改善 Core Web Vitals 最有效的方法

多年來，網路社群累積了很豐富的網站效能最佳化知識。雖然一個最佳化可能可以改善許多網站的效能，但一次全部的網站可能會讓人感到不知所措，而且實際上只有部分網站適用於任一網站。

除非您是網路效能專家，否則可能很難判斷哪些最佳化措施對網站最有效。您可能沒有時間進行所有最佳化，因此請務必問問自己：「您可以選擇哪些最佳化措施，以便為使用者提升成效？」

關於效能最佳化，您必須瞭解以下事實：您無法單憑技術優點來判斷，您也必須考量人為和組織因素，評估自己能否順利實施任何最佳化措施。理論上，某些效能改善措施可能會帶來巨大影響，但實際上，很少開發人員有時間或資源實施這些措施。另一方面，也許有許多人已經在遵循成效最佳做法，本指南會說明以下網頁效能最佳化做法：

• 對實際情況產生最大影響
• 與大多數網站相關且適用
• 大多數開發人員都能實作

整體而言，以下這些都是您實際可行且能有效改善Core Web Vitals 指標的方法。如果你是第一次接觸網站成效，或目前仍在決定投資報酬率最高的投資報酬率，不妨從這裡著手。

與下一個顯示的內容互動 (INP)

根據最新的 Core Web Vitals 指標，「與下一個繪製內容的互動 (INP)」有許多重大改進機會。不過，與已淘汰的前身相比，通過「良好」門檻的網站數量大幅減少，因此您可能會是許多第一次學習如何最佳化互動回應速度的開發人員之一。請先瞭解這些必知技巧，瞭解提升 INP 的最佳方法。

1. 經常產生中斷，以便分割長時間的工作

工作是指瀏覽器執行的任何個別工作，包括轉譯、版面配置、剖析、編譯或執行指令碼。如果工作持續時間超過 50 毫秒，就會成為長時間工作。長時間的工作會造成問題，因為它們會阻斷主執行緒對使用者互動做出快速回應。

雖然您應該盡量減少在 JavaScript 中執行的工作，但您可以分割長時間的工作，協助主執行緒。您可以經常讓出主要執行緒，以便顯示更新和其他使用者互動更快發生。

Scheduler API 可讓您使用優先順序系統排入工作。具體來說，scheduler.yield() API 會分割長時間的工作，同時確保可處理互動，而不會放棄工作佇列中的位址。

將長時間的作業分割後，瀏覽器就能有更多機會執行重要且會阻斷使用者的作業。

2. 避免使用不必要的 JavaScript

網站傳送的 JavaScript 比以往更多，而且這種趨勢似乎不會改變。如果您提供過多的 JavaScript，就會建立一個工作會爭取主執行緒注意力的環境。這可能會影響網站的回應速度，尤其是在啟動期間。

不過，這並非無法解決的問題，您可以採取以下做法：

• 使用基準廣泛可用的網路平台功能，而非冗餘的 JavaScript 實作。
• 請使用 Chrome 開發人員工具中的涵蓋率工具，找出指令碼中未使用的程式碼。藉由縮減啟動期間所需的資源大小，即可確保網頁不需花費太多時間剖析及編譯程式碼，從而提供更順暢的初始使用者體驗。
• 使用程式碼分割功能，為初始轉譯作業不需要的程式碼建立個別套件，但仍可在日後使用。
• 如果您使用代碼管理工具，請定期最佳化代碼。您可以移除含有未使用程式碼的舊代碼，以減少代碼管理工具的 JavaScript 足跡。

3. 避免大量轉譯更新

JavaScript 執行只是影響網站回應速度的一個因素。算繪本身就是一項耗時的工作，在進行大型算繪更新時，網站可能會對使用者互動反應更慢。

最佳化轉譯工作並不容易，一切都取決於您想達成的目標。即便如此，您還是可以採取下列措施，確保算繪工作不會變成長時間工作：

• 重新排序 JavaScript 程式碼中的 DOM 讀取和寫入作業，以免發生強制版面配置和版面配置衝突。
• 保持 DOM 精簡。DOM 大小和版面配置工作的強度有相關。當轉譯器必須更新極大型 DOM 的版面配置時，重新計算版面配置所需的工作可能會大幅增加。
• 使用 CSS 容器，以便延遲轉譯畫面外的 DOM 內容。這項作業不一定簡單，但只要隔離含有複雜版面配置的區域，就能避免不必要的版面配置和轉譯作業。

最大內容繪製 (LCP)

