前端監控性能指標

前端監控性能指標

原文鏈接

性能指標

階段性指標

字段	描述	計算方式	備註
unload	前一個頁面卸載耗時	unloadEventEnd - unloadEventStart	前一個頁面卸載時可能監聽了 unload 做些數據收集，會影響頁面跳轉
redirect	重定向耗時	redirectEnd - redirectStart	過多重定向影響性能
appCache	緩存耗時	domainLookupStart - fetchStart
dns	DNS 解析耗時	domainLookupEnd - domainLookupStart
tcp	TCP 連接耗時	connectEnd - connectStart
ssl	SSL 安全連接耗時	connectEnd - secureConnectionStart	只在 HTTPS 下有效
ttfb	Time to First Byte（TTFB），網絡請求耗時	responseStart - requestStart
response	數據傳輸耗時	responseEnd - responseStart
dom	可交互 DOM 解析耗時	domInteractive - responseEnd	Interactive content
dom2	剩餘 DOM 解析耗時	domContentLoadedEventStart - domInteractive	DOMContentLoaded 所有DOM元素都加載完畢(除了 async script)
DCL	DOMContentLoaded 事件耗時	domContentLoadedEventEnd - domContentLoadedEventStart	document.addEventListener(‘DOMContentLoaded’, cb)
resources	資源加載耗時	loadEventStart - domContentLoadedEventEnd	完整DOM(DOMContentLoaded)到資源加載完畢(window.onLoad)時間
onLoad	onLoad事件耗時	loadEventEnd - loadEventStart

關鍵性能指標

字段	描述	計算方式	備註
firstbyte	首包時間	responseStart - domainLookupStart
fpt	First Paint Time, 首次渲染時間 / 白屏時間	responseEnd - fetchStart	從請求開始到瀏覽器開始解析第一批 HTML 文檔字節的時間差
tti	Time to Interact，首次可交互時間	domInteractive - fetchStart	瀏覽器完成所有 HTML 解析並且完成 DOM 構建，此時瀏覽器開始加載資源
ready	HTML 加載完成時間， 即 DOM Ready 時間	domContentLoadedEventEnd - fetchStart	如果頁面有同步執行的 JS，則同步 JS 執行時間 = ready - tti
load	頁面完全加載時間	loadEventStart - fetchStart	load = 首次渲染時間 + DOM 解析耗時 + 同步 JS 執行 + 資源加載耗時

小程序

字段	描述	計算方式	備註
fpt	First Paint Time, 首次渲染時間	onShow (first page) - onLaunch (app)	小程序從 onLaunch 到第一個頁面 onShow 之間的時間

W3C Level 1

兼容性

常規用法

• 計算主頁面

const t = performance.timing;

const pageloadtime = t.loadEventStart - t.navigationStart,
  dns = t.domainLookupEnd - t.domainLookupStart,
  tcp = t.connectEnd - t.connectStart,
  ttfb = t.responseStart - t.navigationStart;

• 計算頁面資源

const r0 = performance.getEntriesByType('resource')[0];

const loadtime = r0.duration,
  dns = r0.domainLookupEnd - r0.domainLookupStart,
  tcp = r0.connectEnd - r0.connectStart,
  ttfb = r0.responseStart - r0.startTime;

注意事項

1、計算HTML文檔請求使用 Nav Timing

獲取主頁 html 數據，應該使用 performance.timing，而不是 performance.getEntriesByType('resource')[0]。

performance.getEntriesByType('resource') 表示當前 HTML 文檔中引用的所有靜態資源信息，不包括本身 HTML 信息。

如果當前不包含任何靜態資源那麼 performance.getEntriesByType('resource') === [] 使用 [0].xx 會報錯。

2、計算靜態資源使用 getEntriesByType(‘resource’) 代替 getEntries()

getEntries() 包含以下六種類型

1. navigation
2. resource
3. mark
4. measure
5. paint
6. frame

