解讀新一代Web性能體驗和質量指標

作者：ConardLi 2020-05-26 14:10:34

衡量一個 Web 頁面的體驗和質量一直有非常多的工具和指標 ... 每次我們去關注這些指標的時候都會非常痛苦，因為這些指標真的是又多又難理解，測量這些指標的工具也非常多。

當看到最近發布的 Chrome 83 中又增加了幾個性能指標的時候我頭都大了...

然而不要著急，這些指標就是為了聚焦關注度和降低理解成本的，下面我們就來具體看一下，新增加的 Core Web Vitals 到底是什么東西？

如何衡量用戶體驗質量？

優化用戶體驗的質量一直都是是每個 Web 站點長期成功的關鍵，衡量用戶體驗的質量有很多方面。雖然用戶體驗的某些方面是需要基于特定于站點和上下文的，但是所有站點仍然有一組共同的指標——Core Web Vitals，這些指標包括加載體驗、交互性和頁面內容的視覺穩定性，他們構成了 2020 年核心 Web 健康指標的基礎。

多年來，Google 提供了很多工具：(Lighthouse, Chrome DevTools, PageSpeed Insights, Search Console's Speed Report) 來衡量和報告性能。一些開發人員是使用這些工具的專家，而大部分其他人則發現大量的工具和衡量標準都很難學習和使用。

網站開發者不應該為了理解他們交付給用戶的體驗的質量指標而成為性能專家。Web Vitals 計劃的目的就是簡化場景，降低學習成本，并幫助站點關注最重要的指標，即 Core Web Vitals。

Core Web Vitals

Core Web Vitals 是應用于所有 Web 頁面的 Web Vitals 的子集，所有的站點開發者都應該關注一下，他們將在所有谷歌提供的性能測試工具中進行顯示。每個 Core Web Vitals 代表用戶體驗的一個不同方面，在該領域是可衡量的，并反映了以用戶為中心的關鍵結果的真實體驗。

網頁核心的性能指標應該是隨著時間的推移而不斷演變的。當前 2020 年主要關注用戶體驗的三個方面——加載、交互性和視覺穩定性:

Largest Contentful Paint (LCP): 衡量加載體驗：為了提供良好的用戶體驗， LCP 應該在頁面首次開始加載后的 2.5 秒內發生。
First Input Delay (FID): 衡量可交互性，為了提供良好的用戶體驗，頁面的 FID 應當小于 100毫秒。
Cumulative Layout Shift (CLS):衡量視覺穩定性，為了提供良好的用戶體驗，頁面的CLS應保持小于 0.1。

下面我們來詳細介紹這三種性能指標：

LCP

加載體驗的衡量

衡量 Web 頁主要內容的加載速度是眾多開發者一直在關注的一個點，而且可衡量的指標非常多。

比如最早的 load、DOMContentLoaded 事件，用這兩個事件來衡量頁面加載速度是非常糟糕的，因為它們不一定與用戶在屏幕上看到的內容相對應。

以用戶為中心的更新性能指標（例如First Contentful Paint（FCP））它只能捕捉加載體驗的最開始。如果頁面最開始顯示的是一個 loading 動畫，那這個指標就很難關注了。

后來，業界開始建議使用比如 First Meaningful Paint (FMP) 和 Speed Index (SI)（都可以在 Lighthouse 中獲取）等性能指標來幫助捕獲初次渲染后的更多加載體驗，但是這些指標非常復雜，難以解釋，而且誤報率也比較高。

什么是 LCP

Largest Contentful Paint (LCP) 用于衡量標準報告視口內可見的最大內容元素的渲染時間。為了提供良好的用戶體驗，網站應努力在開始加載頁面的前 2.5 秒內進行最大內容渲染。

相比 FCP ，這個指標就非常有價值了，因為這個值是根據頁面加載渲染不斷變化的，如果頁面有一個 lodaing 動畫，然后才渲染出具體內容，那么這個指標計算出來的就是具體內容的加載速度，而非 lodaing 動畫的加載速度。

LCP 考慮哪些元素

LCP 目前并不會計算所有元素，因為這樣會使這個指標變得非常復雜，它現在只關注下面的元素： <img> 元素

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

為了在開始時保持簡單，將元素限制到這個有限的集合是有意的。隨著研究的深入，將來可能會添加更多的元素。

如何計算 LCP ?

頁面上最大的元素即繪制面積最大的元素，所謂繪制面積可以理解為每個元素在屏幕上的 “占地面積”，如果元素延伸到屏幕外，或者元素被裁切了一部分，被裁切的部分不算入在內，只有真正顯示在屏幕里的才算數。

圖片元素的面積計算方式稍微有點不同，因為可以通過 CSS 將圖片擴大或縮小顯示，也就是說，圖片有兩個面積：“渲染面積”與“真實面積”。在 LCP 的計算中，圖片的繪制面積將獲取較小的數值。例如：當“渲染面積”小于“真實面積”時，“繪制面積”為“渲染面積”，反之亦然。

頁面在加載過程中，是線性的，元素是一個一個渲染到屏幕上的，而不是一瞬間全渲染到屏幕上，所以“渲染面積”最大的元素隨時在發生變化。

如果元素被刪除，LCP算法將不再考慮該元素，如果被刪除的元素剛好是 “繪制面積” 最大的元素，則使用新的 “繪制面積” 最大的元素創建一個新的性能條目。

該過程將持續到用戶第一次滾動頁面或第一次用戶輸入（鼠標點擊，鍵盤按鍵等），也就是說，一旦用戶與頁面開始產生交互，則停止報告新的性能指標。

在以上兩個時間軸中，最大的元素隨內容加載而變化。在第一個示例中，新內容被添加到 DOM 中，并且更改了最大的元素。在第二個示例中，布局發生更改，以前最大的內容從視口中刪除。通常情況下，延遲加載的內容要大于頁面上已存在的內容。

改善 LCP

LCP較差的最常見原因是：

服務器響應時間慢
阻斷渲染的 Javascript 和 CSS
資源加載時間慢
客戶端渲染

所以我們從上面的角度去考慮改善 LCP：

優化服務器

這個很好理解，瀏覽器從服務器接收內容所需的時間越長，則在屏幕上呈現任何內容所花費的時間就越長。更快的服務器響應時間可以直接改善包括 LCP 在內的所有頁面加載指標。

[[327658]]

衡量服務器相應時間有一個專門的指標：首字節相應時間（TTFB）是最初的網絡請求被發起到從服務器接收到第一個字節這段時間，它包含了 TCP 連接時間，發送 HTTP 請求時間和獲得響應消息第一個字節的時間。你可以嘗試在下面幾個方便優化 TTFB ：

緩存 HTML 離線頁面，緩存頁面資源，減少瀏覽器對資源的請求。
盡量減小資源阻斷渲染：CSS 和 JavaScript 壓縮、合并、級聯、內聯等等
對圖片進行優化。轉化圖片的格式為 JPG 或者 WEBP 等等的格式，降低圖片的大小，以加快請求的速度。
對 HTML 重寫、壓縮空格、去除注釋等。減少 HTML 大小，加快速度。
使用 preconnect 盡快與服務器建立鏈接、使用 dns-prefetch 盡快進行 DNS 查找。
使用 CDN 加快請求速度

優化阻斷渲染的資源

JavaScript 和 CSS 都是會阻斷頁面渲染的資源，需要盡可能的對 CSS 和 JavaScript 文件進行壓縮、延遲加載首屏無需使用的 JavaScript、內聯關鍵的 CSS 等來減小阻斷時間。

優化資源加載時間

剛才我們上面提到的這些資源，如果在首屏進行渲染，則加載這些元素所花費的時間將直接影響 LCP 。

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

你可以使用下面的手段進行優化：

對圖片進行優化。轉化圖片的格式為 JPG 或者 WEBP 等等的格式，降低圖片的大小。
對重要的資源進行預加載，比如為 style 標簽添加 rel="preload" 屬性
使用 Gzip 和 Brotli 壓縮頁面資源，降低傳輸時間
使用 service worker 緩存資源

服務端渲染

使用服務端渲染可以確保首先在服務器上呈現頁面內容，可以有效改善 LCP，但是相比客戶端渲染的缺點是會加大頁面從而影響 TTFB、服務端渲染需要等待所有 js 執行完畢后才能相應用戶輸入，這會使交互體驗變差。

FID

第一印象

我們都知道留下一個好的第一印象是多么重要。在網絡上，一個好的第一印象可以決定一個人是不是可以成為一個網站的忠實的用戶，或者是離開以后再也不會回來。問題是，什么能給人留下好印象，你如何衡量你可能給用戶留下什么樣的印象?

在網絡上，第一印象可以有很多種不同的形式——我們對網站的設計和視覺吸引力有第一印象，對其速度和響應能力也有第一印象。

開發者們使用 First Contentful Paint（FCP）可以衡量對網站加載速度對第一印象。但是，網站可以在屏幕上繪制像素的速度只是一部分，同樣重要的是用戶嘗試與這些像素進行交互時你的網站的響應速度！

什么是 FID

FID（ First Input Delay）即記錄用戶和頁面進行首次交互操作所花費的時間。FID 指標影響用戶對頁面交互性和響應性的第一印象。為了提供良好的用戶體驗，站點應努力使首次輸入延遲小于 100 毫秒。

FID 發生在 FCP 和 TTI 之間，因為這個階段雖然頁面已經顯示出部分內容，但尚不具備完全的可交互性。這個階段用戶和頁面交互，往往會有較大延遲。

如上圖所示，瀏覽器接收到用戶輸入操作時，主線程正在忙于執行一個耗時比較長的任務，只有當這個任務執行完成后，瀏覽器才能響應用戶的輸入操作。它必須等待的時間就此頁面上該用戶的 FID 值。

例如，以下所有 HTML 元素都需要在響應用戶交互之前等待主線程上正在進行的任務完成：

文本輸入框，復選框和單選按鈕（<input>，<textarea>）
選擇下拉菜單（<select>）
鏈接（<a>）

如何提高 FID

以下幾個方面是提高 FID 的重要指標：

減少 JavaScript 執行時間

同上面改善 LCP 的方法：

縮小并壓縮 JavaScript 文件
延遲加載首屏不需要的 JavaScript
盡量減少未使用的 polyfill

分解耗時任務

上面提到一個較長的耗時任務是影響 FID 的重要指標，任何阻塞主線程 50 毫秒或更長時間的代碼段都可以稱為“長任務”，我們可以將長的耗時任務拆分為較小的異步任務。

使用 Web Worker

主線程阻塞是輸入延遲的主要原因之一。Web Workers 可以讓你在與主執行線程分離的后臺線程上運行 JavaScript，這樣做的好處是可以在一個單獨的線程中執行費時的處理任務，從而允許主（通常是UI）線程運行而不被阻塞。將非 UI 操作移至單獨的工作線程可以減少主線程的阻塞時間，從而改善 FID 。

CLS

視覺穩定性

您是否曾經在訪問一個 Web 頁面時發生下面的情況？在閱讀文章的同時文字突然移動了、你突然找不到你閱讀的位置了、點按鈕的時候按鈕被移動到了其他地方，導致你點了其他東西？

頁面內容的意外移動通常是由于異步加載資源或將 DOM 元素動態添加到現有內容上方的頁面而發生的。罪魁禍首可能是尺寸未知的圖像或視頻，渲染后比其后備更大或更小的字體，或者是動態調整自身大小的第三方廣告或小部件。

Cumulative Layout Shift (CLS) 可通過測量實際用戶發生的頻率來幫助您解決此問題。

什么是 CLS？

CLS 會測量在頁面的整個生命周期中發生的每個意外的樣式移動的所有單獨布局更改得分的總和。布局的移動可能發生在可見元素從一幀到下一幀改變位置的任何時候。為了提供良好的用戶體驗，網站應努力使 CLS 分數小于 0.1 。

如何計算 CLS?

布局偏移分值

為了計算布局的偏移值，瀏覽器會查看兩個渲染幀之間的視口大小和視口中不穩定元素的移動。布局偏移分是該移動的兩個指標的乘積:影響分數和距離分數。

layout shift score = impact fraction * distance fraction

影響分數

前一幀和當前幀的所有不穩定元素的可見區域的并集（占視口總面積的一部分）是當前幀的影響分數。

在上圖中，有一個元素在一幀中占據了視口的一半。然后，在下一幀中，元素下移視口高度的25％。紅色的虛線矩形表示兩個幀中元素的可見區域的并集，在這種情況下，其為總視口的75％，因此其影響分數為 0.75。

距離分數

布局偏移值方程的另一部分測量不穩定元素相對于視口移動的距離。距離分數是任何不穩定元素在框架中移動的最大距離(水平或垂直)除以視口的最大尺寸(寬度或高度，以較大的為準)。

在上面的例子中，最大的視口尺寸是高度，并且不穩定元素移動了視口高度的25%，這使得距離分數為0.25。

因此，在此示例中，影響分數為0.75，距離分數為0.25，因此版式位移分數為0.75 * 0.25 = 0.1875。

如何改善 CLS?

不要使用無尺寸元素

圖像和視頻等元素上始終需要包括 width 和 height 尺寸屬性，現代瀏覽器會根據圖像的 width 和 height 屬性設置圖像的默認長寬比，知道縱橫比后，瀏覽器就可以為元素計算和保留足夠的空間。

或者，使用 aspect-ratio 也可以提前指定寬高比：

img {  
    aspect-ratio: attr(width) / attr(height);  
}

那響應式的圖片呢？可以使用 srcset 定義圖像，使瀏覽器可以在圖像之間進行選擇，以及每個圖像的大小。

<img   
    width="1000"   
    height="1000"  
    src="puppy-1000.jpg"  
    srcset="puppy-1000.jpg 1000w,  
            puppy-2000.jpg 2000w,  
            puppy-3000.jpg 3000w"  
    alt="ConardLi"  
/>

永遠不要在現有內容之上插入內容，除非是響應用戶交互。這確保了預期的布局變化。
寧可轉換動畫，也不要轉換觸發布局變化的屬性的動畫。以一種提供從一個狀態到另一個狀態的上下文和連續性的方式動畫轉換。

提前給廣告位預留空間

很多頁面廣告都是動態插入的，所以一定要提前為廣告位預留一定空間。

警惕字體變化

字體通常是大文件，需要一段時間才能加載，一些瀏覽器直到下載完字體后才呈現文本

font-display: swap 告訴瀏覽器默認使用系統字體進行渲染，當自定義字體下載完成之后再進行替換。

@font-face {  
  font-family: 'Pacifico';  
  font-style: normal;  
  font-weight: 400;  
  src: local('Pacifico Regular'), local('Pacifico-Regular'), url(https://fonts.gstatic.com/xxx.woff2) format('woff2');  
  font-display: swap;  
}

另外，你可以使用 <link rel="preload"> 更早的加載字體文件。

獲取 Core Web Vitals

Google 認為，Core Web Vitals 對于所有網絡體驗都至關重要。因此，它致力于在其工具中顯示這些指標，下面是現有工具中指標的支持情況：

尚未支持這些指標的工具都將在最近得到支持。

web-vitals

現在你可以使用標準的 Web API 在 JavaScript 中測量每個指標。 Google 提供了一個 npm 包：web-vitals，這個庫提供了非常簡單的 API，測量每個指標就像調用一個普通函數一樣簡單：

npm install web-vitals

每個測量函數都接收一個 report 回調函數作為參數，回調函數將在測量完成后觸發，另外，對于像 LCP 和 CLS 這樣的指標是不斷變化的，所以它們的回調函數可能會多次觸發，如果你想獲取在這期間獲取每次變化的數值，你可以指定第二個參數 reportAllChanges，否則回調函數只有在最終測量完成后觸發一次。

import {getCLS, getFID, getLCP} from 'web-vitals';  
getCLS(console.log, true);  
getFID(console.log); // Does not take a `reportAllChanges` param.  
getLCP(console.log, true);

這些變化的指標如果觸發多次的話可能會多次發送到你的服務器，所以回調函數中提供了下面三個參數：

name：指標名稱
id：本地分析的id
delta：當前值和上次獲取值的差值

因此你只需要每次上報 delta (當前值和上次獲取值的差值)，而不需要報告新值。然后在服務器可以通過計算所有id對應值的和來獲取最終結果。

import {getCLS, getFID, getLCP} from 'web-vitals';  
function logDelta({name, id, delta}) {  
  console.log(`${name} matching ID ${id} changed by ${delta}`);  
}  
getCLS(logDelta, true);  
getFID(logDelta);  
getLCP(logDelta, true);

你可以很好的結合 Google Analytics 來記錄你的上報指標：

import {getCLS, getFID, getLCP} from 'web-vitals';  
function sendToGoogleAnalytics({name, delta, id}) {  
  ga('send', 'event', {  
    eventCategory: 'Web Vitals',  
    eventAction: name,  
    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta), 
    eventLabel: id,  
    nonInteraction: true,  
  });  
}  
getCLS(sendToGoogleAnalytics);  
getFID(sendToGoogleAnalytics);  
getLCP(sendToGoogleAnalytics);