# 什麼是 Web Vitals？

Web Vitals 是由 Google 提出衡量網站效能及使用體驗的量化指標，可以幫助開發者做為優化網站的參考。以使用者體驗為中心提出了三個改善面向，每個面向有以下各自對應的指標：

1. 載入速度(Loading Performance)
* **最大內容繪製 Largest Contentful Paint (LCP)**
* 首次顯示內容所需時間 First Contentful Paint (FCP)
* 第一個位元組時間 Time to First Byte (TTFB)

2. 互動反應能力(Interactivity)
* ~~**首次輸入延遲時間 First Input Delay (FID)**~~
* **與下一個顯示的內容互動 Interaction to Next Paint (INP)**
* 總封鎖時間 Total Blocking Time (TBT)

3. 視覺穩定性(Visual Stability)
* **累計版面配置位移 Cumulative Layout Shift (CLS)**

其中 **LCP**, **INP**, **CLS** 是三個較為重要代表各面向的核心指標，也就是我們常聽到的 **Core Web Vitals**。每項網站體驗核心指標都有相關門檻，可將效能分為「良好」、「需要改善」或「不良」

# 為什麼 Core Web Vitals 重要？

除了從指標分數可以看出網站使用體驗的好壞，對於 SEO 排名也有幫助。

# 如何測量 Core Web Vitals？

可依照得到資料的方式，分成不同類型的測量工具：

## 實驗資料 Lab data

測量工具會去模擬使用者的操作行為，使用模擬資料評分，提供可以重現的結果，適合用在產品開發階段做分析及驗證。

