Chrome DevRel 團隊認為，這是提升 2023 年 Core Web Vitals 效能最有效的方法系列。
多年來，Google 向網頁開發人員建議了可改善應用程式效能的方法。
雖然個別建議可能有助於提升許多網站的成效，但每一組建議可說是勢在過度勞累，在實際運作過程中，沒有任何個人或網站能依循這些建議。
除非網頁效能是您一天的工作，否則我們可能無法明確判斷哪種最佳化建議對網站帶來最大的正面影響。例如，您可能已經聽說，實作重要 CSS 可改善載入效能，您可能也聽說最佳化圖片很重要。但如果沒空完成這兩項工作，會怎麼挑選要優先完成的事項？
過去一年來，Chrome 團隊致力回答以下問題：我們能為開發人員提供哪些重要建議，協助他們提升使用者的效能？
為了妥善回答這個問題，我們不僅需要考量任何建議的技術利益，還要考量會影響開發人員確實採用這些建議的可能性，以及人員與組織的因素。換句話說，某些建議在理論上可能具有極大影響力，但實際上很少的網站才有時間或資源進行實作。同樣地，有些建議固然重要，但大多數的網站都已遵循這些做法。
簡而言之，我們希望熱門的網站成效建議清單著重於：
- 我們認為，能帶來最大實際影響的建議
- 適用於大多數網站且適用的建議
- 適合大多數開發人員實際採用的建議
過去一年來，我們花了很多時間稽核我們所採行的完整成效建議，並根據上述三項標準評估每個建議的成效 (包括品質和量化建議)。
本文將概述針對各項 Core Web Vitals 指標進行的改善效能建議。如果你是第一次接觸網站成效，或想找出能帶來最豐厚收益的策略，不妨先從這些建議開始著手。
最大內容繪製 (LCP)
我們第一組建議是針對負載效能評估的最大內容繪製 (LCP)。在三個 Core Web Vitals 指標中，LCP 是最多網站數量的困擾之一，目前網路上只有約一半的網站達到建議門檻，所以我們先從這裡著手。
確保可以從 HTML 來源找到 LCP 資源
HTTP Archive 的 2022 年 Web Almanac 指出，72% 的行動網頁會使用圖片做為 LCP 元素。也就是說，如果大多數網站為了最佳化 LCP 元素，都必須確保圖片可以快速載入。
對許多開發人員來說，載入圖片所需的時間只是一大挑戰。還有一個關鍵點，就是圖片開始載入「之前」的所需時間，而 HTTP 封存資料顯示這是許多網站最後會出現的時間點。
事實上，在 LCP 元素為圖片的網頁中，有 39% 的圖片含有無法透過 HTML 文件來源找到的來源網址。換句話說，在標準 HTML 屬性 (例如 <img src="..."> 或 <link rel="preload" href="...">) 中找不到這些網址，可讓瀏覽器快速找到並立即載入網址。
如果網頁需要等待 CSS 或 JavaScript 檔案完整下載、剖析及處理後，圖片甚至可以開始載入，表示圖片可能太晚。
一般而言，如果 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 映像檔是否發生搜尋問題，Lighthouse 將於 10.0 版 (預計為 2023 年 1 月) 發布新版稽核。
確保使用者可從 HTML 來源找到 LCP 資源，這有助於提高可評估的改善程度，同時也帶來其他優先處理資源的機會，這也是我們建議的做法。
確保 LCP 資源已優先顯示
請確保可供從 HTML 來源找到 LCP 資源，是確保 LCP 資源可提早開始載入的關鍵第一步。但另一項重要步驟是確保該資源的載入作業已「優先」，不會排入其他較不重要的資源排入佇列。
舉例來說，如果您的 LCP 圖片在使用標準 <img> 標記的 HTML 原始碼中，但如果網頁在 <img> 標記前的 <head> 中加入了十幾個 <script> 標記，可能需要一些時間才會開始載入圖片資源。
如要解決這個問題，最簡單的方法就是在載入 LCP 圖片的 <img> 或 <link> 標記上設定新的 fetchpriority="high" 屬性，告知瀏覽器哪些資源的優先順序最高。這樣會指示瀏覽器提早載入，而不要等待指令碼完成。
根據 Web Almanac 的資料，只有 0.03% 符合資格的網頁都採用這個新的 API。也就是說，網路上大部分網站都有很多機會改善 LCP。雖然目前只有以 Chromium 為基礎的瀏覽器支援 fetchpriority 屬性，不過其他瀏覽器只會忽略這個 API 的漸進式強化 API，因此強烈建議開發人員立即使用。
針對非 Chromium 瀏覽器，要確保 LCP 資源的優先順序高於其他資源，唯一的方法就是在文件前面參照。再次以某個網站的範例，在文件的 <head> 中加入大量 <script> 標記，如要確保 LCP 資源優先顯示在畫面上，您可以在這些指令碼前加上 <link rel="preload"> 標記，或者將這些指令碼移至之後的 <body> 下方 <img> 下方。雖然這能正常運作，但相較於使用 fetchpriority，這種做法較為符合人體工學，因此我們希望其他瀏覽器都能在不久後開始支援。
優先處理 LCP 資源的另一個重要面向是，確保您不會進行任何會導致資源降低優先順序的行為，例如新增 loading="lazy" 屬性。目前，有 10% 的網頁實際上在 LCP 圖片上設定了 loading="lazy"。請特別留意，不得對所有映像檔套用延遲載入行為的圖片最佳化解決方案。如果這類程式碼提供覆寫該行為的方法，請務必在 LCP 映像檔上使用該行為。如果您不確定哪一張圖片會是 LCP，請嘗試採取經驗法則，選出合理的候選項目。
將非關鍵資源延後是另一種有效提升 LCP 資源相對優先順序的方法。舉例來說，如果是不支援使用者介面的指令碼 (例如數據分析指令碼或社交小工具)，可以放心延後到 load 事件觸發後，才不會與其他重要資源 (例如 LCP 資源) 競爭網路頻寬。
總結來說，您應遵循下列最佳做法，確保 LCP 資源提早載入，並優先載入：
- 將
fetchpriority="high"加入 LCP 映像檔的<img>標記中。如果 LCP 資源是透過<link rel="preload">標記載入，別擔心，你也可以為此設定fetchpriority="high"！ - 請勿在 LCP 映像檔的
<img>標記上設定loading="lazy"。這麼做會降低圖片的優先順序，並在圖片開始載入時延遲。 - 盡可能延遲非關鍵資源。方法有兩種：使用圖片或 iframe 適用的原生延遲載入功能，或者透過 JavaScript 以非同步方式載入網頁，藉此將圖片移到文件結尾。
透過 CDN 最佳化文件和資源 TTFB
前兩項建議著重於確保能提早發現 LCP 資源並排定優先順序，以便立即開始載入。本謎題的最後一個部分，是確保最快收到初步文件的回應速度。
瀏覽器必須先收到初始 HTML 文件回應的第一個位元組，才能載入任何子資源，而且發生速度越快，其他所有子資源也就越多。
這個時間稱為第一個位元組時間 (TTFB)，減少 TTFB 的最佳方式為：
- 盡可能向靠近使用者的地理位置顯示內容
- 快取內容，方便系統快速重新提供最近要求的內容。
這兩項作業的最佳方式是使用 CDN。CDN 會將您的資源分散至遍布全球的邊緣伺服器，因此能限制這些資源透過線路傳輸給使用者的距離。CDN 通常也有精細的快取控制項，可依據網站需求自訂及最佳化。
許多開發人員都熟悉如何使用 CDN 託管靜態資產，但 CDN 也可以放送和快取 HTML 文件，即使是動態產生的文件也一樣。
Web Almanac 的資料顯示，只有 29% 的 HTML 文件要求是透過 CDN 提供，這表示網站可說是擁有額外節省成本的機會。
設定 CDN 的一些提示如下：
- 請考慮增加快取內容的快取時間長度 (例如，是否真的必須確保內容隨時更新？還是能夠更新到幾分鐘的時間？)。
- 您也許也會無限期快取內容，並在更新時清除快取。
- 探索您是否可以將目前在來源伺服器上執行的動態邏輯移至 edge (大多數現代 CDN 的功能)。
一般來說，凡是直接從邊緣提供內容 (避免行程原始伺服器) 都會對效能產生助益。就算您「必須」從原始伺服器回到原始伺服器，CDN 通常都會經過最佳化調整，能更迅速完成這項作業，因此雙方皆大歡喜。
累計版面配置位移 (CLS)
下一組建議是針對累計版面配置位移 (CLS)，用來評估網頁視覺穩定性。雖然 CLS 自 2020 年以來就大幅改善了網路內容，但約四分之一的網站仍未達到建議門檻。因此，許多網站仍存在可改善使用者體驗的大好機會。
為從網頁載入的所有內容設定明確的大小
版面配置位移通常發生在現有內容載入完成後，現有內容跟著移動。因此，降低這類影響的主要方法是事先預留所有必要空間。
如要修正因未調整大小圖片造成的版面配置位移，最直接的方法，就是明確設定 width 和 height 屬性 (或對等的 CSS 屬性)。不過，根據 HTTP 封存，72% 的網頁至少包含一張未大小的圖片。如果沒有明確尺寸，瀏覽器一開始會將預設高度設為 0px，接著在圖片最終載入且系統發現尺寸時，可能明顯的版面配置位移。這對社會大眾來說是絕佳的契機，比起本文其他建議，能省下許多心力，把握這個大好機會。
此外，也請留意，圖片並非只有 CLS 的貢獻者。如果其他內容通常是在網頁首次轉譯後載入，包括第三方廣告或內嵌影片，都可能造成版面配置位移。aspect-ratio 屬性可協助您解決這個問題。這是相對新的 CSS 功能，可讓開發人員明確提供圖片和非圖片元素的顯示比例。這樣一來，您就可以設定動態 width (例如根據螢幕大小)，瀏覽器會自動計算適當的高度，和處理尺寸圖片的方式大致相同。
動態內容由於其本質非常動態，因此有時會無法確認確切大小。不過，即使您不知道確切的大小，還是可以採取措施來降低版面配置位移的嚴重性。在大部分的情況下，設定合理的 min-height 會比允許瀏覽器對空白元素使用 0px 的預設高度更好。使用 min-height 通常也是一種簡單的修正方法，因為這個做法仍可讓容器視需要擴充至最終內容高度，這只是大幅減少了從完整量，到最好可容許的程度。
確認網頁可採用 bfcache 處理
瀏覽器會使用一種稱為往返快取 (或簡稱 bfcache) 的導覽機制，直接從記憶體快照從瀏覽器記錄中立即載入頁面，或稍後載入網頁。
bfcache 是在瀏覽器層級的效能最佳化，可完全消除載入網頁期間的版面配置位移；對許多網站而言，這是大多數網站都發生 CLS 的情況。bfcache 引入之後，這是 2022 年對 CLS 最大的改善。
儘管如此，有大量網站無法使用 bfcache 顯示，因此在大量瀏覽的情況下，將錯失此免費網站效能的優勢。除非網頁正在載入您不希望從記憶體還原的機密資訊，否則請確保網頁符合資格。
網站擁有者應檢查自己的網頁是否符合 bfcache 處理資格，並設法解決任何無法載入的原因。Chrome 目前已經在開發人員工具中提供 bfcache 測試工具，今年我們計劃進一步強化這項工具的功能，包括針對類似的測試執行全新的 Lighthouse 稽核作業，以及在實際環境中評估這項數據的 API。
雖然我們已在 CLS 部分納入 bfcache，但由於至今收益最大，bfcache 通常也能改善其他 Core Web Vitals 指標。這有多種即時導覽功能，可大幅改善網頁瀏覽體驗。
避免使用版面配置構成 CSS 屬性的動畫/轉場效果
另一個常見的版面配置位移，是在元素建立動畫時。例如，Cookie 橫幅或其他從頂端或底部滑入的通知橫幅，通常是 CLS 的貢獻者。這種情況尤其容易發生問題 (即使這些橫幅會將其他內容推送到一邊)，但即使如此，以動畫方式呈現內容仍可能影響 CLS。
雖然 HTTP 封存資料無法明確將動畫與版面配置位移建立關聯，但資料顯示，若網頁含有任何「可能」影響版面配置的 CSS 屬性動畫，則「良好」的可能性降低了 15%相較於整體網頁數量的 CLS。某些屬性所連結的 CLS 較其他屬性更差。舉例來說，如果網頁的寬度為 margin 或 border 寬度，顯示「不佳」CLS 幾乎是網頁整體評為不良率的兩倍。
這種做法或許並不令人意外，因為每當您轉換或為任何版面配置內的 CSS 屬性建立動畫或動畫時，都會導致版面配置位移，而且如果這些版面配置的位移不在使用者互動後的 500 毫秒內，就會影響 CLS。
有些開發人員可能會感到驚訝，舉例來說，絕對位置的元素會使 top 或 left 產生動畫效果，即使元素不會推送其他內容，也會導致版面配置位移。不過，如果為 transform:translateX() 或 transform:translateY() 加上動畫效果，而不是為 top 或 left 加上動畫效果，這不會造成瀏覽器更新網頁版面配置，也因此不會產生任何版面配置位移。
一直以來，如果 CSS 屬性可在瀏覽器的合成器執行緒上更新，就一直採用效能最佳做法，因為這類屬性會將工作移到 GPU 上並離開主執行緒。這個最佳做法不僅是一般的效能最佳做法，也有助於改善 CLS。
一般來說，請勿在需要瀏覽器更新網頁版面配置的 CSS 屬性中加入動畫或轉換效果，除非您為了回應使用者輕觸或按下按鍵而執行此動作 (但不是 hover)。此外，請盡可能使用 CSS transform 屬性使用轉場效果和動畫。
Lighthouse 稽核作業「避免使用非合成動畫」會在網頁動畫呈現 CSS 屬性可能速度可能變慢時發出警告。
首次輸入延遲時間 (FID)
我們最後一組建議是首次輸入延遲 (FID)，這個指標衡量的是網頁對使用者互動的反應。儘管目前大多數網站在 FID 上的得分非常高，但仍已記錄過去 FID 指標的不足之處，相信網站仍有許多機會提升網站與使用者互動的整體回應能力。
我們新的「與下一個繪製內容互動 (INP)」指標是 FID 的後續差異，以下所有建議同樣適用於 FID 和 INP。由於網站在 INP 上的成效低於 FID (尤其是在行動裝置)，因此建議開發人員審慎考量這些回應式建議，但即使經營「良好」也一樣FID。
避免或分散長時間執行的工作
工作是指瀏覽器執行的獨立工作。工作包括轉譯、版面配置、剖析，以及編譯和執行指令碼。當工作變成「長時間工作」(等於 50 毫秒) 後，主執行緒就無法快速回應使用者輸入內容，
根據 Web Almanac 規定，大量證據指出開發人員可以投入更多心力，避免或處理長時間的工作。雖然比起本文未提供的其他技術建議，分割長時間工作可能並不容易，但相關工作少於本文未提供的其他技巧。
雖然您應盡量在 JavaScript 中盡量減少工作，但您可以將很長的任務分割成較小的工作，大幅簡化主執行緒。您可以經常顯示主執行緒，加快算繪更新和其他使用者互動的速度。
或者，您也可以考慮使用 isInputPending 和 Scheduler API 等 API。isInputPending 是會傳回布林值的函式，用於指出使用者輸入內容是否待處理。如果傳回 true，您可以引發主執行緒，以便處理待處理使用者輸入內容。
Scheduler API 是一項先進的方法，可讓您根據優先順序系統來安排工作，這些作業會考量使用者是否能看到或在背景執行工作。
拆開長時間工作後，瀏覽器就能有更多機會處理使用者可見的重要工作，例如處理互動和出現任何轉譯更新。
避免不必要的 JavaScript
別擔心，網站的 JavaScript 比以往更多，而且這個趨勢也似乎不會隨時變動。當使用者傳送過多 JavaScript 時，會使得工作在主執行緒之間相互競爭。這絕對會影響網站的回應速度，特別是在重要的啟動期間。
但這並不是無法解決的問題。您可以採取下列做法：
- 請使用 Chrome 開發人員工具的涵蓋率工具，在您網站的資源中找出未使用的程式碼。縮減啟動期間所需的資源大小，即可確保網站不需花費太多時間剖析及編譯程式碼，進而提供流暢的初始使用者體驗。
- 有時候，您使用涵蓋率工具發現未使用的程式碼，會標示為「未使用」因為未在啟動期間執行，但未來某些功能仍然需要此函式。這是一種程式碼，可讓您透過程式碼分割功能移至其他套件。
- 如果您使用代碼管理工具，請務必定期檢查代碼，確定代碼皆已最佳化，即使代碼仍在使用中亦然。您可以清除含有未使用程式碼的舊代碼，將代碼管理工具的 JavaScript 變小和效率提升。
避免大量轉譯更新
JavaScript 並不是唯一會影響網站回應速度的因素，轉譯作業可獨立執行成本昂貴的工作，如果大型轉譯需要更新，就可能會影響網站回應使用者輸入內容的能力。
最佳化轉譯工作並非一蹴可幾，通常取決於您想達成的目標。即便如此，您可以採取一些步驟，確保轉譯作業的更新合理性，不會分散在長時間的工作中：
- 避免使用
requestAnimationFrame()執行任何非影像工作。在事件迴圈的轉譯階段，requestAnimationFrame()呼叫會處理，如果在此步驟中處理太多工作，轉譯更新可能會延遲。因此請務必將與requestAnimationFrame()相關的任何工作保留給涉及轉譯更新的工作。 - 縮減 DOM 的大小。DOM 大小和版面配置工作強度彼此相關。當轉譯器必須更新極大型 DOM 的版面配置時，重新計算版面配置所需的工作可能會大幅增加。
- 使用 CSS 納入。CSS 納入作業需要仰賴 CSS
contain屬性，該屬性會指示瀏覽器如何對所設定contain屬性的容器執行版面配置工作，包括將版面配置範圍隔離到 DOM 中的特定根層級。這個程序不一定容易，但只要區隔含有複雜版面配置的區域，就能避免不必要的版面配置和算繪作業。
結論
要提升網頁效能看似困難，尤其是網路上有豐富的指引要考量。不過，只要著重於這些建議，就能根據重點和目的解決問題，希望能進一步提升網站的 Core Web Vitals 指標成效。
雖然這裡列出的建議並非詳盡無遺，但根據仔細分析網站狀態，我們認為這些建議是讓網站在 2023 年改善 Core Web Vitals 成效的最有效方式。
如果您不想採用這裡列出的建議，請參閱下列最佳化指南以瞭解詳情：
讓我們一起迎接新的一年，並享受更快速的網路世界！方便使用者快速瀏覽網站。
相片來源：Devin Avery