Google 開發(fā)了許多實(shí)用指標(biāo)和工具，幫助衡量用戶體驗(yàn)和質(zhì)量，從而發(fā)掘優(yōu)化點(diǎn)。一項(xiàng)名為 Web Vitals 的計(jì)劃降低了學(xué)習(xí)成本，為網(wǎng)站體驗(yàn)提供了一組統(tǒng)一的質(zhì)量衡量指標(biāo) -- Core Web Vitals，其中包括加載體驗(yàn)、交互性和頁(yè)面內(nèi)容的視覺穩(wěn)定性，構(gòu)成了 2020 年核心 Web 健康指標(biāo)的基礎(chǔ)。本文詳細(xì)的介紹了每個(gè)指標(biāo)及其使用方式，推薦了用于測(cè)量這些指標(biāo)的實(shí)用工具，快來一起看看吧～

有很多方法可以優(yōu)化網(wǎng)站的用戶體驗(yàn)。若能預(yù)先了解最佳的優(yōu)化衡量方法，可以大大節(jié)省時(shí)間和成本。

Google 在 2020 年 5 月 5 日提出了新的用戶體驗(yàn)量化方式 Web Vitals 來衡量網(wǎng)站的用戶體驗(yàn)，并將這些衡量結(jié)果用作其排名算法的一部分。為了更好的理解這些內(nèi)容，讓我們來看看這些重要指標(biāo)是什么。

△ Google 在使用者體驗(yàn)量化發(fā)展的相關(guān)成果

Core Web Vitals 與 Web Vitals

什么是 Web Vitals，Google 給出的定義是 一個(gè)良好網(wǎng)站的基本指標(biāo)（Essential metrics for a healthy site），過去要衡量一個(gè)網(wǎng)站的好壞，需要使用的指標(biāo)太多了，Web Vitals 可以簡(jiǎn)化指標(biāo)的學(xué)習(xí)曲線，只需聚焦于 Web Vitals 指標(biāo)的表現(xiàn)即可。

“你不需要成為任何領(lǐng)域的專家就可以了解 Web Vitals。它們很簡(jiǎn)單，比如移動(dòng)友好性、瀏覽安全性、HTTPS、交互性、視覺穩(wěn)定性、加載時(shí)間等?！?/p>

在這些 Web Vitals 中，Google 確定了三個(gè)主要衡量指標(biāo)，即在所有類型的網(wǎng)站中通用的 Core Web Vitals[1]：

[1]Core Web Vitals 是應(yīng)用于所有 Web 頁(yè)面的 Web Vitals 的子集，是其最重要的核心。

△?Core Web Vitals 與 Web Vitals

• 加載性能（LCP） -- 顯示最大內(nèi)容元素所需時(shí)間
• 交互性（FID） -- 首次輸入延遲時(shí)間
• 視覺穩(wěn)定性（CLS） -- 累積布局配置偏移

這三個(gè)指標(biāo)已經(jīng)經(jīng)過了一段時(shí)間的驗(yàn)證，如 LCP 在 WICG 已經(jīng)孵化至少 1 年以上，F(xiàn)ID 在 Google Chrome Labs 上已經(jīng)實(shí)施 2 年以上，LCP 和 CLS（相關(guān) Layout Instability API）已于今年入 W3C 草擬標(biāo)準(zhǔn)。

讓我們一起詳細(xì)了解下 Core Web Vitals。

LCP -- 最大內(nèi)容繪制

1. 加載性能

△?LCP 的基準(zhǔn)時(shí)間

LCP（Largest Contentful Paint）用于衡量加載體驗(yàn)，從真實(shí)用戶的角度衡量網(wǎng)頁(yè)的加載速度。它是 從頁(yè)面剛開始加載到呈現(xiàn)出所有內(nèi)容時(shí)的持續(xù)時(shí)間。

“換句話說，LCP 是度量網(wǎng)頁(yè)上可見區(qū)域加載時(shí)間的方法”

