记录使用Performance API遇到的问题
本文中Performance API指的是Navigation Timing API。這并不是一篇Navigation Timing API的介紹文章，而是我在使用中遇到的問(wèn)題。
我在開(kāi)發(fā)中遇到Navigation Timing API中的connectStart等時(shí)間節(jié)點(diǎn)并不是標(biāo)準(zhǔn)時(shí)間戳，而是0或者一個(gè)很小的數(shù)值，導(dǎo)致指標(biāo)數(shù)據(jù)計(jì)算出錯(cuò)，尤其是IOS設(shè)備。原因如下:
IOS設(shè)備通過(guò)瀏覽器的前進(jìn)后退按鈕進(jìn)入的頁(yè)面，Navigation Timing API數(shù)據(jù)中connectStart，responseEnd等數(shù)據(jù)可能為0或者是一個(gè)比較小的數(shù)值，并不是對(duì)應(yīng)時(shí)間點(diǎn)的時(shí)間戳。究其原因，IOS設(shè)備通過(guò)緩存讀取頁(yè)面時(shí)，Navigation Timing的計(jì)算與安卓實(shí)現(xiàn)不一致。
如果你還想了解下Navigation Timing API，可以繼續(xù)往下看
Navigation Timing API
Navigation Timing API中包含全部的頁(yè)面加載中關(guān)鍵節(jié)點(diǎn)的時(shí)間，例如navigationStart，connectEnd，responseEnd等時(shí)間。
具體的相關(guān)API可以去MDN查看，
瀏覽器支持程度也非常不錯(cuò)，移動(dòng)端IOS9及以上，Android4及以上都支持，桌面端IE9也都支持。
一些常規(guī)的性能數(shù)據(jù)計(jì)算方法
DNS時(shí)間 = domainLookupEnd - domainLookupStart
TCP時(shí)間 = connectEnd - connectStart
后端時(shí)間 = responseEnd - connectEnd
白屏?xí)r間 = domInteractive - navigationStart
整屏?xí)r間 = loadEventEnd - navigationStart
解析dom樹(shù)耗時(shí) = domComplete - domInteractive
request請(qǐng)求耗時(shí) = responseEnd - responseStart
我們團(tuán)隊(duì)就是按照如上指標(biāo)來(lái)做的各個(gè)時(shí)間的統(tǒng)計(jì)，做了各種測(cè)試，線下數(shù)據(jù)都沒(méi)什么問(wèn)題。上線了以后拿到的首批數(shù)據(jù)中，后端時(shí)間計(jì)算出來(lái)竟然有負(fù)值，尤其在IOS設(shè)備下，苦苦尋找原因，終于發(fā)現(xiàn)問(wèn)題所在。
IOS設(shè)備通過(guò)瀏覽器的前進(jìn)后退按鈕進(jìn)入的頁(yè)面，Navigation Timing API數(shù)據(jù)中connectStart，responseEnd等數(shù)據(jù)可能為0或者是一個(gè)比較小的數(shù)值，并不是對(duì)應(yīng)時(shí)間點(diǎn)的時(shí)間戳。
關(guān)于首屏?xí)r間的定義
根據(jù)Navigation Timing API的時(shí)間，是沒(méi)有辦法計(jì)算首屏?xí)r間的，首屏?xí)r間也并沒(méi)有嚴(yán)格的定義，我們團(tuán)隊(duì)采用的首屏?xí)r間如下
首屏?xí)r間 = （dom解析完畢 && 所有首屏圖片加載完畢 ）- navigationStart
標(biāo)準(zhǔn)
| navigationStart | 準(zhǔn)備加載新頁(yè)面的起始時(shí)間 |
| redirectStart | 如果發(fā)生了HTTP重定向，并且從導(dǎo)航開(kāi)始，中間的每次重定向，都和當(dāng)前文檔同域的話，就返回開(kāi)始重定向的timing.fetchStart的值。其他情況，則返回0 |
| redirectEnd | 如果發(fā)生了HTTP重定向，并且從導(dǎo)航開(kāi)始，中間的每次重定向，都和當(dāng)前文檔同域的話，就返回最后一次重定向，接收到最后一個(gè)字節(jié)數(shù)據(jù)后的那個(gè)時(shí)間.其他情況則返回0 |
| fetchStart | 如果一個(gè)新的資源獲取被發(fā)起，則 fetchStart必須返回用戶(hù)代理開(kāi)始檢查其相關(guān)緩存的那個(gè)時(shí)間，其他情況則返回開(kāi)始獲取該資源的時(shí)間 |
| domainLookupStart | 返回用戶(hù)代理對(duì)當(dāng)前文檔所屬域進(jìn)行DNS查詢(xún)開(kāi)始的時(shí)間。如果此請(qǐng)求沒(méi)有DNS查詢(xún)過(guò)程，如長(zhǎng)連接，資源cache,甚至是本地資源等。 那么就返回 fetchStart的值 |
| domainLookupEnd | 返回用戶(hù)代理對(duì)結(jié)束對(duì)當(dāng)前文檔所屬域進(jìn)行DNS查詢(xún)的時(shí)間。如果此請(qǐng)求沒(méi)有DNS查詢(xún)過(guò)程，如長(zhǎng)連接，資源cache，甚至是本地資源等。那么就返回 fetchStart的值 |
| connectStart | 返回用戶(hù)代理向服務(wù)器服務(wù)器請(qǐng)求文檔，開(kāi)始建立連接的那個(gè)時(shí)間，如果此連接是一個(gè)長(zhǎng)連接，又或者直接從緩存中獲取資源（即沒(méi)有與服務(wù)器建立連接）。則返回domainLookupEnd的值 |
| (secureConnectionStart) | 可選特性。用戶(hù)代理如果沒(méi)有對(duì)應(yīng)的東東，就要把這個(gè)設(shè)置為undefined。如果有這個(gè)東東，并且是HTTPS協(xié)議，那么就要返回開(kāi)始SSL握手的那個(gè)時(shí)間。 如果不是HTTPS， 那么就返回0 |
| connectEnd | 返回用戶(hù)代理向服務(wù)器服務(wù)器請(qǐng)求文檔，建立連接成功后的那個(gè)時(shí)間，如果此連接是一個(gè)長(zhǎng)連接，又或者直接從緩存中獲取資源（即沒(méi)有與服務(wù)器建立連接）。則返回domainLookupEnd的值 |
| requestStart | 返回從服務(wù)器、緩存、本地資源等，開(kāi)始請(qǐng)求文檔的時(shí)間 |
| responseStart | 返回用戶(hù)代理從服務(wù)器、緩存、本地資源中，接收到第一個(gè)字節(jié)數(shù)據(jù)的時(shí)間 |
| responseEnd | 返回用戶(hù)代理接收到最后一個(gè)字符的時(shí)間，和當(dāng)前連接被關(guān)閉的時(shí)間中，更早的那個(gè)。同樣，文檔可能來(lái)自服務(wù)器、緩存、或本地資源 |
| domLoading | 返回用戶(hù)代理把其文檔的 "current document readiness" 設(shè)置為 "loading"的時(shí)候 |
| domInteractive | 返回用戶(hù)代理把其文檔的 "current document readiness" 設(shè)置為 "interactive"的時(shí)候. |
| domContentLoadedEventStart | 返回文檔發(fā)生 DOMContentLoaded事件的時(shí)間 |
| domContentLoadedEventEnd | 文檔的DOMContentLoaded 事件的結(jié)束時(shí)間 |
| domComplete | 返回用戶(hù)代理把其文檔的 "current document readiness" 設(shè)置為 "complete"的時(shí)候 |
| loadEventStart | 文檔觸發(fā)load事件的時(shí)間。如果load事件沒(méi)有觸發(fā)，那么該接口就返回0 |
| loadEventEnd | 文檔觸發(fā)load事件結(jié)束后的時(shí)間。如果load事件沒(méi)有觸發(fā)，那么該接口就返回0 |
總結(jié)
以上是生活随笔為你收集整理的记录使用Performance API遇到的问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： OpenStack云计算口袋书－第一章－
- 下一篇： 中国式领导