最大內容繪製時間 (LCP) 是開發人員最常遇到的 Core Web Vitals 問題。Chrome 使用者體驗報告中的 40%網站未達到建議的 LCP 門檻，無法提供良好的使用者體驗。Chrome 團隊建議採用下列技術，以最有效的方式改善 LCP。

1. 確保 LCP 資源可從 HTML 原始碼中找到並優先顯示

Chrome 團隊針對網站上的 LCP 發現以下事項：

• 根據 HTTP 封存的2022 年網路年鑑，72% 的行動網頁都有圖片做為 LCP 元素。
• 根據 Chrome 的實際使用者資料分析，大部分 LCP 不佳的來源，其 p75 LCP 時間中，下載 LCP 圖片的時間只占 不到 10%。
• 在 LCP 不佳的網頁中，在用戶端載入 LCP 圖片時，在第 75 個百分位數會延遲 1,290 毫秒；超過預算的一半是提供快速體驗的一半。
• 在 LCP 元素為圖片的網頁中，39% 的圖片的來源網址無法在初始 HTML 回應 (例如 <img src="..."> 或 <link rel="preload" href="...">) 中找到，因此瀏覽器的預先載入掃描器無法盡快發現這些圖片。
• Web Almanac 指出，只有 0.03% 符合資格的網頁都利用 fetchpriority HTML 屬性，為資源提供更高的優先順序，包括只需稍微費心改善網頁 LCP。

這些統計資料顯示，開發人員把握龐大商機，減少 LCP 圖片的資源載入延遲和資源載入時間。

如果資源載入延遲是問題所在，請務必記住，如果網頁需要等待 CSS 或 JavaScript 完全載入，才能開始載入圖片，那麼要達到良好的 LCP 可能已經太晚了。此外，您也可以使用 fetchpriority HTML 屬性重新調整 LCP 圖片的資源載入順序，以便接收更多頻寬，進而加快載入速度。

如果 LCP 元素是圖片，則應在 HTML 回應中找出圖片的網址，以減少資源載入延遲時間。以下提供幾個訣竅：

• 使用含有 src 或 srcset 屬性的 <img> 元素載入圖片。請勿使用需要 JavaScript 才能算繪的非標準屬性 (例如 data-src)，因為這類屬性速度會越慢。9% 的網頁會將 LCP 圖片遮蓋在 data-src 後方。
• 優先採用伺服器端轉譯 (SSR)，而非用戶端轉譯 (CSR)，因為 SSR 表示 HTML 來源中包含完整的網頁標記 (包括圖片)。CSR 解決方案需要先執行 JavaScript，才能找到圖片。
• 如需從外部 CSS 或 JS 檔案參照圖片，仍可使用 <link rel="preload"> 標記在 HTML 原始碼中加入圖片。請注意，瀏覽器的預先載入掃描器無法搜尋內嵌樣式所參照的圖片，因此即使在 HTML 原始碼中找到這些圖片，載入其他資源時仍可能無法存取這些圖片，因此預先載入功能或許會有幫助。

此外，您可以透過確保 LCP 資源及早載入，並且優先載入，以縮短資源的載入時間：

• 在 LCP 圖片的 <img> 或 <link rel="preload"> 標記中加入 fetchpriority="high" 屬性。這會提高圖片資源的優先順序，讓圖片資源更快開始載入。
• 從 LCP 圖片的 <img> 標記中移除 loading="lazy" 屬性。這樣可避免因確認圖片是否顯示在檢視區或檢視區附近而造成的載入延遲。
• 盡可能延遲非必要資源。將這些資源移至文件結尾、延後載入圖片或iframe，或是使用 JavaScript 以非同步方式載入這些資源，有助於讓 LCP 圖片等重要資源更快載入。

2. 以即時導覽為目標

理想的使用者體驗是完全不需要等待網頁載入。對於資源可偵測性和優先順序等 LCP 最佳化作業，能有效減少使用者等待 LCP 元素載入及顯示的時間，但對於這些位元組透過網路載入和顯示在網頁上的速度，設有實際限制。在達到這個極限之前，您必須付出極大努力，才能再節省幾毫秒的時間。因此，為了實現即時導覽，我們必須採用截然不同的方法。

即時導覽會在使用者開始瀏覽「之前」嘗試載入並轉譯網頁。這樣一來，預先算繪的網頁就能立即顯示，且 LCP 幾乎為零。還原和推測是兩種做法。使用者返回或前往先前造訪過的網頁時，他們可以從記憶體內快取迅速還原，完全看似使用者離開網頁。或者，網頁應用程式也可以嘗試預測使用者下一個前往的網頁，如果預測正確，使用者前往該網頁時，系統就會已載入並轉譯下一個網頁。