讓我們比較一下有圖像和沒有圖像的媒體文章的 LCP。

△?LCP 對(duì)比

有圖片的文章用了 3.57 秒加載，而沒有圖片的文章只用了 2.32 秒載入。

“谷歌堅(jiān)稱，所有開發(fā)者和產(chǎn)品所有者都會(huì)定期測(cè)量其應(yīng)用程序的 Core Web Vitals，并提供工具來輔助測(cè)量?！?/p>

FID -- 首次輸入延遲

1. 交互行為

△?FID 的基準(zhǔn)時(shí)間

FID（First Input Delay）涉及到用戶與 web 頁(yè)面之間的交互性，用于衡量網(wǎng)站操作的順暢程度。它測(cè)量了用戶第一次產(chǎn)生交互行為，到瀏覽器響應(yīng)該用戶操作的持續(xù)時(shí)間。這些用戶交互行為可以是單擊按鈕、點(diǎn)擊鏈接或任何基于 JavaScript 的自定義控件。

在 TTI 的時(shí)間內(nèi)第一個(gè)互動(dòng)事件的開始時(shí)間與瀏覽器回應(yīng)事件的時(shí)間差

為什么要取在 TTI[2] 發(fā)生的第一次的操作事件，Google 給的理由有以下三點(diǎn):

• 使用者的第一次互動(dòng)體驗(yàn)印象相當(dāng)重要；
• 當(dāng)今網(wǎng)頁(yè)最大的互動(dòng)性問題通常發(fā)生在一開始載入時(shí)；
• 頁(yè)面載入完后的第二次操作事件延遲，有其他專門的改善解決建議。

[2]互動(dòng)時(shí)間 TTI 是衡量負(fù)載響應(yīng)能力的重要實(shí)驗(yàn)室指標(biāo)。它有助于確定頁(yè)面看起來是交互式但實(shí)際上不是交互式的情況。快速的 TTI 有助于確保頁(yè)面可用。TTI 度量標(biāo)準(zhǔn)衡量的是從頁(yè)面開始加載到頁(yè)面主要子資源加載之間的時(shí)間，它能夠快速可靠地響應(yīng)用戶輸入。

“根據(jù) Google 的基準(zhǔn)測(cè)試，交互的最佳持續(xù)時(shí)間應(yīng)該在 100ms 以下，而任何超過 300ms 的時(shí)間都被認(rèn)為是較差的?！?/p>

人們可能會(huì)說這些時(shí)間間隔很小，調(diào)整幾百毫秒也沒什么區(qū)別。但實(shí)際上，這些微小的變化可能會(huì)對(duì)最終用戶產(chǎn)生重大影響。

CLS -- 累計(jì)布局偏移

1. 視覺穩(wěn)定性

△?CLS 的基準(zhǔn)時(shí)間

你可能已經(jīng)注意到某些時(shí)候網(wǎng)頁(yè)中的元素在加載時(shí)出現(xiàn)移動(dòng)，我敢肯定這不是用戶期待的優(yōu)秀體驗(yàn)。在這樣的場(chǎng)景中，CLS（Cumulative Layout Shift）測(cè)量在頁(yè)面的整個(gè)生命周期中發(fā)生的每個(gè)意外的樣式移動(dòng)的所有單獨(dú)布局更改得分的總和，可以方便地用來度量 web 頁(yè)面的視覺表現(xiàn)。布局的移動(dòng)可能發(fā)生在可見元素從一幀到下一幀改變位置的任何時(shí)候。為了提供良好的用戶體驗(yàn)，網(wǎng)站應(yīng)努力使 CLS 分?jǐn)?shù)小于 0.1.

“CLS 顯示頁(yè)面加載時(shí)組件移動(dòng)的次數(shù)。正如大家所理解的，CLS 需要盡可能少地次數(shù)來實(shí)現(xiàn)良好的用戶體驗(yàn)?！?/p>

下圖顯示了 medium.com 和視覺不穩(wěn)定網(wǎng)站之間的 CLS 差異。

