本文結合Google官方工具 Lighthouse 分析最新的前端頁面性能評分標準，幫助大家更好地理解各種性能指標，以改進和優(yōu)化相關前端項目。

前端頁面性能一直是大家持續(xù)關注的話題，因為用戶留存率與頁面加載性能密切相關。根據Google的數據統(tǒng)計，當頁面訪問時長從1秒增加到3秒時，用戶跳出率會增加32%。

評估前端頁面性能通常有兩種形式：一是使用性能分析工具在線對各項指標進行評分和評估；二是使用性能監(jiān)控，通過 Performance API 或自定義跟蹤點報告用戶的真實網絡訪問情況，然后進行統(tǒng)計分析。

雖然統(tǒng)計收集用戶數據更貼近實際，但為了對頁面性能評估有一個統(tǒng)一的量化標準，我們通常選擇使用標準評分工具來評估頁面性能。

在性能分析的早期階段，我們會使用Chrome開發(fā)者工具分析網頁，包括查看 load 和DOMContentLoaded等事件觸發(fā)的時間。后來出現了一系列性能分析工具，如Webpage Analyzer、WebPageTest、YSlow等。

現在Google已經正式將其自主開發(fā)的Lighthouse嵌入到開發(fā)者工具標簽中，我們將Lighthouse視為標準評估工具。

Lighthouse 是一個開源的網頁性能分析工具，提供了關于頁面最佳實踐的相關建議。除了可以直接在Chrome DevTools中使用外，它還支持瀏覽器擴展（Chrome和Firefox）或npm包（Node API或CLI）。

像 Google 的 Web measure 和 PageSpeed Insight等工具都使用Lighthouse來分析頁面。

1.Lighthouse 的迭代和性能指標變化

Lighthouse 的第一個開源版本可以追溯到2016年，截至2020年10月，最新版本是6.4.1，總共經歷了89次迭代。多年來，Lighthouse一直在更新其性能指標的選擇。

在最新的6.x版本中，與5.x版本相比，Google引入了三個新的性能指標：移除了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）。以下部分將對這些指標進行詳細解釋。

2.如何計算頁面性能得分

如下圖所示，在頁面性能部分，Lighthouse將評估6個關鍵指標的性能，并計算頁面的性能得分。

根據最新的6.x計算方法，每個性能指標對應一個分數。例如，在上圖中，FCP、SI、LCP、TTI、TBT和CLS的值分別對應78、62、37、5、99和92的單項得分。通常來說，指標值越小，其對應的得分越高。

這六個指標分別被賦予15%、15%、25%、15%、25%和5%的權重。總體性能得分的計算如圖所示 — 通過加權平均得到總分60分。

每個指標值如何對應其各自的得分計算方法的具體細節(jié)可以在文章末尾的參考文獻5和6中找到。

在Lighthouse v6.0版本中, 移除了三個關鍵性能指標: FMP(First Meaningful Paint)、FCI(First CPU Idle) 和 mpFID(Maximum Potential First Input Delay)。

我們將首先examine這三個已棄用指標的定義,以better理解當前版本如何選擇其指標。

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

談到FMP,我們必須首先介紹First Contentful Paint (FCP):第一次內容渲染的時間。

顧名思義,只要瀏覽器第一次觸發(fā)The First Page Paint事件,這一刻就是FCP。然而,此時渲染的內容不一定是重要的頁面信息,比如只繪制了一個頭部操作欄或甚至可見元素。雖然它在Lighthouse 6.0中被保留,但其在性能得分中的權重從23%降至15%。

因此,從用戶的角度來看,FCP不能作為頁面性能的準確指標。

在這種背景下,FMP(First Meaningful Paint)應運而生。根據官方定義,FMP指的是自頁面加載開始以來,初始屏幕上大部分或主要內容已被渲染的時間點。

那么FMP的計時如何確認?讓我們先看最基本的計算方法:

我們首先計算布局對象的數量(使用LayoutAnalyzer進行測試計算;參見參考文獻17)。

如下圖所示,可以看到頁面加載過程是布局對象逐步進入布局樹并渲染的過程。

layoutAnalyzer 收集布局對象的數量,有一個計數器叫 LayoutObjectsThatHadNeverHadLayout,代表新增加的布局對象的數量。

通過測試發(fā)現,與其他計數器相比,它變化最大的時刻往往是頁面上最重要的元素被渲染的時候。

