▲點擊"三分設(shè)"關(guān)注，回復(fù)"社群"加入我們

歡迎來到專業(yè)設(shè)計師學(xué)習(xí)交流社區(qū)

三分設(shè)｜連接知識，幫助全球 1 億設(shè)計師成長

轉(zhuǎn)自：TCC翻譯情報局

編輯：皮皮

共 4715 字，預(yù)計閱讀 12 分鐘

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

Nathan Dumlao 攝影作品（發(fā)表于 Unsplash）

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

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

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

Core Web Vitals 與 Web Vitals

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

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

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

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

Core Web Vitals 與 Web Vitals

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

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

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

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

加載性能

LCP 的基準(zhǔn)時間

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

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

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

LCP 對比

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

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

FID -- 首次輸入延遲

交互行為

FID 的基準(zhǔn)時間

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

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

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

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

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

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

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

CLS -- 累計布局偏移

視覺穩(wěn)定性

CLS 的基準(zhǔn)時間

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

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

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

視覺穩(wěn)定性測量

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

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

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

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

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

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

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

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

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

Bit 使得在項目之間共享、記錄和復(fù)用獨立組件變得簡單。使用它可以最大限度地復(fù)用代碼，能夠保持設(shè)計一致、幫助團(tuán)隊協(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)在是時候?qū)W習(xí)如何測量了。

測量 Web Vitals 比你想象的要容易得多

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

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

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

實驗室測試工具

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

“但是這些實驗室測試工具無法測量 FID，因為沒有用戶來計算其交互性。但是，這些工具使用了一種稱為 Total Blocking Time（TBT）的等效測量方法?！?/span>

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

使用 Lighthouse 測量 Core Web Vitals

現(xiàn)場測試工具

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

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