△?視覺穩(wěn)定性測(cè)量

在上面的例子中，medium.com 網(wǎng)站顯示其 CLS 為 0.097。

“這是不是意味著 medium.com 網(wǎng)站加載時(shí)主頁(yè)移動(dòng)了 0.097 次？→ 不是??！”

計(jì)算此值時(shí)要考慮視窗大小以及兩個(gè)渲染幀之間視窗中不穩(wěn)定元素的移動(dòng)。

布局偏移系數(shù)（Layout Shift Score） = 影響范圍系數(shù)（Impact Fraction） x 移動(dòng)距離系數(shù)（Distance Fraction）

CLS 值（布局偏移系數(shù)）可以使用上述公式輕松計(jì)算。此公式中的影響系數(shù)是指不穩(wěn)定元素對(duì)視窗的影響，而距離系數(shù)是指不穩(wěn)定元素移動(dòng)的距離。

例如，假設(shè)一個(gè)不穩(wěn)定的元素覆蓋了總窗口大小的 40%，當(dāng)頁(yè)面加載時(shí)它向下移動(dòng)了 20%。在這種情況下，因?yàn)椴环€(wěn)定元素占用了總窗口的 60%，影響系數(shù)將為 0.6。又由于不穩(wěn)定元素向下移動(dòng)了 20%，因此距離系數(shù)將為 0.2。

因此，最終布局偏移系數(shù) = 0.6 x 0.2 = 0.12

如上圖的實(shí)例，影響范圍（紅色區(qū)域）占比總窗口 75% ，箭頭（紫色）移動(dòng)占總窗口高度的 25%，故 0.75 x 0.25 = 0.1875。

提示：使用 Bit（于 Github 里）可在項(xiàng)目之間共享可復(fù)用組件。

Bit 使得在項(xiàng)目之間共享、記錄和復(fù)用獨(dú)立組件變得簡(jiǎn)單。使用它可以最大限度地復(fù)用代碼，能夠保持設(shè)計(jì)一致、幫助團(tuán)隊(duì)協(xié)作、加快交付并構(gòu)建可擴(kuò)展的應(yīng)用程序。

Bit 支持 Node，TypeScript，React，Vue，Angular 等。

△?示例：探索在 Bit.dev 上共享的可復(fù)用的 React 組件

我覺得現(xiàn)在你應(yīng)該已經(jīng)很好地理解了 Core Web Vitals 和它們的職責(zé)。所以，現(xiàn)在是時(shí)候?qū)W習(xí)如何測(cè)量了。

測(cè)量 Web Vitals 比你想象的要容易得多

正如我開始提到的，測(cè)量 Web Vitals 是一個(gè)簡(jiǎn)單的過程，任何人都可以做到。實(shí)際有很多工具可以用來測(cè)量 Web 的重要信息，包括一些瀏覽器插件。

“Lighthouse、Chrome DevTools、PageSpeed Insights、Chrome UX Report 和 Web Vitals Extension 位列榜首?！?/p>

雖然這些工具的用途相同，但可以進(jìn)一步分為實(shí)驗(yàn)室測(cè)試工具和現(xiàn)場(chǎng)測(cè)試工具兩類。

1. 實(shí)驗(yàn)室測(cè)試工具

實(shí)驗(yàn)室測(cè)試工具的主要目的是在開發(fā)過程中測(cè)試性能，以確保在發(fā)布之前達(dá)到所需的標(biāo)準(zhǔn)。ChromeDevTools 和 Lighthouse 可用于在開發(fā)環(huán)境中測(cè)量 Core Web Vitals。

“但是這些實(shí)驗(yàn)室測(cè)試工具無(wú)法測(cè)量 FID，因?yàn)闆]有用戶來計(jì)算其交互性。但是，這些工具使用了一種稱為 Total Blocking Time（TBT）的等效測(cè)量方法。”

下圖顯示了使用 Lighthouse 的網(wǎng)頁(yè)的性能測(cè)試結(jié)果：

