多年以來,網路社群累積了豐富的網路效能最佳化知識。雖然任何一種最佳化方式都能改善許多網站的成效,但一次套用所有最佳化項目可能會讓您感到不知所措,而且實際上,只有部分最佳化項目適用於任何網站。
除非您是網路效能專家,否則可能很難判斷哪些最佳化措施對網站最有效。您可能沒有時間進行所有最佳化,因此請務必問問自己:「您可以選擇哪些最佳化措施,以便為使用者提升成效?」
關於效能最佳化,您必須瞭解以下事實:您無法單憑技術優點來判斷,您也必須考量人為和組織因素,評估自己能否實施特定最佳化做法。理論上,某些效能改善措施可能會帶來巨大影響,但實際上,很少開發人員有時間或資源實施這些措施。另一方面,也許有許多人已經在遵循成效最佳做法,本指南會說明以下網頁效能最佳化做法:
- 對實際情況產生最大影響
- 與大多數網站相關且適用
- 大多數開發人員都能實作
綜合來說,這些是改善 Core Web Vitals 指標最實際且有效的方式。如果您不熟悉網站效能,或是仍在決定如何提高投資報酬率,這篇文章就是最佳入門指南。
Interaction to Next Paint (INP)
Interaction to Next Paint (INP) 是最新的 Core Web Vitals 指標,也是最有機會改善的指標之一。不過,與已淘汰的前身相比,通過「良好」門檻的網站數量大幅減少,因此您可能會是許多開發人員中,第一次學習如何最佳化互動回應速度的開發人員。請先瞭解這些必知技巧,瞭解提升 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 Archive 的2024 年網路年鑑,73%的行動網頁都有圖片做為 LCP 元素。
- 根據 Chrome 的實際使用者資料分析,大部分 LCP 不佳的來源,其 p75 LCP 時間中,下載 LCP 圖片的時間只占 不到 10%。
- 在 LCP 不佳的網頁中,載入 LCP 圖片的延遲時間在第 75 百分位數時為 1,290 毫秒,這超過了快速體驗的預算一半。
- 在 LCP 元素為圖片的網頁中,35% 的圖片的來源網址無法在初始 HTML 回應 (例如
<img src="...">
或<link rel="preload" href="...">
) 中找到,因此瀏覽器的預先載入掃描器無法盡快發現這些圖片。 - 根據 Web Almanac 的資料,15% 的符合資格網頁都善用
fetchpriority
HTML 屬性,將資源的優先順序提高,包括那些可輕鬆改善網頁 LCP 的資源。
這些統計資料顯示,開發人員有很大機會可以減少 LCP 圖片的資源載入延遲和資源載入時間。
如果資源載入延遲是問題所在,請務必記住,如果網頁需要等待 CSS 或 JavaScript 完全載入後才能開始載入圖片,可能就無法達到良好的 LCP。此外,您也可以使用 fetchpriority
HTML 屬性重新調整 LCP 圖片的資源載入順序,以便接收更多頻寬,進而加快載入速度。
如果 LCP 元素是圖片,則應可在 HTML 回應中找到圖片的網址,以減少資源載入延遲時間。以下提供幾個訣竅:
- 使用含有
src
或srcset
屬性的<img>
元素載入圖片。請勿使用data-src
這類非標準屬性,因為這類屬性需要使用 JavaScript 才能顯示,因此速度會比較慢。7% 的網頁會將 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 使用資格」一節。
Browser Support
預先算繪使用者下一個造訪的網頁,是另一種大幅改善 LCP 成效的有效方法,而這項操作可透過 Speculation Rules API 執行。不過,如要實現這些效益,請務必預先轉譯正確的網頁。不正確的推測會浪費伺服器和用戶端的資源,進而影響效能。因此,您對下一頁的內容越不確定,就越應該謹慎預先算繪。如有疑問,您可以參考分析資料,更有把握地預先顯示最有可能成為下一個瀏覽頁面的網頁。
3. 使用 CDN 最佳化 TTFB
先前的建議著重於即時導覽,可為使用者提供最佳體驗,但在某些情況下,bfcache 和推測載入技術可能不適用。假設使用者按下跨來源連結前往您的網站,而初始 HTML 文件回應有效地阻斷 LCP。瀏覽器必須收到回應的第一個位元組,才能開始載入任何子資源。越早完成這項作業,其他作業就能越快開始。
這段時間稱為「第一個位元組時間 (TTFB)」。縮短 TTFB 的最佳方法如下:
- 盡可能提供與使用者所在位置相近的內容。
- 快取該內容,以便在近期內再次要求時快速提供。
如要同時達成這兩項目標,最佳做法就是使用 CDN。CDN 會將資源分發至全球各地的邊緣伺服器,因此可縮短這些資源透過網路傳送至使用者的距離。CDN 通常也提供精細的快取控制選項,可根據網站需求進行調整。
CDN 也可以提供及快取 HTML 文件,但根據 Web Almanac 的資料,只有 33% 的 HTML 文件要求是透過 CDN 提供。這表示網站有重大機會實現額外節省。
設定 CDN 時,請參考以下提示:
- 快取靜態 HTML 文件,即使時間很短也一樣。舉例來說,內容是否需要隨時更新?或者可以延遲幾分鐘嗎?
- 請查看是否可以將在原始伺服器上執行的動態邏輯移至邊緣,這是大多數新式 CDN 的功能。
只要您能直接從邊緣提供內容,並避免前往原始伺服器,就能提升效能。即使您必須將資料傳送到原始位置,CDN 通常會進行最佳化,以便更快速地傳送資料,因此無論如何,您都能獲得好處。
累計版面配置位移 (CLS)
累計版面配置位移 (CLS) 是評估網頁視覺穩定性的指標。雖然 CLS 是大多數網站的優良指標,但約四分之一的網站仍未達到建議門檻,因此許多網站仍有很大的改善空間,以提升使用者體驗。
1. 為從網頁載入的任何內容設定明確的尺寸
版面配置變更通常會在其他內容載入完畢後,現有內容移動時發生。改善 CLS 的主要方法,就是盡可能提前預留所需空間。
如要修正未指定大小的圖片造成的版面配置變動,最佳做法是明確設定 width
和 height
屬性或其等效的 CSS 屬性。66% 的網頁至少有一張未設定大小的圖片。如果沒有明確的大小,這些圖片的初始高度為 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。
如要進一步瞭解這裡未列出的最佳化方式,請參閱下列指南:
附錄:變更記錄
我們會在這裡追蹤這份文件的重大異動,以便說明重要最佳化建議何時及為何異動。
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 大會簡報,取得影片摘要。