網站使用體驗核心指標是什麼？

Core Web Vitals（CWVs；網站使用體驗核心指標）

Google 發表新的網站品質評估指標 Core Web Vitals，目的是提供具有代表且一致性的網站品質數據，這些指標分別為：LCP、FID、CLS 與2022年新增的 INP。但在2024年，FID將正式被INP取代。

因為評估網頁速度體驗的方法百百種，而且很難把 UX 數據量化，而因為 CWVs 會成為 Google 搜尋排名 SEO 的因素之一，一些網頁檢測工具勢必會跟上這次提出的標準。

指標的檢測標準。圖片來自 blog.chromium.org

什麼是 LCP？

LCP是最大內容繪製元素(Largest Contentful Paint)，視窗可見範圍內最大內容元素的渲染時間。根據 LCP API 考慮的元素類型有：

• img 元素
• 在svg 裡面的 image 元素
• 有 poster image 的 video 元素
• 使用 CSS url() 載入圖片的元素
• 包含文字節點的 Block-level 元素

什麼是 CLS？

CLS是累計版面配置位移(Cumulative Layout Shift)，可以想成頁面載入時的穩定度。CLS 會測量在頁面整個生命週期中發生的每個意外排版位移（layout shift），並將所有單獨排版位移的分數加總，分數在0到1之間。比如使用者才剛閱讀完一句話，突然上面跑出廣告把剛才閱讀的文字往下擠，或是想點擊取消按鈕，卻在下一秒位移按到確定，造成非常糟糕的使用體驗，都會讓分數增加。

什麼是 FID？

FID是首次輸入延遲(First Input Delay)，用戶首次與頁面互動（點擊連結、輸入欄、下拉選單、按鈕或 JavaScript 驅動的元件）到瀏覽器能夠回應該互動的時間。而當量測工具無法測量 FID 時，可以換成評估與 FID 關係密切的總阻塞時間（TBT）指標，因此優化 TBT 也可直接提高 FID 的品質。

但在 INP 出現之後，基本上就被其取代了，Google也宣布將在2024年3月由INP取代之。

什麼是 INP？

INP是與下一次的互動渲染(Interaction to Next Paint)，基本上可以想成 FID 的替代品，它涵蓋了頁面的整個生命週期，會累積頁面上所有的互動延遲，例如 pointerup、pointerdown 和 click 這些都可能導致整體互動的延遲。簡單來說，著重的點在用戶體驗和使用者的設備可變性。

看看 Google 在 web.dev LIVE 2020 的線上研討會怎麼說：

另外，Google 也有做一個解釋 INP 的影片：

網站使用體驗核心指標對SEO的影響

來自 Simplifying the Page Experience report(2021-08-04)

Google 將源自 Core Web Vitals 的信號與現有的頁面體驗搜索信號結合，包含 mobile-friendliness、safe-browsing、HTTPS-security 和 intrusive interstitial guidelines。新的網頁 UX 信號會在 2021 年 6 月之後成為 Google 搜尋的排名因素，並在 2022 年 2 月之後納入桌機版的排名（區別手機與桌機的使用者）。

數值標準

當然，各指標會有其標準：

• LCP：小於等於 2.5 秒才算良好，超過 4 秒代表不良。
• FID：小於等於 100 毫秒才算良好，超過 300 毫秒為不良。
• CLS：小於等於 0.1 才算良好，超過 0.25 代表不良。
• INP：小於等於 200 毫秒才算良好，超過 500 毫秒代表頁面響應能力較差。

前三項你可以在此處查看 Google 的說明，而 INP 可以看這篇文章。

*2021-02-18 從「小於」改成「小於等於」

輕鬆改善圖片載入

圖片、影片和 iframe 通常是網頁中容量最大的東西，若要無損壓縮圖片的話，網路上可以找到很多工具，例如 Squoosh、TinyPNG、SVGOMG，又或者可以使用 WebP、WebM、AVIF 等較輕量的檔案格式。

