前端頁面性能及其分析工具

本文結(jié)合谷歌官方工具 Lighthouse，分析了最新的前端頁面性能評分標(biāo)準(zhǔn)，幫助大家更好地理解各項性能指標(biāo)，以提升并優(yōu)化相關(guān)的前端項目。

前端頁面的性能，一直都是大家持續(xù)關(guān)注的一個領(lǐng)域，因?yàn)橛脩舻牧舸媛屎晚撁婕虞d性能息息相關(guān)。根據(jù)google做出的數(shù)據(jù)統(tǒng)計，頁面訪問時長從1s增加到3s，用戶跳出率增加32%。

對于前端頁面性能的評估，一般是兩種形式：一種是使用性能分析工具，在線對網(wǎng)頁各項指標(biāo)進(jìn)行打分評估；一種是使用性能監(jiān)控，通過 performance api 或者自定義的埋點(diǎn)上報用戶網(wǎng)絡(luò)真實(shí)的訪問情況，然后進(jìn)行統(tǒng)計分析。

雖然通過統(tǒng)計用戶的數(shù)據(jù)更加真實(shí)，但是為了對頁面性能能夠有一個統(tǒng)一的量化標(biāo)準(zhǔn)，我們往往選擇使用標(biāo)準(zhǔn)的打分工具對頁面的性能進(jìn)行評估。

性能分析初期，我們會從 chrome 的開發(fā)者工具對網(wǎng)頁進(jìn)行分析，包括查看 load 和 DOMContentLoaded 等事件觸發(fā)的時間。后來又有了一系列的性能分析工具，例如 webpage analyzer、WebPageTest、Yslow等。

現(xiàn)在由于google官方已經(jīng)將他們自己開發(fā)的 Lighthouse 嵌入到開發(fā)者工具的選項卡中，因此我們就把 Lighthouse 當(dāng)做是標(biāo)準(zhǔn)評估工具。

Lighthouse 是一款開源的web頁面性能分析工具，并且會給出頁面最佳實(shí)踐的一些相關(guān)建議。除了可以直接在 chrome DevTools 中使用外，也支持使用瀏覽器插件（chrome和Firefox）或者npm包（node api或者CLI）。

像google的網(wǎng)頁?measure以及?PageSpeed Insight工具都是調(diào)用的 Lighthouse 對頁面進(jìn)行分析。

1. Lighthouse 的迭代與性能指標(biāo)變化

Lighthouse 第一個開源的版本可以追溯到2016年，目前（2020年10月）最新的版本是6.4.1，已經(jīng)迭代89個版本。而在這幾年中 Lighthouse 對于性能指標(biāo)的選取也一直在更新。

google在最新的6.X版本中，相比于5.X版本，更新了三個新的性能指標(biāo)：去掉了 FMP(First Meaningful Paint)、FCI(First CPU Idle) 和 mpFID(Max Potential First Input Delay)；

加入了 TBT(Total Blocking Time)、LCP(Largest Contentful Paint) 和 CLS(Cumulative Layout Shift)。后文會針對這些指標(biāo)進(jìn)行詳細(xì)的講解。

之前5.X版本的Lighthouse

現(xiàn)在的Lighthouse(6.X版本)

2.? 如何計算頁面性能分?jǐn)?shù)

如下圖所示，在頁面性能部分，Lighthouse 會綜合目前的6個關(guān)鍵指標(biāo)的表現(xiàn)情況，計算出頁面的性能分?jǐn)?shù)。

以最新的6.X計算方法來看，每個性能指標(biāo)的數(shù)值會對應(yīng)一個該指標(biāo)的分?jǐn)?shù)。例如上圖中的FCP、SI、LCP、TTI、TBT、CLS等數(shù)值，對應(yīng)的單項分?jǐn)?shù)就依次為78、62、37、5、99、92分。一般來說數(shù)值越小該指標(biāo)分?jǐn)?shù)越高。

而這6個指標(biāo)對應(yīng)的權(quán)重分別為15%、15%、25%、15%、25%、5%，通過加權(quán)平均計算出性能總分為圖中的60分。

如果想知道每個指標(biāo)數(shù)值與其對應(yīng)分?jǐn)?shù)的具體計算方法，可以參考文章末尾的資料5和6。