因此,FMP指標的計算方法是LayoutObjectsThatHadNeverHadLayout(新增布局對象)經歷最大變化后的下一刻(跟隨最大布局變化的繪制)。

當然,也有一些情況下上述情況不適用:

a) 如果頁面很長,可能在第一屏內添加的不可見布局對象比可見的多。在這種情況下,FMP變得不準確。

b) 在加載網絡字體的情況下,文本使用fallback字體進行布局但默認在loadstart后3秒內不繪制;這也會影響FMP的計算。

對于場景1,FMP引入了"布局重要性"的概念來解決這個問題;對于場景2,FMP延遲統(tǒng)計以使指標更準確地反映頁面狀況。更詳細的解決方案請參考參考文獻18。

然而,FMP最終在6.0版本中被棄用,主要是由于以下兩個原因:

• 在生產環(huán)境中,FMP對頁面上的微小變化過于敏感,容易導致結果不一致。
• 這個指標的定義過于依賴瀏覽器的具體實現細節(jié),缺乏標準化的參考。

2.LCP的到來取代了FMP

前一節(jié)提到了FCP和FMP的缺點,所以W3C的性能組一直在思考找到一個合適的指標,更準確地反映用戶看到頁面主要內容的時間。

有時候更簡單更好。基于各方面關于頁面性能的討論,終于找到了一個更準確的方法來衡量頁面的主要內容是否已加載,這就是 LCP(Largest Contentful Paint)。

LCP指的是視口內最大內容元素渲染的時間。這個指標在Lighthouse 6.0中正式引入,在最終性能得分中占據高達25%的權重。

LCP 應該是除FCP之外最容易定義的指標之一。從其定義來看,有兩個關鍵點:選擇哪些元素進行比較,以及如何確定它們的大小。

根據官方文檔,以下元素將被視為 Largest Contentful Element 的一部分:

• <img>
• <svg>中的<image>
• <video>
• 通過url()函數加載背景圖片的元素
• 包含文本節(jié)點或內聯文本子元素的塊級元素

我們如何確定一個元素的大小?主要基于這四條規(guī)則:

• 視口內可見元素的大小;如果它們超出或被裁剪或被遮擋,則不計入元素大小。
• 對于圖像元素,大小由Min(實際大小,原始大小)決定。
• 對于文本元素,只考慮覆蓋所有文本的最小矩形區(qū)域。
• 對于所有元素,不包括margin、padding、border等在計算中。

Google對這個指標的評價如下:LCP是一個非常重要的以用戶為中心的指標;它反映了用戶層面感知的加載速度;它標志著主要內容中最大內容元素的加載完成;LCP時間越短,用戶感知頁面可用的速度越快。

3.被放棄的FCI是什么,為什么它與TTI如此密切相關?

FCI(First CPU Idle:首次CPU空閑),這個指標用來衡量一個頁面達到最小可交互標準需要多長時間。

最小可交互性的確認需要同時滿足以下兩個條件:

a) 屏幕上的大多數UI元素是可交互的

b) 頁面對用戶輸入的響應平均在合理范圍內

TTI(Time To Interactive:頁面可交互時間),指頁面達到完全可交互狀態(tài)所需的時間。

完全可交互意味著同時滿足以下三個條件:

a) FCP之后,頁面上已經渲染了有用的內容

b) 為最可見的頁面元素注冊了事件回調

c) 頁面對用戶交互的響應在50ms以內

2017年,First Interactive 指標被分為兩個指標: First Interactive 和 Consistently Interactive; 次年7月, First Interactive被重命名為 FCI,而Consistently Interactive 被重命名為TTI。可以看出,FCI和TTI是兩個反映用戶交互響應的指標。

那么,最小可交互性和完全可交互性是如何計算的?在介紹具體計算方法之前,我們需要知道,這兩個指標都是模糊的,可以在不同情況下不斷優(yōu)化和改進。

FCI的最小可交互時間

在主線程的時間線上,從FMP開始直到某個任務結束之后,找到一個長度為f(t)的時間窗口W。如果W滿足在其持續(xù)時間內任何時刻都沒有連續(xù)超過250ms的任務集,并且在其結束前后1秒內沒有長任務(JS執(zhí)行時間超過50ms的任務)。那個任務結束的時刻就是我們定義的FCI。其中f(t)=4e^(-0.045t)+1。