您可以透過往返快取 (bfcache) 還原先前造訪過的網頁。如要使用此功能，請務必確保網頁符合 bfcache 資格條件。網頁不符合使用 bfcache 的常見原因，是因為這些網頁使用 no-store 快取指示，或是有 unload 事件監聽器。

還原已完全轉譯的網頁，不僅可改善載入效能，還能提升版面配置的穩定性。如要進一步瞭解 bfcache 以及如何有效改善 CLS，請參閱「確保網頁符合 bfcache 使用資格」一節。

預先轉譯使用者造訪的下一個網頁，是大幅改善 LCP 效能的一種有效方式。為此，我們採用了 Speculation Rules API。不過，如要實現這些效益，請務必預先算繪正確的網頁。不正確的推測會浪費伺服器和用戶端的資源，進而影響效能。所以您對下一頁的信心就會越低，在預先轉譯時應較為保守。如有疑慮，您可以利用數據分析資料，放心地預先算繪出下一個訪客最有可能造訪的網頁。

3. 透過 CDN 最佳化 TTFB

先前的建議著重於即時導覽，因此可為使用者提供最佳體驗，但某些情況下，bfcache 和推測載入技術可能不適用。假設使用者按下跨來源連結前往您的網站，而初始 HTML 文件回應有效地阻斷 LCP。瀏覽器必須收到回應的第一個位元組，才能開始載入任何子資源。越早完成這項作業，其他作業就能越快開始。

這段時間稱為「第一個位元組時間 (TTFB)」。縮短 TTFB 的最佳方法如下：

• 盡可能提供與使用者所在位置相近的內容。
• 快取該內容，以便在近期內再次要求時快速提供。

如要同時執行這兩項操作，最佳做法就是使用 CDN。CDN 會將資源分發至全球各地的邊緣伺服器，因此可縮短這些資源透過網路傳送至使用者的距離。CDN 通常也有精細的快取控制項，可以根據網站需求調整。

CDN 也可以提供及快取 HTML 文件，但根據 Web Almanac 的資料，只有 29% 的 HTML 文件要求是由 CDN 提供。這表示網站有重大機會實現額外節省。

設定 CDN 的一些提示包括：

• 快取靜態 HTML 文件，即使時間很短也一樣。舉例來說，內容是否需要隨時更新？或者可以延遲幾分鐘嗎？
• 請查看是否可以將在原始伺服器上執行的動態邏輯移至邊緣，這是大多數新式 CDN 的功能。

只要您能直接從邊緣提供內容，並避免前往原始伺服器，就能提升效能。即使您必須將資料傳送到原始位置，CDN 通常會進行最佳化，以便更快速地傳送資料，因此無論如何，您都能獲得好處。

累計版面配置位移 (CLS)

累計版面配置位移 (CLS) 是評估網頁視覺穩定性的指標。雖然 CLS 是大多數網站的優良指標，但約四分之一的網站仍未達到建議門檻，因此許多網站仍有很大的改善空間，可提升使用者體驗。

1. 為從網頁載入的所有內容設定明確的大小

當其他內容載入完畢後，現有內容移動時，通常會發生版面配置變更。改善 CLS 的主要方法，就是盡可能提前預留所需空間。

如要修正未指定大小的圖片造成的版面配置變動，最佳做法是明確設定 width 和 height 屬性或其等效的 CSS 屬性。72% 的網頁至少有一張未設定大小的圖片。如果沒有明確的大小，這些圖片的初始高度為 0px，這可能會導致在這些圖片載入及瀏覽器偵測到其尺寸時，造成版面配置偏移。這對集結網路來說是龐大的商機，比起本指南建議的一些其他建議，能花更少的心力，把握這個商機。

圖片並非 CLS 的唯一影響因素。版面配置可能會因其他內容而產生位移，這些內容通常會在網頁初始轉譯後載入，包括第三方廣告或嵌入的影片。這時可以使用 aspect-ratio 屬性。這項基準 CSS 功能可供開發人員明確設定圖片和非圖片元素的顯示比例。這樣做可讓您設定動態 width (例如根據螢幕大小)，瀏覽器會自動計算適當的高度，和處理尺寸圖片的方式類似。

不過，動態內容的確切大小不一定能得知。即使您不知道確切大小，仍可降低版面配置位移的嚴重程度。設定合理的 min-height 通常比讓瀏覽器為空元素使用預設高度 0px 更為理想。使用 min-height 通常也是簡單的修正方式，因為它仍可讓容器視需要放大至最終內容的高度，只是將放大量減少到更容易接受的程度。

2. 確保網頁符合 bfcache 的使用資格

