頁面加載性能之常見的性能指標

咱們已經知道性能的重要性，但當咱們討論性能的時候，讓一個網頁變得跟快，具體是指哪些？

事實上性能是相對的:

• 一個網站可能一個用戶感受很快，但對其餘用戶感受很慢
• 兩個網站的loading結束時間是同樣的，但其中一個你感受比另外一個要快
• 一個網站加載的很快，但頁面長時間不可交互

因此在討論性能的時候，精確的、可量化的指標很重要。

雖說某一個指標多是客觀的，可量化的，但對咱們實際去評價性能可能沒什麼幫助。

定義指標

以往，開發者都經過 load 事件來衡量性能。load 是頁面生命週期中的明確的時刻，但這個時刻用戶並不關心。

舉個例子，服務器可能很快的就返回了一個很小的頁面，但在 load 事件以後推遲了若干秒來獲取內容並展現。雖然這種頁面 load 很快，但實際上用戶看到內容則是在以後的若干秒，load 的時間跟用戶實際感知的不同。

爲了確保指標與用戶相關，Chrome團隊圍繞一系列問題定製了框架:

• 是否發生了: 跳轉是否成功？服務器是否有響應？
• 是否有用: 是否渲染了足夠的內容供用戶查看？
• 是否可用: 用戶是否可交互？或者頁面卡住？
• 是否用的爽: 交互是否順暢？天然？無延後？無卡頓？

指標的分類

• 感知加載速度: 頁面加載完並給用戶呈現了展現內容
• 加載響應: 頁面加載完到js執行
• 運行時響應: 頁面加載完以後，到頁面可交互
• 視覺穩定性: 頁面上是否有干擾元素，例如預期以外的滾動或者移動
• 流暢性: transition和animation是否流暢，幀率是否保持在60

鑑於以上的全部分類，咱們應該清楚地意識到沒有單一的指標能夠捕獲全部性能特徵。

常見的性能指標

• First contentful paint (FCP): 從頁面開始加載，到頁面任意內容渲染在屏幕上的時間。(實驗屬性，現場數據)
• Largest contentful paint (LCP): 從頁面加載開始，到頁面上最大的文本塊或者圖片元素渲染在屏幕上的時間。(實驗數據，現場數據)
• First input delay (FID): 用戶第一個交互行爲，好比點擊連接、點擊按鈕等，到瀏覽器實際響應此次交互的時間。(現場數據)
• Time to Interactive (TTI): 從頁面開始加載，到內容呈現，初始js加載完成，再到能夠馬上響應用戶交互的時間。(實驗數據)
• Total blocking time (TBT): 在FCP和TTI之間的時間，即頁面可見到可交互的時間，表明了主線程被阻塞沒法響應用戶交互。（實驗數據）
• Cumulative layout shift (CLS): 從頁面開始加載，到頁面生命週期變爲隱藏之間的全部意外的佈局變化的累計分數。(實驗數據，現場數據)

以上指標能夠檢測大部分的與用戶相關的性能影響，但也不表明所有。

在某些狀況下，會引入新的指標來覆蓋缺失的區域，但其餘狀況下最好的指標是針對你的網站量身定製的。

自定義指標

有時候你的站點可能須要一些額外的指標來捕獲整個性能圖。舉個例子，LCP的指標，若是最大的文本塊或者圖片元素不是你的網站的主要內容，這個指標則失去了本來的意義。

爲了應對這些狀況，Web性能工做小組定製了一些標準的底層API，幫你能夠實施本身的自定義指標:

• User Timing API
• Long Tasks API
• Element Timing API
• Navigation Timing API
• Resource Timing API
• Server timing

總結

本文只是一個常見性能指標的一個簡要介紹，後面會針對每個指標作更詳細的介紹，以及在項目中的實際應用。

參考

https://web.dev/user-centric-...