作為開發我們都知道，頁面效能很重要，一個效能良好的頁面可以給使用者帶來非常好的使用者體驗。那麼，怎麼能知道自己寫的頁面效能是好是壞呢？
Lighthouse 是Chrome提供給開發者用來測量頁面效能的工具。透過Lighthouse，我們可以很清楚的看到頁面的效能情況。
當前頁面的效能總體得分為96分，是非常優異的。
這個分數是怎麼得出來的？這些指標又跟分數有什麼樣的關係呢？讓我們來一探究竟。
Lighthouse效能分數的計算
上圖中提到了Lighthouse是基於FCP (First Contentful Paint)、SI (Speed Index)、 LCP (Largest Contentful Paint)、 TBT (Total Blocking Time) 和 CLS (Cumulative Layout Shift)這5個指標來計算效能得分的。
點選“檢視計算機”，可以看到以下頁面：
頁面中包含了效能的指標、資料(value)、得分(Metric Score)以及權重(Weighting)，而最終的效能得分就是這些指標分數的加權平均值。即（從上往下開始計算）：(100*0.1 + 95*0.1 + 84*0.25 + 100 * 0.3 + 100 * 0.25) / (0.1+ 0.1+ 0.25+0.3+0.25) 約等於 96(四捨五入)。
加權平均值： 即將各數值乘以相應的權數，然後加總求和得到總體值，再除以總的單位數。點選瞭解更多
指標的定義
Web指標是Google開創的一項新計劃，旨在為網路質量訊號提供統一指導，這些訊號對於提供出色的網路使用者體驗至關重要。
指標定義的框架
長久以來，網路效能都是透過load事件進行測量的。但是透過這個事件獲取到的資料，跟實際的使用者體驗並不是很相符。
舉個例子：伺服器可以透過載入一個“最小”的頁面來進行響應，響應完成之後，再透過非同步獲取主要的頁面資訊進行展示。透過load事件進行測量，效能上看起來很優秀，但是使用者實際上看到頁面的時候時間可能變得更長了(因為多了一次請求)。這明顯跟真實的使用者體驗不匹配。
為了能更準確地測量使用者的網頁效能體驗，Chrome團隊成員與W3C Web效能工作組共同合作，圍繞幾個關鍵問題構建出了指標的框架：
可以根據這幾個點去對指標進行定義，這些都是跟使用者息息相關的。
指標型別
使用者對效能感知相關的指標可以分為以下幾類：
-
Perceived load speed 感知載入速度： 頁面在螢幕上載入並渲染出所有視覺元素的速度。
-
Load responsiveness 載入響應度： 為了使元件對使用者互動作出快速響應，頁面載入和執行任何所需 JavaScript 程式碼的速度。
-
Runtime responsiveness 執行時響應度： 頁面在載入後，對使用者互動的響應速度。
-
Visual stability 視覺穩定性： 頁面上的元素是否會出現讓使用者感到意外的偏移，並對使用者互動造成潛在的干擾？
-
Smoothness 平滑度： 過渡和動畫在頁面狀態切換的過程中是否具有穩定的幀速率和順滑的流動性？
透過上述的效能指標型別表明，只用一項指標去捕獲頁面的所有效能特徵是遠遠不夠的。
核心指標
多年來，Google 提供了許多效能測量和效能報告工具，導致一些開發者發現大量的工具和指標令人應接不暇。
開發者想要了解的是他們提供給使用者的體驗質量是怎樣的，並非每個人都需要成為效能專家。我們並不需要去了解所有的指標，只需要專注於一些重點的指標就可以了。
核心Web指標的構成會隨著時間的推移而發展 。當前針對2020年的指標構成側重於使用者體驗的三個方面——載入效能、互動性和視覺穩定性——幷包括以下指標（及各指標相應的閾值）：
這3個指標可以作為網站的一組通用指標，但並不是說我們只需要關注以上這幾個核心指標就可以了。在某些情況下，我們將引入新指標來查漏補缺，來捕獲完整的效能全貌，能夠體現出你網頁的真實使用者體驗才是最佳的指標。
其他一些重要的指標：
-
First contentful paint 首次內容繪製 (FCP)：測量頁面從開始載入到頁面內容的任何部分在螢幕上完成渲染的時間。
-
Time to Interactive 可互動時間 (TTI)：測量頁面從開始載入到視覺上完成渲染、初始指令碼（如果有的話）完成載入，並能夠快速、可靠地響應使用者輸入所需的時間。
-
Total blocking time 總阻塞時間 (TBT)：測量 FCP 與 TTI 之間的總時間，這期間，主執行緒被阻塞的時間過長，無法作出輸入響應。
指標閾值定義
標準
在為核心Web指標建立閾值時，Chrome團隊首先確定了每個閾值必須滿足的標準。
高質量的使用者體驗
-
確保滿足核心
Web指標"良好"閾值的頁面能夠提供高質量的使用者體驗。 -
人類感知和
HCI研究，有時會使用單個固定閾值來進行概括，但底層研究中通常會用範圍值來表示，聚合和匿名Chrome指標資料也顯示出了平滑且連續的分佈。所以指標的閾值會用範圍值來表示。
可透過現有網路內容實現
為了確保網站所有者能夠成功地最佳化他們的網站並滿足"良好"閾值，我們要求這些閾值對於網路上現有的內容是可以實現的。
例如，雖然零毫秒是理想的LCP"良好"閾值，並且可以帶來即時載入體驗，但由於網路和裝置處理延遲，零毫秒的閾值實際上在大多數情況下都無法實現。因此，對於核心Web指標來說，零毫秒不是一個合理的LCP"良好"閾值。
"良好"閾值：在評估核心Web指標的候選"良好"閾值時，我們會根據Chrome使用者體驗報告(CrUX)中的資料驗證這些閾值是否可以實現。為了確認一個閾值是可以實現的，要求目前至少有10%的域滿足"良好"閾值。
"欠佳"閾值： 透過確定當前只有少數域未能達到的效能水平來建立"欠佳"閾值。除非有"欠佳"閾值定義的相關研究，否則在預設情況下，效能表現最差的 10-30%的域將被歸類為"欠佳"。
總結
如果針對某一指標有相關的使用者體驗研究，並且對文獻中的數值範圍有合理共識，那麼我們會用這個範圍作為輸入來指導我們的閾值選取過程
在沒有相關的使用者體驗研究的情況下，會對滿足不同指標候選閾值的真實世界頁面進行評估，從而確定一個能帶來良好使用者體驗的閾值。
在評估候選閾值時，發現這些標準有時會相互衝突。而使用者行為指標又顯示了行為的逐漸變化，所以通常沒有唯一"正確"的指標閾值，有時可能需要從多個合理的候選閾值中進行選擇。
示例—— LCP (Largest Contentful Paint) 閾值標準定製
一、體驗質量
米勒和卡德的研究將使用者在失去注意力之前的等待時間描述為一個從大約0.3秒到3 秒的範圍，也就表明我們的LCP"良好"閾值應該在這個範圍內。此外，考慮到目前的首次內容繪製"良好"閾值為1秒，並且最大內容繪製通常發生在首次內容繪製之後，可以進一步將LCP候選閾值的範圍限制在1秒到3秒之間。
二、可實現性
利用CrUX(Chrome User Experience Report)的資料，我們可以確定網路上滿足LCP候選"良好"閾值的域所佔的百分比。
只有不到10%的域滿足1秒閾值，但1.5秒到3秒之間的其他所有閾值也都滿足我們的要求，即至少有10%的域滿足"良好"閾值，因此這些閾值仍然是有效的候選值。
為了確保所選取的閾值對於最佳化良好的網站始終都可實現，Chrome團隊分析了全網表現最出色的網站的LCP效能，從而確定哪些閾值對於這些網站是始終都可實現的。具體來說，我們的目標是確定一個對於表現最出色的網站來說，始終可以在第75個百分位數實現的閾值。最終發現1.5秒和2秒的閾值並不是始終都可以實現的，而2.5秒的閾值是始終可以實現的。
為了確定LCP的"欠佳"閾值，我們利用CrUX資料來確定大多數域能夠滿足的閾值：
在閾值為4秒的情況下，大約26%的手機端域和19%的桌面端域將被歸類為欠佳。這些百分比落在10-30%的目標範圍內，因此，4秒是可接受的"欠佳"閾值。
因此，得出結論，對於最大內容繪製來說，2.5秒是一個合理的"良好"閾值，4秒是一個合理的"欠佳"閾值。
指標分數
一旦Lighthouse收集了效能指標（大多數以毫秒為單位報告），它就會透過檢視指標值在其Lighthouse評分分佈上的位置，將每個原始指標值轉換為0到100之間的指標分數。評分分佈是從HTTP Archive上真實網站效能資料的效能指標得出的對數正態分佈。
例如，最大內容繪製(LCP)衡量使用者何時感知到頁面的最大內容可見。LCP的指標值表示使用者啟動頁面載入和頁面呈現其主要內容之間的持續時間。根據真實網站資料，表現最好的網站在大約1,220毫秒內渲染LCP，因此指標值對映為99分。
HTTPArchive 資料的第25個百分位數變為50分（中值控制點），第8 個百分位數變為90分（良好/綠色控制點）。
指標的權重
效能分數是由指標的加權平均計算出來的，一般來說，權重越高的指標，對效能的得分影響就越大。
為了使使用者感知的效能處於一個相對平衡的狀態，權重會隨著時間而改變。因為Lighthouse團隊會定期的進行調研，根據使用者的反饋來找出對使用者感知的效能影響最大的因素，從而修改指標和權重。
下圖為 Lighthouse 10 和 Lighthouse 8的指標及權重變化對比：
如果想要了解更多可以檢視：web效能指標更新記錄
結束語
我們透過上述瞭解了Lighthouse效能得分計算背後的邏輯，沒有去了解之前還不知道Chrome團隊為了些事情做了大量的工作。透過對使用者行為和感知的大量研究、實際的資料及使用者反饋來定製和調整標準，有理有據，也更能反饋出實際的情況。只能說是真Niubility。