* [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview?hl=zh-tw)
* [Chrome DevTools Performance panel](https://developer.chrome.com/docs/devtools/performance?hl=zh-tw)

## 真實資料 Field data

也被稱為 Real User Monitoring(RUM)，實測工具會使用從真實使用者蒐集來的匿名使用行為資料評分，可以知道使用者真實體驗狀況，但分數也會受使用者當下裝置影響，例如使用者的網路狀況不佳，或是每個使用者會顯示不同的客製化資料，都會影響測量評分，因此可能會跟模擬測量結果有差距。

* [Chrome User Experience Report (CrUX)](https://developer.chrome.com/docs/crux/dashboard/?hl=zh-tw)
* [PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/?hl=zh-TW)
* [Search Console](https://search.google.com/search-console/about)
* [Web Vitals Chrome Extension](https://github.com/GoogleChrome/web-vitals-extension)
* [Firebase Performance Monitoring](https://firebase.google.com/docs/perf-mon?hl=zh-tw)
* [Performance — Web Vitals — knst-co-ltd — Sentry](https://knst-co-ltd.sentry.io/performance/browser/pageloads/?project=4504881304043520&statsPeriod=30d)

# 調適流程

## Step1: 評估網站健康狀態並找出改善空間

1. 使用 [PageSpeed Insights](https://pagespeed.web.dev/) 查看網站的整體 Core Web Vitals 狀況，以及個別網址的特定資訊

2. 使用 [Google Search Console](https://search.google.com/search-console/insights/about?hl=zh-tw)，找出哪些網頁需要改進

## Step2: 偵錯和最佳化

1. 於本機開發時使用 Lighthouse 發現問題

* Lighthouse 預設只會在網頁載入期間評估使用者體驗。因此排除了 FID 和 INP，改用 TBT。
* Lighthouse 會使用受限的 4G 連線，模擬中階行動裝置。這樣做可以找到在高速裝置和快速網際網路連線中不會出現的問題。這個模擬節流功能可能不符合網站使用者族群的使用者體驗。然而，這些指標可以顯示存在效能問題的位置，如果在 Lighthouse 發現問題獲得解決，可提升網站整體的效能。

2. 使用 Web Vitals Chrome Extension 進行即時分析
Web Vitals Chrome Extension 可以即時顯示網站體驗核心指標，並擷取到 FID, INP 和 CLS。

3. 使用 Chrome DevTools Performance panel 細查問題
Chrome DevTools Performance panel 可剖析所選時間範圍內的所有網頁行為

## Step 3：監控變化

1. 使用 [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci)
Lighthouse-CI 在 PR 時自動執行 Lighthouse 的稽核，避免發生效能迴歸問題，維持對效能的要求。通過設定的指標分數門檻後才能進行部署。

2. 透過真實資料查看網站健康狀態趨勢
效能提升幅度通常會在六個月內降低，修正問題後必須驗證真實產品環境中的指標分數是否真的有優化成功。

# 最佳化各指標的作法

每個指標有不同的優化方法，也會互相影響，因此在針對某個指標做調整時，也需要注意整體的分數。調整與優化的方法也需要視專案使用的前後端架構決定。在此紀錄目前已執行或一般常見可行的調整方向

## 最佳化 LCP

LCP 代表了網頁主要內容的載入速度，特別是從使用者開始載入網頁到在可視區域中轉譯最大圖片或文字區塊所需的時間。
有許多因素會影響瀏覽器載入及轉譯網頁的速度，只要任一因素發生延遲，就會對 LCP 造成重大影響。
在極罕見的情況下，只修正網頁的某個部分並不容易能有效改善 LCP。如要改善 LCP，請務必查看整個載入程序，確認過程中每個步驟都已最佳化。


必須確保所有子類別都經過最佳化，因為某些最佳化作業會將儲存在某一部分的時間轉移到另一個部分，而非實際減少 LCP。


### 優化圖片載入

圖片通常是 LCP 指標的重點項目，尤其是有使用 Banner 圖片時。優化方法：

1. 使用 WebP、AVIF 格式
- 不過需注意相容性問題
- ["WebP" | Can I use](https://caniuse.com/?search=WebP)
- ["AVIF" | Can I use](https://caniuse.com/?search=AVIF)

- 前端轉 webp 的方法

前端把圖片轉檔的方式是使用 [canvas.toBlob()](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob)
可以設定 quality 來設定轉換的壓縮品質，範圍 0~1，不指定的話瀏覽器會使用預設值。
mime type: image/jpeg 預設值為 0.92， image/webp 預設值為 0.8，而 image/png 本身為無損畫質的格式。
經測試與研究發現，使用這個方法，即使不指定參數 quality，瀏覽器仍然使用預設值進行有損壓縮。且 quality 設為 1 表示為最高質量，實際上仍為有損壓縮。


2. 移除大張圖片的 Lazy Load ! 請優先載入

* 使用 SSR (server-side rendering)

> 但可能也會對 TTFB 及 TTI 造成負面影響，需要整體性評估看是否有改善跑分

範例：使用 Nuxt.js 套件，可以在 asycData() 或是 fetch() 時先去取得圖片資料。若有使用 swiper 套件，可以更改設定參數與使用方法，使其在 server 端就渲染載入。請參考：[vue-awesome-swiper/README.md at master · davecat/vue-awesome-swiper · GitHub](https://github.com/davecat/vue-awesome-swiper/blob/master/README.md)


* 與資源服務器預先建立連線

使用 dns-prefetch 或是 preload

## 最佳化 CLS

避免版面配置突然改變，提升使用者體驗


### 設定圖片尺寸

* 設定 width、height 或 aspect-ratio

* 為延遲載入的內容保留空間

範例：

## 最佳化 TBT

總封鎖時間 (TBT) 會測量網頁無法回應使用者輸入內容的總時間長度，例如滑鼠點擊、螢幕輕觸或鍵盤按下。計算方式是在「首次顯示內容所需時間」和「互動時間」之間，將所有「長時間工作」中的「區塊」部分相加。

常見問題：降低第三方程式碼的影響。

範例：若有引入 GTM 或 GA 等套件，可以朝以下幾個方向進行優化：

* 非同步載入套件
* 空的 GTM 容器對頁面速度的影響很小。最大問題可能是添加到該容器中的標籤。但每個標籤都是不同的，其影響也可能有所不同。因此最終的結果是「視情況而定」
* 觸發標籤的時間越晚，它們產生的負面影響就越小
* 盡量避免直接對 DOM 的操作
* 移除容器中不必要（或不相關）的標籤。這將可以更輕鬆地使用標籤管理器，並有可能提高頁面速度

# 參考資料

* [Core Web Vitals  |  web.dev](https://web.dev/explore/learn-core-web-vitals?hl=zh-tw)
* [為什麼實驗資料和實際資料有差異 (以及處理方式)  |  Articles  |  web.dev](https://web.dev/articles/lab-and-field-data-differences?hl=zh-tw)
* [網站體驗核心指標工作流程和 Google 工具  |  Articles  |  web.dev](https://web.dev/articles/vitals-tools?hl=zh-tw)
* [最佳化最大內容繪製  |  Articles  |  web.dev](https://web.dev/articles/optimize-lcp?hl=zh-tw)
* [改善累計版面配置位移  |  Articles  |  web.dev](https://web.dev/articles/optimize-cls?hl=zh-tw)
* [改善與下一個顯示的內容的互動方式  |  Articles  |  web.dev](https://web.dev/articles/optimize-inp?hl=zh-tw)
* [總封鎖時間  |  Lighthouse  |  Chrome for Developers](https://developer.chrome.com/docs/lighthouse/performance/lighthouse-total-blocking-time?utm_source=lighthouse&utm_medium=lr&hl=zh-tw)
* [[前端優化系列]Web Vitals優化方法懶人包 | Eric Deng](https://gcdeng.com/series/frontend-performance-series/a-guidebook-to-optimize-web-vitals)
* [今晚，我想來點 Web 前端效能優化大補帖！ :: 2021 iThome 鐵人賽](https://ithelp.ithome.com.tw/users/20113277/ironman/3877)