在6.0版本的 Lighthouse 中，被去掉的關(guān)鍵性能指標(biāo)分別是FMP（首次有意義的渲染幀）、FCI（首次CPU空閑）以及用戶mpFID（潛在最大首次輸入延遲）。

下面我們從這三個被廢棄指標(biāo)的定義開始切入，更好的理解現(xiàn)在版本的指標(biāo)選取依據(jù)。

1.? 什么是 FMP，和 FCP 有什么區(qū)別

說起FMP之前，我們必須要先介紹一下 First Contentful Paint（FCP）：首次內(nèi)容渲染時間。

如其名所示，只要首次觸發(fā)了瀏覽器的 The First Page Paint 事件，此刻的時間點(diǎn)就是FCP。但此時渲染的不一定是重要的頁面信息，比如僅僅是繪制了一個頭部的 action bar 等，甚至不一定會渲染出可見的元素。雖然在Lighthouse6.0中得到了保留，但對性能得分的權(quán)重從23%降低到15%。

因此，F(xiàn)CP 不能作為一個從用戶視角準(zhǔn)確衡量頁面性能好壞的指標(biāo)。

在這個背景下，F(xiàn)MP（First Meaningful Paint：首次有意義的渲染幀）應(yīng)運(yùn)而生。根據(jù)官方的定義，F(xiàn)MP 是指從頁面加載開始，到大部分或者主要內(nèi)容已經(jīng)在首屏上渲染的時間點(diǎn)。

那么 FMP 時間點(diǎn)是怎么確認(rèn)的呢，我們先看下最基本的計算方法：

我們首先計算布局對象（layout objects）數(shù)量（使用 LayoutAnalyzer 測試計算，詳見資料17）。

根據(jù)下圖可以看出，頁面加載的過程其實(shí)就是布局對象逐步進(jìn)入 layout tree 并進(jìn)行渲染的過程。

layoutAnalyzer 會收集 layout objects 數(shù)量，有一個計數(shù)器叫做?

LayoutObjectsThatHadNeverHadLayout，即首次新增的 layout objects 的個數(shù)。

通過測試發(fā)現(xiàn)相比于其他計數(shù)器，它變化最大的時刻，往往就是頁面最重要的元素渲染了的時刻。

因此 FMP 指標(biāo)的計算方法為：LayoutObjectsThatHadNeverHadLayout（新增的布局對象）發(fā)生變化最大的下一個時刻（paint that follows biggest layout change）。

當(dāng)然，也存在一些場景不適用上述的情況：

針對場景1，F(xiàn)MP 通過引入了 layout signifcance（布局重要度）的概念來解決該問題；針對場景2，F(xiàn)MP 通過推遲統(tǒng)計的時間，來讓指標(biāo)更加合理反映頁面的情況。更加詳細(xì)的解決方案可以參考資料18。

google也針對上述 FMP 的不同場景對近200個頁面做了試驗(yàn)，通過人工看頁面截圖，與用戶感受到的 FMP 準(zhǔn)確度做對比，結(jié)果如下：

不過最終 FMP 在6.0的時候被廢棄，主要是因?yàn)橐韵聝牲c(diǎn)：

2.?代替 FMP 的 LCP 來了

上一個小章節(jié)中提到的了 FCP、FMP 的不足，因此W3C的性能小組也一直在想找一個合適的指標(biāo)，更加真實(shí)反映用戶看到頁面主要內(nèi)容的時間。

有時候簡單點(diǎn)也許會更好（Sometimes simpler is better），根據(jù)多方關(guān)于頁面性能的討論，終于找到了一個更加準(zhǔn)確衡量頁面主要內(nèi)容是否加載的方法，那就是 LCP（Largest Contentful Paint）。

LCP 指的是在視窗內(nèi)，最大的內(nèi)容元素被渲染的時間。這個指標(biāo)在 Lighthouse 6.0中也正式加入，并且在最終性能評分中，有高達(dá)25%的權(quán)重。

LCP 應(yīng)該是除了FCP以外最容易定義的指標(biāo)，從定義可以看出，關(guān)鍵點(diǎn)就2個，選取哪些元素進(jìn)行比較和如何確定元素的大小。

根據(jù)官方文檔，下列元素會被納入Largest Contentful 元素的考慮范圍：

那我們?nèi)绾未_定元素的大??？主要是以下 4 個規(guī)則：