下圖中紅框指示的時間點就是FCI。

TTI完全可交互時間

從網絡和主線程的時間線上,找到第一個5s窗口期 W。在 W 期間,應滿足以下條件:任何時刻并發(fā)網絡請求不超過兩個,且沒有超過50ms的長任務。W 之前最后一個長任務結束的時間就是我們所說的TTI。

下圖中紅框指示的時間點就是TTI:

盡管有人指出FCI在某些時候比TTI更有意義,但它們之間的區(qū)別仍然不足以證明 Lighthouse 保留兩個相似的指標。

因此,在Lighthouse 6.0中,最終決定使用TTI代替FCI。

4.mpFID和新增的TBT指標

mpFID(max potential First Input Delay)指的是頁面上從用戶輸入到實際開始處理事件回調的潛在最大延遲時間。

mpFID的具體計算方法是選擇從FCP到TTI之間JavaScript執(zhí)行時間最長的任務,然后從該任務消耗的時間中減去50ms。

然而,mpFID只代表一個最大延遲時間,可能與用戶實際體驗到的延遲時間不同。用戶在不同時間獲得的FID也會有所不同。因此,mpFID并不能真實反映頁面對用戶輸入的響應時間。

在5.x版本計算性能得分時,mpFID權重為0,不參與打分。雖然這個指標不再出現在報告中,但它仍然保留在JSON數據中,仍然是官方認可的關鍵用戶體驗指標。

那么,TBT(Total Blocking Time)到底是什么,為什么在性能報告中選擇它而不是FID呢?

我們先來看看它的定義:TBT指的是頁面在響應用戶輸入時被阻塞的總累計時間。

具體計算方法相當清晰 — 將FCP和TTI之間的所有長任務加起來,并將它們的阻塞部分的時間相加,就得到了TBT。阻塞部分的時間指的是長任務執(zhí)行超過50ms的任何部分;例如,如果一個長任務總共花費70ms,那么阻塞時間就是20ms。

可以看出,與mpFID相比,TBT是一個更穩(wěn)定的指標,能更準確地反映頁面對用戶輸入的平均延遲響應。

5. 新增的CLS

CLS(Cumulative Layout Shift),是用來衡量視覺界面穩(wěn)定性的指標。

數據來源于Layout Instability API(參見參考文獻14),計算方法如下:

layout shift score = impact fraction * distance fraction

布局移動分數 = 影響分數 * 距離分數

其中impact fraction指的是對整個視口的影響程度。例如,在下圖中,如果文本占整個視口的50%,在下一幀中相對于上一幀向下移動了25%,那么它影響了整個頁面的75%。因此,impact fraction為0.75。

distance fraction相對容易理解,它指的是改變的距離占整個視口的比例。例如,在上述案例中,移動25%意味 著distance fraction 為 0.25。

因此,圖示demo的CLS值計算為0.75 * 0.25 = 0.1875。更詳細的計算方法可以參考參考文獻13和14。

一個說明CLS如何影響用戶體驗的例子:如下圖所示,當用戶試圖點擊取消按鈕時,突然頁面發(fā)生布局偏移,確認按鈕出現在之前取消按鈕的位置...

可以看出,CLS是一個更加以用戶為中心的新性能評估指標。

目前,CLS作為一個新增指標權重較小,只有5%,但Lighthouse已經在考慮在下一個主要版本中增加其權重。

6. 一直存在的Speed Index

Speed Index(SI)用于衡量可見內容填充頁面的速度,計算過程使用開源工具Speedline(參考文獻16)。

Speedline記錄頁面的視頻,并通過測量第一幀和最后一幀之間的時間差來計算Speed Index的值。

值得一提的是,SI的最終得分將通過與數據庫中真實網站的SI值進行比較來計算。目前,SI得分和評分標準如下表所示:

回顧上述指標替換的過程,我們可以看到,無論是從FMP到LCP,FCI到TTI,還是FID到TBT,目前在性能指標的選擇上,都在向更穩(wěn)定的方向發(fā)展:指標的定義越來越簡潔明了,計算方法也趨向標準化。

然而,我們也應該知道,這里沒有銀彈;每個指標都會有其局限性。在許多場景下,低分并不一定意味著頁面體驗差。只有理解這些指標背后的原理,我們才能基于性能得分更科學地評估頁面。