資訊專欄INFORMATION COLUMN
摘要：記錄使用遇到的問題本文中指的是。上線了以后拿到的首批數(shù)據(jù)中，后端時間計算出來竟然有負(fù)值，尤其在設(shè)備下，苦苦尋找原因，終于發(fā)現(xiàn)問題所在。如果事件沒有觸發(fā)，那么該接口就返回文檔觸發(fā)事件結(jié)束后的時間。
記錄使用Performance API遇到的問題
本文中Performance API指的是Navigation Timing API。這并不是一篇Navigation Timing API的介紹文章，而是我在使用中遇到的問題。
我在開發(fā)中遇到Navigation Timing API中的connectStart等時間節(jié)點并不是標(biāo)準(zhǔn)時間戳，而是0或者一個很小的數(shù)值，導(dǎo)致指標(biāo)數(shù)據(jù)計算出錯，尤其是IOS設(shè)備。原因如下:
IOS設(shè)備通過瀏覽器的前進(jìn)后退按鈕進(jìn)入的頁面，Navigation Timing API數(shù)據(jù)中connectStart，responseEnd等數(shù)據(jù)可能為0或者是一個比較小的數(shù)值，并不是對應(yīng)時間點的時間戳。究其原因，IOS設(shè)備通過緩存讀取頁面時，Navigation Timing的計算與安卓實現(xiàn)不一致。
如果你還想了解下Navigation Timing API，可以繼續(xù)往下看
Navigation Timing APINavigation Timing API中包含全部的頁面加載中關(guān)鍵節(jié)點的時間，例如navigationStart，connectEnd，responseEnd等時間。
具體的相關(guān)API可以去MDN查看，
瀏覽器支持程度也非常不錯，移動端IOS9及以上，Android4及以上都支持，桌面端IE9也都支持。
DNS時間 = domainLookupEnd - domainLookupStart
TCP時間 = connectEnd - connectStart
后端時間 = responseEnd - connectEnd
白屏?xí)r間 = domInteractive - navigationStart
整屏?xí)r間 = loadEventEnd - navigationStart
解析dom樹耗時 = domComplete - domInteractive
request請求耗時 = responseEnd - responseStart
我們團(tuán)隊就是按照如上指標(biāo)來做的各個時間的統(tǒng)計，做了各種測試，線下數(shù)據(jù)都沒什么問題。上線了以后拿到的首批數(shù)據(jù)中，后端時間計算出來竟然有負(fù)值，尤其在IOS設(shè)備下，苦苦尋找原因，終于發(fā)現(xiàn)問題所在。
IOS設(shè)備通過瀏覽器的前進(jìn)后退按鈕進(jìn)入的頁面，Navigation Timing API數(shù)據(jù)中connectStart，responseEnd等數(shù)據(jù)可能為0或者是一個比較小的數(shù)值，并不是對應(yīng)時間點的時間戳。
關(guān)于首屏?xí)r間的定義根據(jù)Navigation Timing API的時間，是沒有辦法計算首屏?xí)r間的，首屏?xí)r間也并沒有嚴(yán)格的定義，我們團(tuán)隊采用的首屏?xí)r間如下
首屏?xí)r間 = （dom解析完畢 && 所有首屏圖片加載完畢 ）- navigationStart
標(biāo)準(zhǔn)| 屬性 | 含義 |
|---|---|
| navigationStart | 準(zhǔn)備加載新頁面的起始時間 |
| redirectStart | 如果發(fā)生了HTTP重定向，并且從導(dǎo)航開始，中間的每次重定向，都和當(dāng)前文檔同域的話，就返回開始重定向的timing.fetchStart的值。其他情況，則返回0 |
| redirectEnd | 如果發(fā)生了HTTP重定向，并且從導(dǎo)航開始，中間的每次重定向，都和當(dāng)前文檔同域的話，就返回最后一次重定向，接收到最后一個字節(jié)數(shù)據(jù)后的那個時間.其他情況則返回0 |
| fetchStart | 如果一個新的資源獲取被發(fā)起，則 fetchStart必須返回用戶代理開始檢查其相關(guān)緩存的那個時間，其他情況則返回開始獲取該資源的時間 |
| domainLookupStart | 返回用戶代理對當(dāng)前文檔所屬域進(jìn)行DNS查詢開始的時間。如果此請求沒有DNS查詢過程，如長連接，資源cache,甚至是本地資源等。 那么就返回 fetchStart的值 |
| domainLookupEnd | 返回用戶代理對結(jié)束對當(dāng)前文檔所屬域進(jìn)行DNS查詢的時間。如果此請求沒有DNS查詢過程，如長連接，資源cache，甚至是本地資源等。那么就返回 fetchStart的值 |
| connectStart | 返回用戶代理向服務(wù)器服務(wù)器請求文檔，開始建立連接的那個時間，如果此連接是一個長連接，又或者直接從緩存中獲取資源（即沒有與服務(wù)器建立連接）。則返回domainLookupEnd的值 |
| (secureConnectionStart) | 可選特性。用戶代理如果沒有對應(yīng)的東東，就要把這個設(shè)置為undefined。如果有這個東東，并且是HTTPS協(xié)議，那么就要返回開始SSL握手的那個時間。 如果不是HTTPS， 那么就返回0 |
| connectEnd | 返回用戶代理向服務(wù)器服務(wù)器請求文檔，建立連接成功后的那個時間，如果此連接是一個長連接，又或者直接從緩存中獲取資源（即沒有與服務(wù)器建立連接）。則返回domainLookupEnd的值 |
| requestStart | 返回從服務(wù)器、緩存、本地資源等，開始請求文檔的時間 |
| responseStart | 返回用戶代理從服務(wù)器、緩存、本地資源中，接收到第一個字節(jié)數(shù)據(jù)的時間 |
| responseEnd | 返回用戶代理接收到最后一個字符的時間，和當(dāng)前連接被關(guān)閉的時間中，更早的那個。同樣，文檔可能來自服務(wù)器、緩存、或本地資源 |
| domLoading | 返回用戶代理把其文檔的 "current document readiness" 設(shè)置為 "loading"的時候 |
| domInteractive | 返回用戶代理把其文檔的 "current document readiness" 設(shè)置為 "interactive"的時候. |
| domContentLoadedEventStart | 返回文檔發(fā)生 DOMContentLoaded事件的時間 |
| domContentLoadedEventEnd | 文檔的DOMContentLoaded 事件的結(jié)束時間 |
| domComplete | 返回用戶代理把其文檔的 "current document readiness" 設(shè)置為 "complete"的時候 |
| loadEventStart | 文檔觸發(fā)load事件的時間。如果load事件沒有觸發(fā)，那么該接口就返回0 |
| loadEventEnd | 文檔觸發(fā)load事件結(jié)束后的時間。如果load事件沒有觸發(fā)，那么該接口就返回0 |
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/89509.html
摘要：回過頭來發(fā)現(xiàn)，我們的項目，雖然在服務(wù)端層面做好了日志和性能統(tǒng)計，但在前端對異常的監(jiān)控和性能的統(tǒng)計。對于前端的性能與異常上報的可行性探索是有必要的。這是我們頁面加載性能優(yōu)化需求中主要上報的相關(guān)信息。 概述 對于后臺開發(fā)來說，記錄日志是一種非常常見的開發(fā)習(xí)慣，通常我們會使用try...catch代碼塊來主動捕獲錯誤、對于每次接口調(diào)用，也會記錄下每次接口調(diào)用的時間消耗，以便我們監(jiān)控服務(wù)器接口...
今天來給大家介紹下前端監(jiān)控中一個特定指標(biāo)的獲取算法，有人會問，為啥就單單講一個指標(biāo)？這是因為，目前大部分的指標(biāo)，比如白屏?xí)r間，dom加載時間等等，都能通過現(xiàn)代瀏覽器提供的各種api去進(jìn)行較為精確的獲取，而今天講的這個指標(biāo)，以往獲取他的方式只能是通過邏輯埋點去獲取它的值，因此在做一些前端監(jiān)控時，需要根據(jù)業(yè)務(wù)需要去改變頁面對這個值的埋點方式，會比較繁瑣，恰巧最近剛剛好在做一些前端監(jiān)控相關(guān)的項目，遇到這...
摘要：前端渲染過程的二三事本文不會介紹整個前端渲染過程的步驟，只是記錄最近閱讀的文章的些許思考和感悟。那么現(xiàn)在我們可以明白這個問題的關(guān)鍵所在了，因為在大部分頁面中是擁有的，而由于其解析順序，那么在事件之前必定已經(jīng)成功構(gòu)造樹。 前端渲染過程的二三事 本文不會介紹整個前端渲染過程的步驟，只是記錄最近閱讀的文章的些許思考和感悟。（文章地址一（系列）,文章地址二） 希望大家在閱讀這篇文章之前能將上述...
摘要：參考鏈接初探監(jiān)控網(wǎng)頁與程序性能使用簡潔的測試網(wǎng)頁加載速度前端性能統(tǒng)計前端性能監(jiān)控起步使用性能快速分析前端性能通過以上幾篇文章，可以對前端性能相關(guān)的概念和有一個整體的認(rèn)識。但在我們這次的前端性能監(jiān)控方案中，并不將其作為主要的監(jiān)控指標(biāo)。 參考鏈接 初探 performance – 監(jiān)控網(wǎng)頁與程序性能 使用簡潔的 Navigation Timing API 測試網(wǎng)頁加載速度 前端性能統(tǒng)計 ...
摘要：前言最近有幸參與一個前端質(zhì)量監(jiān)控類項目的重構(gòu)，算是個人初次接觸到前端質(zhì)量監(jiān)控相關(guān)的知識，對于其中的性能統(tǒng)計部分很感興趣，查詢資料之后寫了文章，作為個人學(xué)習(xí)記錄，如有錯誤，敬請斧正頁面整體性能通過瀏覽器提供的方法，我們能夠得到網(wǎng)頁每個處理階段 前言 最近有幸參與一個前端質(zhì)量監(jiān)控類項目的重構(gòu)，算是個人初次接觸到前端質(zhì)量監(jiān)控相關(guān)的知識，對于其中的性能統(tǒng)計部分很感興趣，查詢資料之后寫了文章，作...
閱讀 3789·2021-08-10 09:42
閱讀 687·2019-08-30 15:55
閱讀 969·2019-08-30 15:54
閱讀 3195·2019-08-30 13:45
閱讀 647·2019-08-29 16:23
閱讀 2068·2019-08-29 16:23
閱讀 1082·2019-08-29 15:18
閱讀 2342·2019-08-29 12:57