google對該指標(biāo)的評價如下：LCP 是一個十分重要并且以用戶感受為中心的指標(biāo)；它反映了感知層面上頁面的加載速度；它標(biāo)記了頁面主要內(nèi)容中最大內(nèi)容元素加載完成的時間點(diǎn)；LCP 較短的頁面能夠讓用戶更快感覺到頁面是可用的。

3.?被廢棄的 FCI 是什么，為什么和 TTI 聯(lián)系這么緊密

FCI（First Cpu Idle：首次CPU空閑），這個指標(biāo)用來衡量一個頁面需要多久才能達(dá)到 minimally interactive（最低限度交互）的標(biāo)準(zhǔn)。

而最低可交互的確認(rèn)需要同時滿足以下兩個條件：

TTI（Time To Interactive：頁面可交互時間），指的是頁面達(dá)到完全可交互狀態(tài)所需要的時間。

完全可交互指的是同時滿足下面三個條件：

2017年，F(xiàn)irst Interactive 指標(biāo)被分成了 First Interactive 和 Consistently Interactive 兩個指標(biāo)；第二年7月，F(xiàn)irst Interactive指標(biāo)改名為 FCI，同時 Consistently Interactive 改名為 TTI 。可見，F(xiàn)CI 和 TTI 這兩個指標(biāo)是一對反映用戶交互響應(yīng)的指標(biāo)。

那么最低可交互和完全可交互是怎么計算的呢？在介紹具體的計算方法之前，我們需要知道這兩個指標(biāo)都是模糊的并且在不同的情況下可以持續(xù)被優(yōu)化改進(jìn)的。

• FCI 的最低限度可交互時間

在主線程的時間線中，從 FMP 開始且某個任務(wù)結(jié)束后，尋找到長度為 f(t) 的時間窗口 W。如果 W 滿足在其任意時間段內(nèi)，沒有長度大于250ms的連續(xù)任務(wù)集，且前后1s內(nèi)都沒有長任務(wù)（js執(zhí)行時間超過50ms的任務(wù)為長任務(wù)），那么該任務(wù)結(jié)束的時刻就是我們定義的 FCI 。其中 f(t) = 4 * e^(-0.045 * t) + 1。

下圖紅框中所指的時間點(diǎn)即為 FCI

具體的推導(dǎo)過程可以參考資料11，可以更深刻的理解到為什么 FCI 是模糊的一個概念。

• TTI 的完全可交互時間

從網(wǎng)絡(luò)和主線程的時間線中，找到第一個5s的窗口期 W，在 W 時間段滿足：任意時刻沒有超過兩個同時進(jìn)行中的網(wǎng)絡(luò)請求、沒有超過50ms的長任務(wù)。則W前的最后一個長任務(wù)結(jié)束時刻，就是我們說的 TTI。

下圖紅框中所指的時間點(diǎn)即為 TTI：

盡管有些人指出，F(xiàn)CI 在某些時候比 TTI 更有意義，但是它們之間的差異還是不足以讓 Lighthouse 保留兩個相似的指標(biāo)。

因此在 Lighthouse 6.0里，最終選擇還是使用 TTI 來取代 FCI。

4. mpFID 與新增的 TBT 指標(biāo)

mpFID（max potential First Input Delay）指的是從用戶輸入到頁面真正開始處理事件回調(diào)的潛在（可能）最大延遲時間。

mpFID 具體的計算方法，是從以 FCP 為開始到以 TTI 為結(jié)束的這段時間里，選擇其中js執(zhí)行時間最長的任務(wù)，用它消耗的時間再減去50ms。

但是 mpFID 表示的只是一個最大延遲時間，與用戶實(shí)際輸入的延遲時間是有差距的，用戶在不同時刻的輸入得到的 FID 也會不同，因此 mpFID 并不能真實(shí)反映頁面對用戶輸入的響應(yīng)時間。

在5.X版本計算性能分?jǐn)?shù)的時候，mpFID 權(quán)重為0，并沒有參與評分。雖然這個指標(biāo)不再顯示在報告中，但其實(shí)在JSON數(shù)據(jù)中還有保留，而 mpFID 也是官方依然認(rèn)可的一個關(guān)鍵用戶體驗(yàn)指標(biāo)。

那究竟什么是 TBT（Total Blocking Time），為什么要在性能報告中選擇用它代替 FID 呢？