在比較老的瀏覽器中，getEntries() 通常情況下一般只有 resource 類型等同於 getEntriesByType('resource')。
因爲 navigation 是 Navigation Timing 2 規範，老的瀏覽器不支持。而 mark 和 measure 是 User Timing 用戶自定義類型。
最後兩個對於目前（2020年) 來說實現的瀏覽器就更少了。

所有使用 getEntries() 來檢索靜態資源都需要過濾其他幾種類型，getEntriesByType('resource') 就很明確。

3、secureConnectionStart 問題

secureConnectionStart 用來測量 SSL協商 所花費的時間，可能有三種值

1. undefined，瀏覽器不支持該屬性；
2. 0，未使用 HTTPS；
3. timestamp 時間戳，使用了 HTTPS

chrome 很老的版本有一個 bug，當獲取資源複用了已建立的 HTTPS 信道時，secureConnectionStart 設置爲 0 了，按標準應該設置爲時間戳。

取值時應該避免不支持和未使用的情況

const r0 = performance.getEntriesByType('resource')[0];
if ( r0.secureConnectionStart ) {
  const ssl = r0.connectEnd - r0.secureConnectionStart;
}

4、跨域資源設置響應頭 Timing-Allow-Origin

獲取頁面資源時間詳情時，有跨域的限制。默認情況下，跨域資源以下屬性會被設置爲 0

redirectStart
redirectEnd
domainLookupStart
domainLookupEnd
connectStart
connectEnd
secureConnectionStart
requestStart
responseStart

• 對於可控跨域資源例如自家 CDN，Timing-Allow-Origin 的響應頭 origins 至少得設置了主頁面的域名，允許獲取資源時間。
• 一般對外公共資源設置爲 Timing-Allow-Origin: *。
• 對於第三方不可控資源且未設置 Timing-Allow-Origin 頭，應該過濾掉這些無效數據。

如果未正確設置 Timing-Allow-Origin 的話

1. 未做過濾，那麼上報的數據會極大優於用戶實際使用情況；
2. 做了過濾，那麼上了跨域 CDN 的資源也無法上報數據，導致分析不出上了 CDN 的優勢。

// Resource Timing
const r0 = performance.getEntriesByType('resource')[0],
  loadtime = r0.duration;

// 只要選取上述一個屬性(除了secureConnectionStart)進行判斷即可
if ( r0.requestStart ) {
  const dns = r0.domainLookupEnd - r0.domainLookupStart,
    tcp = r0.connectEnd - r0.connectStart,
    ttfb = r0.responseStart - r0.startTime;
}

let ssl = 0; // 默認爲 0，當然也可以在數據庫層面去做
// 使用了 HTTPS 在計算
if ( r0.secureConnectionStart ) {
  ssl = r0.connectEnd - r0.secureConnectionStart;
}

5、注意屬性值爲 0 的含義

上面我們知道了

1. 未使用 HTTPS 時，secureConnectionStart === 0
2. 跨域且未設置正確的 Timing-Allow-Origin 時，有若干屬性值爲 0

• DNS 解析時間 domainLookupEnd - domainLookupStart === 0

1. 和 HTML 同域名下的資源，DNS 時間可能均爲 0，因爲瀏覽器會緩存當前解析域名的 IP；
2. 瀏覽器預解析了 DNS 並緩存，<link rel="dns-prefetch" href="//cross-domain.com" />。

• TCP 建立連接時間 connectEnd – connectStart === 0

1. 例如瀏覽器與每臺主機大概能同時建立 6 個獨立的 TCP 連接，那麼頭 6 個資源的 TCP 非零，剩餘的 keep-alive 信道複用 TCP 時間爲 0

• SSL connectEnd – secureConnectionStart === 0

1. 與 TCP 相同
2. 未使用 HTTPS

總之，爲零有很多場景，注意區分。

1. 不支持
2. 未使用
3. 複用
4. 緩存
5. 安全原因不予顯示
6. …

6、304

很老的 chrome 版本有個bug，在 200 有 Timing-Allow-Origin 未在 304 時設置，
導致上述很多屬性未能設置爲時間戳類型而是 0。

那麼問題來了