另外，還可以用瀏覽器原生的延遲載入方法「loading="lazy"」增加效能，若再寫上寬、高的話，還能改善 CLS。

若是背景圖片的話，則可以使用 JavaScript 的 IntersectionObserver，讓該元素出現在可見視窗時再載入，降低使用者剛進入頁面時的負擔。

然而，並不是所有圖片都要加上「loading lazy」，若是一開始就在使用者的畫面中，加上「loading="lazy"」只會拖慢載入時間，這些一開始就在畫面上的圖片、影片或iframe，加上「fetchpriority="high"」增加其載入優先度會是比較好的選擇。

如何改善CLS？

圖片CLS

各測速工具基本上都會點出哪裡有問題與基本的改善方案。而 Google 也分享了 Yahoo JAPAN News 的 CLS 改善方法，成功讓網頁流量增加 15%：

1. 給每一張圖片的 HTML 都加上寬和高。
2. 使用 CSS 的 aspect-ratio 和 object-fit。

就是這麼簡單，成功讓 CLS 改善 0.2 分。當然使用常見的 CSS position 和 padding-top 也可以解決，但用 aspect-ratio 相對簡便一些。

文字CLS

在載入網頁字體時(font-face)，雖然 CSS 的 font-display:swap 解決了字體閃爍的問題，但字體變換的瞬間因不同字體有不同的軸、字重、字寬，所以依然會造成一瞬間的抖動(CLS 0.001~0.01 分左右)。

網路上常見的解答是：不改變(少量分數割捨)、改回瀏覽器原本就支援的字體、使用 CSS（size-adjust、ascent-override）校正、使用可變字體(variable fonts)、font loading API。

而Google教程也有提出文字CLS的解決方法：

• font-display: optional 會使網站字型只有在初始版面配置之前可用時，才會使用網頁字型。
• 使用與網頁字型類似的備用字型。舉例來說，使用 font-family: "Google Sans", sans-serif; 時，瀏覽器會在 "Google Sans" 載入時使用 sans-serif 備用字型。如未指定備用字型 (僅使用 font-family: "Google Sans")，會導致 Chrome 使用預設的 Serif 字型，但這種字型的效果較差。
• 使用新的 size-adjust、ascent-override、descent-override 和 line-gap-override API，盡量減少備用字型和網頁字型之間的大小差異。
• Font loading API 可以縮短字型載入時間。
• 使用 <link rel=preload> 盡快載入重要的字型。預先載入的字型較可能為第一次顯示做好準備，並且讓版面配置位移不會改變。

避免非合成動畫(non-composited animation)

你可以查看 High Performance Animations、Stick to Compositor-Only Properties and Manage Layer Count 這兩篇文章的說明，盡量選擇高效的動畫方式（transform），並避免過多的層級變化。

另外，web.dev 也簡單寫了一篇改善使用體驗核心指標的方法，讓大家有輕鬆優化網頁的應對方式。

網頁效能測量工具

• PageSpeed Insights：Google 推薦使用的網頁測速工具，內容完整，也有針對 Core Web Vitals 更新指標，例如會寫出 LCP 是指哪一個網頁元素、哪些元素使 CLS 分數增加。
• Lighthouse：若使用 chrome 或 edge 的話非常方便，直接打開 DevTools 就可以使用。
• WebPageTest：有提供 LCP 和 CLS 的數值。
• web vitals chrome 插件
• 用 Screaming Frog 大量檢測
• 其它

另外，一些工具像是 PageSpeed Insights 會用 TBT（總阻塞時間，Total Blocking Time）來取代 FID。TBT 是使用者在頁面被阻止響應（例如點擊、鍵盤輸入）的總時間，計算方式是 FCP 和 TTI 之間所有執行超過 50 毫秒的任務的阻塞時間總和。例如，一個功能耗時 70 毫秒，阻塞時間就是 20 毫秒。雖然 TBT 和 FID 的測量內容不同，但改進 TBT 通常都能改進 FID。

其實光是前2個工具就已經很夠用了，它們還能順便查看文字顏色對比度、PWA等各種問題。