△?使用 Lighthouse 測(cè)量 Core Web Vitals

2. 現(xiàn)場(chǎng)測(cè)試工具

實(shí)驗(yàn)室測(cè)試工具的結(jié)果不是 100% 準(zhǔn)確的，因?yàn)闆]有真正的用戶試用網(wǎng)頁(yè)?，F(xiàn)場(chǎng)測(cè)試工具可以用來填補(bǔ)這個(gè)漏洞。此外，與實(shí)驗(yàn)室測(cè)試工具不同的是，現(xiàn)場(chǎng)測(cè)試工具可以按原樣測(cè)量所有 3 個(gè) Core Web Vitals。

PageSpeed Insights、Chrome UX Report 和 Web Vitals Extension 是一些現(xiàn)場(chǎng)測(cè)試工具，我們可以使用這些工具在真實(shí)用戶交互時(shí)測(cè)量 Core Web Vitals。這些現(xiàn)場(chǎng)測(cè)試工具匿名地從網(wǎng)頁(yè)上收集實(shí)時(shí)數(shù)據(jù)，使我們無(wú)需手動(dòng)運(yùn)行任何操作即可檢查 Vitals。

△?使用 Lighthouse 測(cè)量 Core Web Vitals

讓我們假設(shè)你已經(jīng)測(cè)量了網(wǎng)站的 Core web Vitals，而結(jié)果并不符合預(yù)期。那么，做什么能提高這些分?jǐn)?shù)呢？

改善 Web Vitals 的步驟

既然你現(xiàn)在知道如何測(cè)量 Web Vitals，那么讓我們看看如果存在問題，如何改進(jìn)你的網(wǎng)站。

眾所周知，對(duì)于性能相關(guān)問題的技術(shù)修復(fù)并不是那么簡(jiǎn)單。大多數(shù)時(shí)候它們非常復(fù)雜耗時(shí)。但是，可以遵循一些通用的指導(dǎo)方法來改進(jìn)這些 Core Web Vitals。

可以通過以下方式改進(jìn)網(wǎng)站的 LCP：

刪除或避免使用消耗太多時(shí)間加載的大型頁(yè)面元素。通過分析前面討論的測(cè)量工具結(jié)果，可以很容易地發(fā)現(xiàn)這些元素及其影響；

△?Lighthouse 分析結(jié)果

避免不必要的第三方 JavaScript 庫(kù)。下面的分析表明，使用第三方庫(kù)已將主線程阻塞 2700 毫秒；

△?Lighthouse 分析結(jié)果

設(shè)置延遲加載和延遲加載圖像；

減少服務(wù)器響應(yīng)時(shí)間。

與 LCP 類似，可以遵循以下幾點(diǎn)來提高網(wǎng)站的 FID 值：

• 使用高效的緩存策略更快地加載頁(yè)面內(nèi)容；
• 與 LCP 類似，可以通過提交不必要的 JavaScript 庫(kù)來增強(qiáng) FID 值；
• 最小化將提高頁(yè)面加載時(shí)間，用戶將能夠立即與頁(yè)面交互。

△?Lighthouse 分析結(jié)果

Core Web Vitals 最終測(cè)量的是 CLS，可以通過以下方式提高 CLS 分?jǐn)?shù)：

• 對(duì)圖像和視頻使用固定尺寸；
• 如果網(wǎng)站存在廣告顯示，一定要為他們留下必要的空間。

結(jié)論

我希望你們已經(jīng)明白了維護(hù)優(yōu)秀網(wǎng)站的重要性。這些測(cè)量方法為保持網(wǎng)站的用戶體驗(yàn)友好性提供了有力支持。

盡管這些測(cè)量方法非常有前途，但在某些情況下，也需要臨時(shí)修改這些測(cè)量方法來確保良好的用戶體驗(yàn)。所以請(qǐng)保持注意。

歡迎關(guān)注作者微信公眾號(hào)：「TCC翻譯情報(bào)局」