1. 你在 #4 中過濾了 304 的情況，只統計了 200 的情況，衆所周知 304 緩存技術明細優於非緩存的 200。
   這會拉低的你平均統計性能。
2. 如果不過濾，那又會獲得比 304 還優的性能統計。

碰到這種情況暫時就沒辦法區分了，幸運的是 chrome 在version 37時修復了。

PS：iframe 與文檔環境是相互隔離的，你可以獲取 iframe 的 contentWindow.performance 來獲取。

W3C Level 2

兼容性

用法

PerformanceNavigationTiming

• 代替 performance.timing(目前兼容性高，仍然可使用，未來可能被廢棄)。

const pageNav = performance.getEntriesByType('navigation')[0];

• PerformanceNavigationTiming 使用了High-Resolution Time，時間精度可以達毫秒的小數點好幾位。

{
    "name": "https://developer.mozilla.org/zh-CN/docs/Web/Performance",
    "entryType": "navigation",
    "startTime": 0,
    "duration": 13636.144999996759,
    "initiatorType": "navigation",
    "nextHopProtocol": "h2",
    "workerStart": 0,
    "redirectStart": 0,
    "redirectEnd": 0,
    "fetchStart": 8.684999993420206,
    "domainLookupStart": 8.684999993420206,
    "domainLookupEnd": 8.684999993420206,
    "connectStart": 8.684999993420206,
    "connectEnd": 8.684999993420206,
    "secureConnectionStart": 8.684999993420206,
    "requestStart": 15.749999991385266,
    "responseStart": 10650.364999994054,
    "responseEnd": 13565.22999999288,
    "transferSize": 56666,
    "encodedBodySize": 56127,
    "decodedBodySize": 207120,
    "serverTiming": [],
    "workerTiming": [],
    "unloadEventStart": 10659.469999998691,
    "unloadEventEnd": 10659.5299999899,
    "domInteractive": 13574.969999986934,
    "domContentLoadedEventStart": 13612.624999994296,
    "domContentLoadedEventEnd": 13612.629999988712,
    "domComplete": 13635.66999998875,
    "loadEventStart": 13635.704999993322,
    "loadEventEnd": 13636.144999996759,
    "type": "navigate",
    "redirectCount": 0
}

• 新增了不少屬性，可以獲取更加詳細的信息(resource 也一樣)。

// Service worker 響應時間
let workerTime = 0;
if (pageNav.workerStart > 0) {
  workerTime = pageNav.responseEnd - pageNav.workerStart;
}

// HTTP header 大小
const headerSize = pageNav.transferSize - pageNav.encodedBodySize;

// 壓縮比率，如果是 1 的話，也能說明未開啓例如 gzip
const compressionRatio = pageNav.decodedBodySize / pageNav.encodedBodySize;

• 兼容，由於 performance.getEntriesByType('navigation') 取不到並不會報錯而是返回空數組。

if (performance.getEntriesByType('navigation').length > 0) {
  // We have Navigation Timing API
}

Paint timing

Paint Timing 定義兩個新指標：

1. 首次繪製 (FP，first-paint) ，瀏覽器渲染任何在視覺上不同於導航前屏幕內容之內容的時間點。這段時間不就是白屏耗時嘛。
2. 首次內容繪製 (FCP，first-contentful-paint)，瀏覽器渲染來自 DOM 第一位內容的時間點。這段時間不就是灰屏耗時嘛。

// 直接在代碼裏這麼用的話，不一定取得到，需要輪詢
performance.getEntriesByType('paint');

[
  {
    "name": "first-paint",
    "entryType": "paint",
    "startTime": 17718.514999956824,
    "duration": 0
  },
  {
    "name": "first-contentful-paint",
    "entryType": "paint",
    "startTime": 17718.519999994896,
    "duration": 0
  }
]

• performance.getEntriesByType 返回的是數組，只有準備好的數據才能入組，你可能需要輪詢，或找到一個恰當的時間點來上報數據。
  新標準，提供了 PerformanceObserver API 來幫你監聽響應的資源數據是否準備好了。

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // `name` will be either 'first-paint' or 'first-contentful-paint'.
    const metricName = entry.name;
    const time = Math.round(entry.startTime + entry.duration);

    collect({
      name: metricName,
      time: time,
    });
  }
});
observer.observe({entryTypes: ['paint'/* , 'navigation', resource */]});