如本指南前述，往返快取 (bfcache) 會從記憶體快照中，立即載入瀏覽器記錄中較早或較晚的網頁。雖然 bfcache 是一種可改善 LCP 的瀏覽器層級效能最佳化功能，但它也能完全消除版面配置位移。事實上，2022 年推出的 bfcache 是當年 CLS 改善幅度最大的因素。

儘管如此，許多網站不符合使用 bfcache 的資格，因此無法享有這項免費的網站效能優勢。除非網頁正在載入機密資訊，否則不希望從記憶體中還原，請確保網頁符合使用 bfcache 的資格。

網站擁有者應檢查網頁是否符合 bfcache 使用資格，並修正任何導致不符合資格的因素。Chrome 在開發人員工具中提供 bfcache 測試工具，您也可以使用 Not Restored Reasons API 偵測欄位中的不符資格原因。

3. 避免使用會影響版面配置的 CSS 屬性製作動畫和轉場效果

另一個常見的版面配置位移原因，是元素有動畫效果。舉例來說，從頂端或底部滑入的 Cookie 橫幅或其他通知橫幅，通常會導致 CLS 增加。當這些橫幅會將其他內容推到畫面外時，這個問題就會特別嚴重，但即使不會，加入動畫效果仍會影響 CLS。

雖然 HTTP 檔案庫資料無法明確將動畫與版面配置變化連結，但資料確實顯示，如果網頁為任何「可能」影響版面配置的 CSS 屬性設定動畫，則相較於整體網頁，其「良好」CLS 的機率會降低 15%。部分資源的 CLS 比其他資源更糟。舉例來說，如果網頁會為 margin 或 border 寬度設定動畫，CLS 評分為「差」的機率幾乎是整體網頁評分為差的兩倍。

這可能不會讓您感到意外，因為每當您轉換或為任何版面配置誘發 CSS 屬性時，都會導致版面配置移位。如果這些版面配置位移不在使用者互動後的 500 毫秒內，則會影響 CLS。

有些開發人員可能會感到驚訝，舉例來說，即使不會推送其他內容，以絕對定位方式呈現 top 或 left 的動畫元素，也會導致版面配置移位。不過，如果您為 transform:translateX() 或 transform:translateY() 設定動畫，而非 top 或 left，瀏覽器就不會更新網頁版面配置，因此可避免版面配置偏移。

長久以來，偏好動畫的 CSS 屬性，可在瀏覽器的轉換器執行緒中更新，這一直是效能最佳做法，因為這會將工作從主執行緒移至 GPU。這項最佳做法不僅是一般的效能最佳做法，也有助於改善 CLS。

一般來說，除非是為了回應使用者輕觸或按下按鍵 (但不是 hover)，否則請勿為需要瀏覽器更新網頁版面的 CSS 屬性設定動畫或轉場效果。盡可能使用 CSS transform 屬性，設定轉場效果和動畫。

當網頁使用可能會造成速度變慢的 CSS 屬性動畫時，Lighthouse 稽核會發出「避免使用非合成的動畫」警告。

結論

改善網頁成效可能會讓您感到困惑，尤其是在網路上有大量指南可供參考的情況下。不過，只要專注於這份最有效的最佳做法清單，就能重新著手解決問題，並希望能改善網站的 Core Web Vitals。

如要進一步瞭解這裡未列出的最佳化方式，請參閱下列指南：

• 將 INP 最佳化
• 最佳化 LCP
• 最佳化 CLS

附錄：變更記錄

我們會追蹤這份文件的重大變更，以說明重要建議變更的時間和原因。

2024 年 10 月

2024 年更新：

• INP
  • 我們已將這項指標從 FID 改為 INP，以便在 Core Web Vitals 中推出 INP 指標，並將其設為清單中的首要指標。
  • 我們已撤銷建議使用 isInputPending API 來分割長時間工作。如要進一步瞭解我們的考量，請參閱「最佳化長時間工作」一文。
• LCP
  • 我們將可搜尋性和優先順序的最佳化建議合併為一項建議。
  • 我們新增了可實現即時導航的新建議。

2023 年 1 月

以下是初始的最佳化建議清單：

• LCP
  • 確保 LCP 資源可從 HTML 來源偵測
  • 確保 LCP 資源優先處理
  • 使用 CDN 最佳化文件和資源的 TTFB
• CLS
  • 為從網頁載入的任何內容設定明確的大小
  • 確保網頁符合往返快取資格
  • 避免使用版面配置傳入 CSS 屬性的動畫和轉場效果
• FID
  • 避免或分散長時間執行的工作
  • 避免使用不必要的 JavaScript
  • 避免大型轉譯更新

你也可以觀看這份 2023 年 Google I/O 大會簡報，取得影片摘要。