Resource Timing
轉(zhuǎn)載: https://developers.google.cn/web/tools/chrome-devtools/network-performance/understanding-resource-timing
使用performance.timing對(duì)象里面的數(shù)據(jù)進(jìn)行計(jì)算操作就能得出時(shí)間啦。
公式如下：
DNS解析時(shí)間： domainLookupEnd - domainLookupStart
TCP建立連接時(shí)間： connectEnd - connectStart
白屏?xí)r間： responseStart - navigationStart
dom渲染完成時(shí)間： domContentLoadedEventEnd - navigationStart
頁(yè)面onload時(shí)間： loadEventEnd - navigationStart
了解通過網(wǎng)絡(luò)收集資源的階段至關(guān)重要。這是解決加載問題的基礎(chǔ)。
所有網(wǎng)絡(luò)請(qǐng)求都被視為資源。通過網(wǎng)絡(luò)對(duì)它們進(jìn)行檢索時(shí)，資源具有不同生命周期，以 Resource Timing 表示。Network 面板使用與應(yīng)用開發(fā)者所用相同的 Resource Timing API。
請(qǐng)注意：當(dāng)使用具有跨源資源的 Resource Timing API 時(shí)，確保所有資源具有 CORS 標(biāo)頭。
Resource Timing API 提供了與接收各個(gè)資源的時(shí)間有關(guān)的大量詳細(xì)信息。請(qǐng)求生命周期的主要階段包括：
重定向
立即開始 startTime
。
如果正在發(fā)生重定向，redirectStart
也會(huì)開始。
如果重定向在本階段末發(fā)生，將采集 redirectEnd
。
應(yīng)用緩存
如果是應(yīng)用緩存在實(shí)現(xiàn)請(qǐng)求，將采集 fetchStart
時(shí)間。
DNS
domainLookupStart
時(shí)間在 DNS 請(qǐng)求開始時(shí)采集。
domainLookupEnd
時(shí)間在 DNS 請(qǐng)求結(jié)束時(shí)采集。
TCP
connectStart
在初始連接到服務(wù)器時(shí)采集。
如果正在使用 TLS 或 SSL，secureConnectionStart
將在握手（確保連接安全）開始時(shí)開始。
connectEnd
將在到服務(wù)器的連接完成時(shí)采集。
請(qǐng)求
requestStart
會(huì)在對(duì)某個(gè)資源的請(qǐng)求被發(fā)送到服務(wù)器后立即采集。
響應(yīng)
responseStart
是服務(wù)器初始響應(yīng)請(qǐng)求的時(shí)間。
responseEnd
是請(qǐng)求結(jié)束并且數(shù)據(jù)完成檢索的時(shí)間。
在 DevTools 中查看
要查看 Network 面板中給定條目完整的耗時(shí)信息，您有三種選擇。
將鼠標(biāo)懸停到 Timeline 列下的耗時(shí)圖表上。這將呈現(xiàn)一個(gè)顯示完整耗時(shí)數(shù)據(jù)的彈出窗口。
點(diǎn)擊任何條目并打開該條目的 Timing 標(biāo)簽。
使用 Resource Timing API 從 JavaScript 檢索原始數(shù)據(jù)。
此代碼可以在 DevTools 的 Console 中運(yùn)行。 它將使用 Network Timing API 檢索所有資源。 然后，它將通過查找是否存在名稱中包含“style.css”的條目對(duì)條目進(jìn)行過濾。 如果找到，將返回相應(yīng)條目。
Queuing
如果某個(gè)請(qǐng)求正在排隊(duì)，則指示：請(qǐng)求已被渲染引擎推遲，因?yàn)樵撜?qǐng)求的優(yōu)先級(jí)被視為低于關(guān)鍵資源（例如腳本/樣式）的優(yōu)先級(jí)。 圖像經(jīng)常發(fā)生這種情況。
請(qǐng)求已被暫停，以等待將要釋放的不可用 TCP 套接字。
請(qǐng)求已被暫停，因?yàn)樵?HTTP 1 上，瀏覽器僅允許每個(gè)源擁有六個(gè) TCP 連接。
生成磁盤緩存條目所用的時(shí)間（通常非常迅速）
Stalled/Blocking
請(qǐng)求等待發(fā)送所用的時(shí)間。 可以是等待 Queueing 中介紹的任何一個(gè)原因。 此外，此時(shí)間包含代理協(xié)商所用的任何時(shí)間。
Proxy Negotiation
與代理服務(wù)器連接協(xié)商所用的時(shí)間。
DNS Lookup
執(zhí)行 DNS 查詢所用的時(shí)間。 頁(yè)面上的每一個(gè)新域都需要完整的往返才能執(zhí)行 DNS 查詢。
Initial Connection / Connecting
建立連接所用的時(shí)間，包括 TCP 握手/重試和協(xié)商 SSL 的時(shí)間。
SSL
完成 SSL 握手所用的時(shí)間。
Request Sent / Sending
發(fā)出網(wǎng)絡(luò)請(qǐng)求所用的時(shí)間。 通常不到一毫秒。
Waiting (TTFB)
等待初始響應(yīng)所用的時(shí)間，也稱為至第一字節(jié)的時(shí)間。 此時(shí)間將捕捉到服務(wù)器往返的延遲時(shí)間，以及等待服務(wù)器傳送響應(yīng)所用的時(shí)間。
Content Download / Downloading
接收響應(yīng)數(shù)據(jù)所用的時(shí)間。
診斷網(wǎng)絡(luò)問題
通過 Network 面板可以發(fā)現(xiàn)大量可能的問題。查找這些問題需要很好地了解客戶端與服務(wù)器如何通信，以及協(xié)議施加的限制。
已被加入隊(duì)列或已被停止的系列
最常見問題是一系列已被加入隊(duì)列或已被停止的條目。這表明正在從單個(gè)網(wǎng)域檢索太多的資源。在 HTTP 1.0/1.1 連接上，Chrome 會(huì)將每個(gè)主機(jī)強(qiáng)制設(shè)置為最多六個(gè) TCP 連接。如果您一次請(qǐng)求十二個(gè)條目，前六個(gè)將開始，而后六個(gè)將被加入隊(duì)列。最初的一半完成后，隊(duì)列中的第一個(gè)條目將開始其請(qǐng)求流程。
要為傳統(tǒng)的 HTTP 1 流量解決此問題，您需要實(shí)現(xiàn)域分片。也就是在您的應(yīng)用上設(shè)置多個(gè)子域，以便提供資源。然后，在子域之間平均分配正在提供的資源。
HTTP 1 連接的修復(fù)結(jié)果不會(huì)應(yīng)用到 HTTP 2 連接上。事實(shí)上，前者的結(jié)果會(huì)影響后者。 如果您部署了 HTTP 2，請(qǐng)不要對(duì)您的資源進(jìn)行域分片，因?yàn)樗c HTTP 2 的操作方式相反。在 HTTP 2 中，到服務(wù)器的單個(gè) TCP 連接作為多路復(fù)用連接。這消除了 HTTP 1 中的六個(gè)連接限制，并且可以通過單個(gè)連接同時(shí)傳輸多個(gè)資源。
至第一字節(jié)的漫長(zhǎng)時(shí)間
又稱：大片綠色
等待時(shí)間長(zhǎng)表示至第一字節(jié)的時(shí)間 (TTFB) 漫長(zhǎng)。建議將此值控制在 200 毫秒以下。長(zhǎng) TTFB 會(huì)揭示兩個(gè)主要問題之一。
請(qǐng)執(zhí)行以下任一操作：
客戶端與服務(wù)器之間的網(wǎng)絡(luò)條件較差，或者 2.服務(wù)器應(yīng)用的響應(yīng)慢
要解決長(zhǎng) TTFB，首先請(qǐng)盡可能縮減網(wǎng)絡(luò)。理想的情況是將應(yīng)用托管在本地，然后查看 TTFB 是否仍然很長(zhǎng)。如果仍然很長(zhǎng)，則需要優(yōu)化應(yīng)用的響應(yīng)速度?？梢允莾?yōu)化數(shù)據(jù)庫(kù)查詢、為特定部分的內(nèi)容實(shí)現(xiàn)緩存，或者修改您的網(wǎng)絡(luò)服務(wù)器配置。很多原因都可能導(dǎo)致后端緩慢。您需要調(diào)查您的軟件并找出未滿足您的性能預(yù)算的內(nèi)容。
如果本地托管后 TTFB 仍然漫長(zhǎng)，那么問題出在您的客戶端與服務(wù)器之間的網(wǎng)絡(luò)上。很多事情都可以阻止網(wǎng)絡(luò)遍歷?？蛻舳伺c服務(wù)器之間有許多點(diǎn)，每個(gè)點(diǎn)都有其自己的連接限制并可能引發(fā)問題。測(cè)試時(shí)間是否縮短的最簡(jiǎn)單方法是將您的應(yīng)用置于其他主機(jī)上，并查看 TTFB 是否有所改善。
達(dá)到吞吐量能力
又稱：大片藍(lán)色
如果您看到 Content Download 階段花費(fèi)了大量時(shí)間，則提高服務(wù)器響應(yīng)或串聯(lián)不會(huì)有任何幫助。首要的解決辦法是減少發(fā)送的字節(jié)數(shù)。
