瞭解資源耗時 | Chrome F12 network

瞭解資源耗時

瞭解經過網絡收集資源的階段相當重要。這是解決加載問題的基礎。

TL;DR

• 瞭解資源耗時的階段。

• 瞭解每一個階段向 Resource Timing API 提供的內容。

• 瞭解時間線圖表中不一樣的性能問題指示器，例如一系列透明欄或者大片的綠塊。

全部網絡請求都被視爲資源。經過網絡對它們進行檢索時，資源具備不一樣生命週期，以資源耗時表示。Network 面板使用與應用開發者所用相同的 Resource Timing API。

請注意：當使用具備跨源資源的 Resource Timing API 時，確保全部資源具備 CORS 標頭。

Resource Timing API 提供了與接收各個資源的時間有關的大量詳細信息。請求生命週期的主要階段包括：

• 重定向

• 當即開始 startTime。

• 若是正在發生重定向，redirectStart 也會開始。

• 若是重定向在本階段末發生，將採集 redirectEnd。

• 應用緩存

• 若是是應用緩存在實現請求，將採集 fetchStart 時間。

• DNS

• domainLookupStart 時間在 DNS 請求開始時採集。

• domainLookupEnd 時間在 DNS 請求結束時採集。

• TCP

• connectStart 在初始鏈接到服務器時採集。

• 若是正在使用 TLS 或 SSL，secureConnectionStart 將在握手（確保鏈接安全）開始時開始。

• connectEnd 將在到服務器的鏈接完成時採集。

• 請求

• requestStart 會在對某個資源的請求被髮送到服務器後當即採集。

• 響應

• responseStart 是服務器初始響應請求的時間。

• responseEnd 是請求結束而且數據完成檢索的時間。

在 DevTools 中查看

要查看 Network 面板中給定條目完整的耗時信息，您有三種選擇。

1. 將鼠標懸停到 Timeline 列下的耗時圖表上。這將呈現一個顯示完整耗時數據的彈出窗口。

2. 點擊任何條目並打開該條目的 Timing 標籤。

3. 使用 Resource Timing API 從 JavaScript 檢索原始數據。

此代碼能夠在 DevTools 的 Console 中運行。 它將使用 Network Timing API 檢索全部資源。 而後，它將經過查找是否存在名稱中包含「style.css」的條目對條目進行過濾。 若是找到，將返回相應條目。

performance.getEntriesByType('resource').filter(item => item.name.includes("style.css"))

Queuing

若是某個請求正在排隊，則指示：

• 請求已被渲染引擎推遲，由於該請求的優先級被視爲低於關鍵資源（例如腳本/樣式）的優先級。 圖像常常發生這種狀況。

• 請求已被暫停，以等待將要釋放的不可用 TCP 套接字。

• 請求已被暫停，由於在 HTTP 1 上，瀏覽器僅容許每一個源擁有六個 TCP 鏈接。

• 生成磁盤緩存條目所用的時間（一般很是迅速）

Stalled/Blocking

請求等待發送所用的時間。 能夠是等待 Queueing 中介紹的任何一個緣由。 此外，此時間包含代理協商所用的任什麼時候間。

Proxy Negotiation

與代理服務器鏈接協商所用的時間。

DNS Lookup

執行 DNS 查詢所用的時間。 頁面上的每個新域都須要完整的往返才能執行 DNS 查詢。

Initial Connection / Connecting

創建鏈接所用的時間，包括 TCP 握手/重試和協商 SSL 的時間。

SSL

完成 SSL 握手所用的時間。

Request Sent / Sending

發出網絡請求所用的時間。 一般不到一毫秒。

Waiting (TTFB)

等待初始響應所用的時間，也稱爲至第一字節的時間。 此時間將捕捉到服務器往返的延遲時間，以及等待服務器傳送響應所用的時間。

Content Download / Downloading

接收響應數據所用的時間。

診斷網絡問題

經過 Network 面板能夠發現大量可能的問題。查找這些問題須要很好地瞭解客戶端與服務器如何通訊，以及協議施加的限制。

已被加入隊列或已被中止的系列

最多見問題是一系列已被加入隊列或已被中止的條目。這代表正在從單個網域檢索太多的資源。在 HTTP 1.0/1.1 鏈接上，Chrome 會將每一個主機強制設置爲最多六個 TCP 鏈接。若是您一次請求十二個條目，前六個將開始，然後六個將被加入隊列。最初的一半完成後，隊列中的第一個條目將開始其請求流程。

要爲傳統的 HTTP 1 流量解決此問題，您須要實現域分片。也就是在您的應用上設置多個子域，以便提供資源。而後，在子域之間平均分配正在提供的資源。

HTTP 1 鏈接的修復結果不會應用到 HTTP 2 鏈接上。事實上，前者的結果會影響後者。 若是您部署了 HTTP 2，請不要對您的資源進行域分片，由於它與 HTTP 2 的操做方式相反。在 HTTP 2 中，到服務器的單個 TCP 鏈接做爲多路複用鏈接。這消除了 HTTP 1 中的六個鏈接限制，而且能夠經過單個鏈接同時傳輸多個資源。

至第一字節的漫長時間

又稱：大片綠色

等待時間長表示至第一字節的時間 (TTFB) 漫長。建議將此值控制在 200 毫秒如下。長 TTFB 會揭示兩個主要問題之一。

請執行如下任一操做：

1. 客戶端與服務器之間的網絡條件較差，或者 2. 服務器應用的響應慢

要解決長 TTFB，首先請儘量縮減網絡。理想的狀況是將應用託管在本地，而後查看 TTFB 是否仍然很長。若是仍然很長，則須要優化應用的響應速度。能夠是優化數據庫查詢、爲特定部分的內容實現緩存，或者修改您的網絡服務器配置。不少緣由均可能致使後端緩慢。您須要調查您的軟件並找出未知足您的性能預算的內容。

若是本地託管後 TTFB 仍然漫長，那麼問題出在您的客戶端與服務器之間的網絡上。不少事情均可以阻止網絡遍歷。客戶端與服務器之間有許多點，每一個點都有其本身的鏈接限制並可能引起問題。測試時間是否縮短的最簡單方法是將您的應用置於其餘主機上，並查看 TTFB 是否有所改善。

達到吞吐量能力

又稱：大片藍色

若是您看到 Content Download 階段花費了大量時間，則提升服務器響應或串聯不會有任何幫助。首要的解決辦法是減小發送的字節數。