【第1041期】關鍵請求

科技 08-29

前言

今日早讀文章由眾成平台@Athon翻譯分享。

正文從這開始～

網站服務看起來很簡單：發送HTML，瀏覽器進行處理並載入資源，然後我們只要耐心的等頁面渲染好即可。

但是你很少知道，整個過程背後發生了很多事情。

你有沒有想過，瀏覽器如何知道應該載入哪些資源，並且以什麼順序來載入這些資源？

今天我們將看看如何利用資源優先順序來提高載入速度。

GIF/415K

頁面資源的載入流程

大多數瀏覽器使用流解析器來解析HTML，解析器通過標記（markup）發現外鏈的資源，隨後這些資源會根據一個預先確定的優先順序被添加到一個網路隊列中。

在Chrome中，資源有以下幾種優先順序：很低[Very Low],低[Low] ，中[Medium]，高[High]和非常高[Very high]。在Chrome DevTools的源碼中，定義了稍微不同的叫法: 最低[Lowest],低[Low], 中[Medium], 高[High]和最高[Highest].

如果你想看你網站請求的優先順序，你可以通過在Chrome DevTools的網路請求面板中開啟Priority欄來查看。

提示：如果你使用Safari Technology preview，用同樣的方式也能看到（新的）Prority 欄。

GIF/270K

通過右鍵單擊任意請求面板標籤來顯示請求的優先順序。

你還可以在Performance標籤下查看每個請求的優先順序。

滑鼠移入時顯示資源的載入時間和優先順序。

Chrome如何定義資源的優先順序？

每種資源類型（CSS、JavaScript、字體等）都有自己的一套規則，規定它們將如何被排序。下面是關於網路優先順序計劃的不完全清單：

HTML— 最高優先順序（Highest）

Styles—最高優先順序（Highest）。使用@import引用的樣式同樣也是最高優先順序，但是會被排在阻塞腳本之後。

Images是唯一可以根據視口動態改變優先順序的資源。所有圖像以低優先順序（Low）開始，但在可見視口中渲染時將被提升為中等優先順序（Medium）。視口之外的圖像（也稱為「below the fold」）依舊保持低優先順序。

在這篇文章的調研階段，（在Paul Irish的幫助下）我發現Chrome DevTools將已被提升為中優先順序的圖片誤報為低優先順序，Paul寫過一個錯誤報告，你可以在這裡進行查看。

如果你想要知道Chrome源碼里是如何進行圖片優先順序提升的，你可以從UpdateAllImageResourcePriorities和ComputeResourcePriority這開始看。

Ajax/XHR/fetch()—高優先順序（High）。

Script 遵循一個複雜的載入優先順序方案。（Jake Archibald在2013年詳細描述了這個方案。如果你想了解它背後的科學，我建議你深入地研究下）。簡單概括一下是這樣的：

使用載入的script，如果該標籤出現在圖片之後，它會被定為中優先順序（Medium）。

使用了async或defer屬性的script，它會被定為低優先順序（Low）。

使用了type="module"屬性的script，它會被定為低優先順序（Low）。

Fonts 更像是難以駕馭的野獸；首先，它們是非常重要的資源（誰也不願意發生這種情況：「我看到它了！」，「現在它不見了」，「哇，一個新字體！」）所以字體理應以最高優先順序（Highest）下載。

不幸的是，大部分@font-face標籤都包含在外鏈的css中（像這樣載入：）。這意味著字體往往會在樣式載入完之後才進行載入。

即使你的CSS文件通過 @font-face引用了字體，也只在你的字體選擇器匹配到頁面上的節點時，才會請求該字體。假設你構建了一個單頁面應用，在應用渲染之前並不會渲染任何文本，那麼字體的載入時間會更加後置。

什麼是關鍵請求？

大多數網站會讓瀏覽器載入渲染頁面所需的全部資源，並沒有「可視區域／above the fold」的具體概念。

過去瀏覽器在同一域名下的同時請求數不會超過6個——人們通過使用assets-1.domain.tld, assets-2.domain.tld這種散列域名來嘗試繞過這種限制，以便同時下載更多的資源，但是並未認識到這會導致每個新域名和資源都會需要DNS解析和TCP連接。

雖然這種方法有一些優點，但我們中的許多人並沒有完全了解它的影響，當然也沒有高質量的瀏覽器開發工具來驗證它們。

謝天謝地，現在我們有了很棒的工具。以CNN為例，我們首先找到可視區域渲染完畢時（對於讀者來說，就是可用時），必須載入的資源。

用戶關注的內容是標題和主要內容。

展示該屏信息時，只有5個部分是必要的（而且在站點可用之前，並不需要把它們全部載入完）：

最重要的，HTML。假設其他請求都失敗了，用戶依舊可以閱讀該頁。

CSS。

Logo（一張用CSS放置的PNG背景圖片。也可以是內嵌的SVG）。

4 種web字體（居然這麼多！）。

文章頭圖

這些靜態資源（注意不包括Javascript）是構成頁面主視窗可視區域所必需的。它們應該首先被載入

但是我們通過Chrome的Performance面板看到，在字體和頭圖載入之前，大概有50 個請求。

GIF/2.0M

在不太穩定的4G環境下記錄，CNN.com大概在9s的時候才被完全渲染。

查看頁面所需的請求，和實際的請求顯然不一樣。

控制資源載入優先順序

現在我們已經定義了什麼是關鍵請求，我們可以開始進行幾個簡單而強大的調整來對它們進行優先順序排序。

