Chrome DevRel 團隊認為，2023 年網站體驗核心指標表現最有效的方式，就是一系列的最佳做法。
多年來，Google 向網頁程式開發人員提出了許多可提升效能的建議。
每項建議都可以個別提升網站成效，但整體上的建議實在令人難以置信，在實際上，任何人或網站無法完全追蹤這些建議。
除非網站效能是你的日常工作，否則你可能無法辨別哪些建議對你的網站帶來最大正面影響。例如，您或許知道導入關鍵的 CSS 可以改善載入效能，而您或許也聽說了將圖片最佳化的重要性。但既然沒時間處理這兩件事，你該怎麼選擇要選擇哪一個？
Chrome 團隊去年花了很多時間，努力回答以下問題：對於協助開發人員改善使用者體驗，我們最建議提供了哪些重要建議？
為了充分回答這個問題，我們不僅要考量任何建議的技術優勢，還要考量會影響開發人員實際採用這些建議可能性的人工與組織因素。換句話說，有些建議或許在理論上具有顯著影響，但實際上只有極少數網站有充足的時間或資源來執行導入作業。同樣的，有些建議也很重要，但大多數網站都已採取這些做法。
簡言之，我們希望列出熱門網站成效建議，著重於：
- 我們認為的建議對實際影響
- 與大部分網站相關且適用的建議
- 適用於大多數開發人員應採行的真實建議
過去一年來，我們投入了大量時間稽核我們所提供的整套成效建議，並根據上述三項條件 (包括品質和量化) 進行評估。
本文將針對每個網站體驗核心指標指標，概略說明改善效能的重要建議。如果你是第一次使用網頁效能，或是想找出能夠帶來最多收益的策略，不妨先從這些建議做法著手。
最大內容繪製 (LCP)
我們第一組建議適用於最大內容繪製 (LCP)，也就是評估負載效能。在三項 Core Web Vitals 指標中，LCP 是目前網站上遇到最多問題的網站數量。目前網站上只有約半的網站符合建議門檻，現在就讓我們開始評估。
確認 LCP 資源可透過 HTML 來源探索
根據 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% 的網頁在data-src後方遮蓋了 LCP 圖片。偏好伺服器端算繪 (SSR) 而非用戶端算繪 (CSR)，因為 SSR 代表完整的網頁標記 (包括圖片) 位於 HTML 原始碼中。CSR 解決方案需要執行 JavaScript 才能找到圖片。
如果需要從外部 CSS 或 JS 檔案參照您的圖片，您還是可以透過
<link rel="preload">標記，在 HTML 原始碼中加入圖片。請注意，瀏覽器的預先載入掃描器無法找到內嵌樣式所參照的圖片，因此即使可在 HTML 原始碼中找到圖片，系統仍可能在載入其他資源時封鎖這些圖片，因此在這類情況下，預先載入功能可以派上用場。
為協助您瞭解 LCP 映像檔是否發生可偵測問題，Lighthouse 將於 2023 年 1 月推出 10.0 版新的稽核項目。
不過，確保能從 HTML 原始碼輕鬆找到 LCP 資源，不僅有助於改善成效，還能提高對資源的優先順序，這也是我們的下一項建議。
確保 LCP 資源已優先
確保使用者可從 HTML 來源發掘 LCP 資源，是確保 LCP 資源提早開始載入的重要步驟，但還有另一項重要步驟，就是確保資源的載入作業設為優先，不會排入許多其他較不重要的資源。
舉例來說，即使您的 LCP 圖片顯示在 HTML 原始碼中使用標準 <img> 標記，如果網頁在文件的 <head> 中之前有十多個 <script> 標記，則圖片資源可能需要一些時間才會開始載入。<img>
最簡單的解決方法，就是在會載入 LCP 圖片的 <img> 或 <link> 標記上設定新的 fetchpriority="high" 屬性，讓瀏覽器瞭解應優先處理哪些資源。如此即可指示瀏覽器提早載入指令碼，而非等待指令碼完成。
根據 Web Almanac 的研究指出，只有 0.03% 符合資格的網頁都能利用這個新的 API，這表示大部分網站皆可透過大量方式改善 LCP。雖然 fetchpriority 屬性目前僅適用於以 Chromium 為基礎的瀏覽器，但這個 API 是循序漸進的增強功能，其他瀏覽器現在會忽略這個 API，因此強烈建議開發人員立即使用。
對於非 Chromium 瀏覽器而言，如要確保 LCP 資源優先於其他資源，唯一的方法就是在文件中提前參照該資源。如要確保 LCP 資源的優先順序高於這些指令碼資源，可以再次使用文件 <head> 中許多 <script> 標記的網站範例，您可以在任何指令碼之前加上 <link rel="preload"> 標記，也可以稍後將這些指令碼移至 <body> 的 <img> 下方。雖然這個方式有效，但比使用 fetchpriority 更符合人體工學，因此我們期望其他瀏覽器能盡快支援這項功能。
決定 LCP 資源的優先順序還有另一個重點，就是確保您不會執行任何會導致資源優先順序降低的動作，例如新增 loading="lazy" 屬性。目前 10% 的網頁實際上設定了 loading="lazy" 的 LCP 圖片。請務必留意那些明顯將延遲載入行為套用至所有圖片的圖片最佳化解決方案。如果檔案提供覆寫該行為的方法，請務必將其用於 LCP 圖片。如果您不確定哪個圖片是 LCP，請嘗試利用經驗法則挑選合理的候選項目。
延遲非關鍵資源是有效提升 LCP 資源的相對優先順序的另一種方法。舉例來說，未驅動使用者介面的指令碼 (例如分析指令碼或社交小工具) 可以安全延期，直到 load 事件觸發為止，確保這些指令碼不會與其他重要資源 (例如 LCP 資源) 競爭網路頻寬。
總而言之，您應遵循下列最佳做法，確保能提早載入 LCP 資源，並將資源優先載入：
- 在 LCP 圖片的
<img>標記中新增fetchpriority="high"。如果是透過<link rel="preload">標記載入 LCP 資源，也不必擔心，因為您也可以在該標記上設定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 的訣竅如下：
- 請考慮增加快取內容的時間長度 (例如，內容是否必須保持新鮮感？還是有可能在幾分鐘後過時？)。
- 建議您甚至可以無限期快取內容，並在更新時清除快取內容。
- 探索您是否可以將目前在來源伺服器上執行的動態邏輯移至邊緣 (大多數新式 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。
儘管如此，有大量網站不符合使用 Bufcache 的資格，因此已經沒有機會在大量瀏覽的情況下取得免費網頁效能優勢。除非網頁正在載入機密資訊，但不想從記憶體中還原，否則建議您確保網頁符合顯示資格。
網站擁有者應檢查自己的網頁是否符合 Bfcache 條件，然後採取任何不相關的原因。Chrome 目前已在開發人員工具中設置 bfcache 測試人員，今年我們計劃推出新的 Lighthouse 稽核功能，執行類似的測試和實際執行方法的 API，藉此改良工具。
雖然 bfcache 已納入 CLS 部分，但我們發現目前為止收益最高，但 bfcache 通常也會改善其他網站體驗核心指標。而且是多種即時瀏覽功能之一，可大幅改善網頁瀏覽體驗。
避免使用執行版面配置的 CSS 屬性的動畫/轉場效果
版面配置位移的另一個常見原因，就是元素為動畫。舉例來說，從頂端或底部滑入的 Cookie 橫幅或其他通知橫幅，通常都是 CLS 的貢獻者。當這些橫幅將其他內容推移 360 時，就會發生這種問題。然而，即使內容並未加入動畫效果，仍會影響 CLS。
雖然 HTTP Archive 資料無法確切地將動畫與版面配置位移串連，但資料可以顯示，如果有網頁以動畫方式影響版面配置，「可能」影響版面配置的 CSS 屬性，「良好」CLS 的機率比網頁整體低了 15%。部分資源與 CLS 相關聯的情況較其他資源較差。舉例來說，如果網頁含有動畫 margin 或 border 寬度，CLS 代表「不佳」的 CLS 幾乎是網頁整體評估結果的兩倍。
這或許並不太意外，因為每次您轉換或製作任何版面配置相關的 CSS 屬性時，都會導致版面配置位移，而且如果版面配置的位移不會在使用者互動後的 500 毫秒內出現，就會對 CLS 造成影響。
部分開發人員可能會感到意外，因為即使元素是在正常文件流程之外移除的情況，也是如此。舉例來說，設有動畫 top 或 left 的絕對定位元素會導致版面配置位移，即使這些元素不會推送其他內容也一樣。然而，如果你不是為 top 或 left 加上動畫效果，而是建立 transform:translateX() 或 transform:translateY() 動畫，瀏覽器就不會更新網頁版面配置，也不會產生任何版面配置位移。
長久以來，想要在瀏覽器合成器執行緒上更新 CSS 屬性的動畫是最佳的效能最佳做法，該動畫會移至 GPU 並移出主執行緒。這除了是一般效能最佳做法，也有助於改善 CLS。
一般來說，除非您要讓使用者輕觸或按下按鍵來更新網頁版面配置，否則請勿為任何需要瀏覽器更新網頁版面配置的 CSS 屬性建立動畫或轉換 (但不是 hover)。請盡可能使用 CSS transform 屬性來轉換和動畫。
Lighthouse 稽核功能會避免使用非合成動畫，因此當網頁以動畫呈現可能速度緩慢的 CSS 屬性時，就會發出警告。
首次輸入延遲時間 (FID)
我們的最後一組建議是關於首次輸入延遲時間 (FID)，後者可評估網頁回應使用者互動的程度。雖然目前網路上大多數網站的 FID 都分數很高，但我們之前記錄了 FID 指標的缺點，相信網站仍有很大的機會可以改善網站對於使用者互動的整體回應能力。
新的「與下一個顯示的內容互動 (INP)」指標是 FID 的可能後續指標，而且下列所有建議同樣適用於 FID 和 INP。由於 INP 網站在 FID 方面的成效較 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 中的特定根層級進行隔離。這並非易事，但透過區隔包含複雜版面配置的區域，即可避免對不必要的版面配置和轉譯工作處理。
結語
改善網頁效能似乎是一項艱鉅的任務，尤其是因為網路上有大量值得參考的指引。不過，只要您著重這些建議，就能以專注和目的解決問題，可望進一步改善網站的網站體驗核心指標。
雖然本文列出的建議並非面面俱到，但我們相信，根據網路狀態的仔細分析，這些建議是網站在 2023 年改善網站體驗核心指標表現最有效的方式。
如果您想要跳脫上述建議，請參閱下列最佳化指南以瞭解詳情：
歡慶新年，並為所有人打造更快速的網路！讓使用者在最重要的方面，能夠提升您網站的速度。
相片由 Devin Avery 提供