先看下定義：TBT 指的是頁面響應(yīng)用戶輸入時，已經(jīng)被阻塞的時間總和。

具體的計算方法比較明確，統(tǒng)計從 FCP 到 TTI 之間的所有長任務(wù)，并將它們的阻塞部分時間進(jìn)行求和，即為 TBT。其中阻塞部分時間指的是長任務(wù)執(zhí)行時間超過50ms的部分，例如一個長任務(wù)執(zhí)行了70ms，那么阻塞時間就是20ms。

可以看出，TBT 相比于 mpFID 是一個更加穩(wěn)定的指標(biāo)，相較而言能更加真實(shí)地反映頁面對于用戶輸入的響應(yīng)平均延時。

5.? 新增的CLS

CLS (Cumulative Layout Shift：累積布局變化)，它是用來衡量視覺界面穩(wěn)定性的一個指標(biāo)。

這個數(shù)據(jù)的獲取是由 Layout Instability API（詳見參考資料14）提供的，計算方法如下：

layout shift score = impact fraction * distance fraction

其中 impact fraction 指的是對整個視窗的多少造成了影響。例如下圖中的文字占整個視窗的50%，并且下一幀比上一幀向下移動了25%，因此對整個頁面的75%造成了影響，因此 impact fraction 為0.75。

distance fraction 比較好理解，就是發(fā)生變化距離占整個視窗的比例，比如上面的例子，移動25%即 distance fraction 為0.25。

綜上，圖示demo的 CLS 值即為0.75 * 0.25 = 0.1875。更詳細(xì)的計算方法可以參考資料13、14。

舉一個 CLS 實(shí)際影響用戶體驗(yàn)的例子：如下圖所示，用戶想點(diǎn)取消按鈕，結(jié)果頁面突然發(fā)生了布局變化，確認(rèn)按鈕出現(xiàn)在了之前取消的位置…

可見，CLS 是更從用戶體驗(yàn)出發(fā)，而新增的一個性能評判指標(biāo)。

目前 CLS 作為新晉指標(biāo)所占權(quán)重還不大，僅為5%，但是 Lighthouse 已經(jīng)在考慮下一個大版本中增加其權(quán)重了。

6. 一直都在的 Speed Index

速度指數(shù) Speed Index（SI）是用來衡量頁面可見內(nèi)容填充快慢的指標(biāo)，計算過程使用是開源工具 speedline（資料16）。

speedline 通過對頁面進(jìn)行視頻錄制，并統(tǒng)計首幀與最后一幀變化的時間差來計算 speed Index 的值。

值得一提的是 SI 的最終分?jǐn)?shù)，會通過和數(shù)據(jù)庫中真實(shí)網(wǎng)站的 SI 進(jìn)行比較算出。目前 SI 分?jǐn)?shù)與得分標(biāo)準(zhǔn)如下表所示：

回顧上述指標(biāo)的更替過程我們可以發(fā)現(xiàn)，不論是從 FMP 到 LCP、FCI 到 TTI 還是 FID 到 TBT，目前在性能指標(biāo)的選取上，都已經(jīng)在朝著更加穩(wěn)定的方向前進(jìn)：指標(biāo)的定義越來越簡明清晰，并且計算的方式也趨于標(biāo)準(zhǔn)化。

但是我們也應(yīng)該知道這里沒有銀彈，每個指標(biāo)都會有其局限性。在很多場景下，并不能認(rèn)為得分低，就一定代表著頁面的體驗(yàn)差。而我們也只有了解了這些指標(biāo)的背后原理，才能更加科學(xué)地結(jié)合性能得分對頁面做出評價。

1. Find out how you stack up to new industry benchmarks for mobile page speed?

2. Performance.timing Api?

3. What's New in Lighthouse 6.0

4. Web Vitals

5. Lighthouse Scoring Calculator

6. Lighthouse performance scoring

7. WebPageTest Demo

8. Time to First Meaningful Paint

9. First Interactive and Consistently Interactive

10. Largest Contentful Paint (LCP)

11. First Interactive and Consistently Interactive

12. How Mercado Libre optimized for Web Vitals (TBT/FID)

13. Cumulative Layout Shift (CLS)

14. layout-instability

15. Speed Index

16. speedline

17. Layout Analyzer

18. Time to First Meaningful Paint