預載入（）讓瀏覽器把font.woff放在載入隊列的高優先順序（High）中。

注意：font.woff應該以高優先順序下載的原因是as="font"—它是一個字體，所以它遵循我們在之前「Chrome如何確立資源的優先順序」一節所談到的優先順序規則。

其實這就好像你在告訴瀏覽器，「你可能還不知道它，但是我們將要使用它。」

這對我們之前定義的關鍵請求來說是完美的。Web字體幾乎可以被定為"絕對關鍵"，但是針對字體被發現並下載的方式有一些根本性問題：

我們只有等到CSS被載入、解析和應用，才能發現@font-face規則。

只有通過選擇器將CSS規則匹配到DOM，才會將該字體添加到瀏覽器的請求隊列中。

選擇器匹配發生在樣式重新計算的過程中。它不一定在樣式下載之後「立刻」發生，當主線程繁忙的時候，它可能被延遲。

在大多數情況下，字體的顯示被延遲了好幾秒鐘，僅僅因為我們沒有指示瀏覽器及時下載它們。

在一個擁有低端CPU，網路連接很慢的手機上，假設沒有適當的回退方案，絕對會讓用戶抓狂。

預載入實踐：字體

我對calibreapp.com跑了兩個測試。在第一個測試中，我並未對網站進行任何修改。在第二個裡面，我加了這兩個標籤：

下面，你將看到這兩個測試中網頁渲染的視覺對比。結果是相當驚人的：

當字體被預載入時，頁面渲染速度加快了 3.5 秒

下面那行：字體是預載入的 — 這個網站在3G連接下5秒就渲染完成了。

還接受media=""屬性，它將根據@media查詢規則選擇性地對資源進行優先排序：

在這裡，我們可以為小屏幕設備預載入特定的圖像。對於「超棒頭條圖片」來說非常完美。

正如上面展示的，我們使用簡單的幾個標籤，極大地改善了頁面的請求和渲染性能。

在web字體上更進一步

69%網站使用了web字體, 不幸的是，他們在大多數情況下體驗並不太好。這些文字出現，然後消失，然後再次出現，改變字重並在渲染過程中使頁面發生抖動。

坦率地說，這幾乎在每一個層面上都很糟糕。

正如您在上面看到的，控制字體的請求順序和優先順序對渲染速度有很大的影響。顯然，我們應該在大多數情況下為Web字體請求排優先順序。

我們可以使用CSSfont-display屬性進一步改進。這個屬性允許我們在請求和載入Web字體過程中控制字體顯示的方式。

顯示方式有四個選項，但是我建議使用font-display: swap;，在Web字體載入完之前，使用後備字體進行顯示--載入完成後直接替換原先的字體。

像這樣定義一系列字體：

body{

font-family:Calibre,Helvetica,Arial;

}

瀏覽器會在Calibre字體載入完成之前，先使用Helvetica字體（或者Arial字體，如果你沒有先使用Helvetica字體字體的話）進行展示。現在只有Chrome和Opera支持font-display，但這是跨越性的非同步，從今天起就沒有理由不使用它了。

保持頁面性能

正如你所知道的，網站從來都不是「完整的」。總是有改進的空間，這些技術方案會很快就讓人感覺到應接不暇。

Calibre是一個自動化的工具，用於審核性能、可訪問性和Web最佳實踐，它將幫助你保持領先。

正如您在上面看到的，有幾個指標是理解用戶性能的關鍵。

首次渲染，告訴我們什麼時候瀏覽器開始「從無內容到有內容」

首次有意義的渲染,告訴我們什麼時候瀏覽器「渲染有用的內容」。

最後，首次交互將告訴你什麼時候頁面被完全渲染，並且JavaScript主線程已經落定（CPU已經平穩了幾秒鐘）。

在這裡，我們為CNN的「首次有意義的渲染」設置了一個預期。

您可以針對所有這些關鍵用戶體驗指標設置預期。當超出預期（或滿足預期）時，你的團隊將通過Slack、電子郵件或你喜歡的任何方式得到通知。

GIF/624K

關鍵請求的檢查清單

啟用Chrome DevTools請求優先列表

決定哪個請求必須在用戶可以看到整個渲染頁面前完成。

儘可能減少所需的關鍵請求的數量。

使用靜態資源，這些資源「很可能」被使用在網站的下一頁。

使用，nopush HTTP請求頭來告訴瀏覽器我們需要在HTML完全下載完之前預請求哪些資源。

HTTP/2 Server push目前比較棘手。盡量避免使用它。 (看看Tom Bergan, Simon Pelchat 和 Michael Buettner寫的informative document還有Jake Archibald的 "HTTP/2 Push is tougher than I thought"

在可能的情況下對Web字體使用font-display: swap;。

Web字體有沒有被使用？它們可以被移除嗎？如果不能：提高優先它們的優先順序並且使用WOFF2！

延遲載入腳本會延遲你的單頁應用程序顯示任何東西嗎？

看看這個free screencast 還有 Front End Center ，它們告訴我們如何在載入字體時提供最好的降級體驗。

看下 chrome://net-internals/#events 然後載入一個頁面—它會顯示網路相關的事件。

沒有什麼請求能比不請求更快[No request is faster than no request].

關於本文

譯者：@Athon

譯文：http://www.zcfy.cc/article/the-critical-request-css-tricks-3843.html

作者：@ BEN SCHWAR

原文：https://css-tricks.com/the-critical-request/

點擊展開全文