• 使用需要做代碼兼容

if ('performance' in window) {
  if ('PerformanceObserver' in window) {
    // todo
  } else {
    // todo
  }
}

• 首次有效繪製First Meaning Paint (FMP)：表示當前頁面最想展示給用戶的元素渲染的時間點，即主元素渲染點。
• FMP 沒有標準化的定義，需要開發自己定義。例如元素增速最陡峭的那個時間點。

User timing

• performance.mark 打點，參數爲點位名稱標識

performance.mark('starting_calculations');
const multiply = 82 * 21;
performance.mark('ending_calculations');

performance.mark('starting_awesome_script');
function awesomeScript() {
  console.log('doing awesome stuff');
}
performance.mark('ending_awesome_script');

• performance.measure 計算，參數爲點位名稱標識、mark 點位1、mark 點位2

performance.mark('starting_calculations');
const multiply = 82 * 21;
performance.mark('ending_calculations');
+ performance.measure('multiply_measure', 'starting_calculations', 'starting_calculations');

performance.mark('starting_awesome_script');
function awesomeScript() {
  console.log('doing awesome stuff');
}
performance.mark('starting_awesome_script');
+ performance.measure('awesome_script', 'starting_awesome_script', 'starting_awesome_script');

• 取出時間

const measures = performance.getEntriesByType('measure');
measures.forEach(measureItem => {
  console.log(`${measureItem.name}: ${measureItem.duration}`);
});

上報數據

• 一般可以考慮在用戶準備卸載頁面時上報，毫無疑問這個時間點不會干擾用戶在當前頁的操作。
  但是如果上報耗時很長，會影響用戶跳轉到下一頁的體驗。可以使用 navigator.sendBeacon。

window.addEventListener('unload', function() {
  // 注意 performance.getEntries 會取當前頁所有資源包括頁面本身的性能信息
  // 注意 數據體量問題
  let rumData = new FormData();
  rumData.append('entries', JSON.stringify(performance.getEntries()));

  // 是否支持
  if('sendBeacon' in navigator) {
    // Beacon 發起請求
    if(navigator.sendBeacon(endpoint, rumData)) {
      // sendBeacon 發送成功
    } else {
      // sendBeacon 發送失敗! 使用 XHR or fetch 代替
    }
  } else {
    // sendBeacon 不支持! 使用 XHR or fetch 代替
  }
}, false);

• 傳統解決方案，在 unload 中處理

1. 因爲頁面卸載了，就不會關心異步 ajax 的完成接收，所以一般使用同步 ajax 來阻塞頁面卸載。
2. 創建圖片，用 img src 來發送請求。
3. setTimeout(ajax, 0)。

• navigator.sendBeacon 解決了以上問題

1. 頁面卸載了，依舊可以異步請求。
2. 不阻塞當前頁的卸載。
3. 使用簡單。

總結

• Navigation Timing 收集 HTML 文檔性能指標。

1. performance.timing 常用、解決兼容性
2. performance.getEntriesByType('navigation')[0] 新標準，精度高內容更詳細，兼容性較差

• Resource Timing 收集 HTML 依賴的資源的性能指標，如CSS、JS、圖片、字體等。

1. performance.getEntriesByType('resource') 新老一樣使用，新標準做了擴展。

• User timing 收集用戶自定義

1. performance.getEntriesByType('measure') 可以考慮，用來對 FMP 打點。

參考

1. HTML DOM標準
2. W3C Navigation Timing
3. Navigation Timing Level 2
4. User Timing Level 2
5. boomerang
6. commercial boomerang
7. Resource Timing practical tips
8. 前端監控實踐——FMP的智能獲取算法
9. Assessing Loading Performance in Real Life with Navigation and Resource Timing
10. Navigator.sendBeacon
11. performance-bookmarklet
12. waterfall.js