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