Google 2021 年 5 月更新：深入了解 Core Web Vitals
已發表: 2021-07-19更新：數字營銷的世界在不斷變化，但別擔心，我們處於領先地位。 谷歌改變了對即將推出的算法的看法。
在我們的更新中閱讀最近的更改，但也可以閱讀此博客。
2021 年 5 月，Google 將引入 Core Web Vitals (CWV) 指標，以構成其搜索排名算法的一部分。 這是您需要知道的，然後在此之前做……
我們都知道快速網站很重要。 它們創造了更好的用戶體驗，從而提高了轉化率，並且已經將 Google 中的移動搜索排名以及其他頁面體驗指標（如移動友好性）考慮在內。
但谷歌並沒有就此止步。 早在 2020 年 5 月，他們就向我們介紹了 Core Web Vitals，並在 2020 年 11 月 10 日宣布，在 2021 年 5 月，Core Web Vitals 將作為搜索信號納入整體排名算法。
此外，他們計劃“測試一個視覺指示器，該指示器可以突出顯示具有出色頁面體驗的搜索結果中的頁面。” 因此，我們不僅通過 CWV 優化獲得更高排名的機會，而且我們還有可能提高搜索引擎結果頁面的點擊率。
立即採取行動來審核和修復這些新的 CWV 指標標記的任何潛在問題，這將使我們的網站有更好的機會在 2021 年此更改生效時獲得更高的 Google 排名。
但首先，回顧一下……
回顧：什麼是 Core Web Vitals？
Core Web Vitals 是一組包含 3 個新頁面體驗指標的集合，這些指標會影響整體網站速度得分。 這些指標已經在 Google 的 PageSpeed Insights 工具 PSI 和其他地方的 Lighthouse 性能監控中發揮了重要作用。
新的 CWV 指標包括以下內容： 
最大的內容繪製 (LCP)
這是折疊元素上方最大元素呈現給用戶之前所用的時間。 它佔整體速度評分機制的 25%，因此對於將最大的項目在移動設備上的交付時間簡化為 2.5 秒或更低至關重要。
許多因素導致高 LCP，包括服務器響應能力、渲染阻塞腳本和样式、CSS 的複雜性、字體和圖像
首次輸入延遲 (FID)
這衡量了交互性； 頁面對用戶輸入的響應程度如何，例如通過點擊或點擊。 瀏覽器響應第一次輸入的目標速度應為 100 毫秒或更短。
如果瀏覽器在頁面加載期間解析或執行大量 JavaScript，這將佔用 CPU 或阻塞“主線程”，導致設備對輸入的響應變慢。 高 FID 通常是 JavaScript 複雜的指標。 這可以是單個腳本或函數或多個腳本。
現有的用於交互時間和總阻塞時間的 PSI 指標與 FID 相關，並且總共佔總速度分數的 35%。
累積佈局偏移 (CLS)
這是對高於折疊內容的視覺穩定性的度量。 雖然它只佔整體速度分數的 5%，但在整體情況下仍然值得考慮。 高 CLS 通常可以指示頁面加載期間視覺佈局的一個或多個更改，例如當加載橫幅時將頁面內容向下移動。
速度得分細分
下圖顯示了總體速度得分的細分以及這些新的 CWV 指標在 GPSI 得分中的作用有多大。
來自 Lighthouse 分數更新的源數據
雖然非 CWV 指標也構成了整體得分，包括首次內容繪製 (FCP)、交互時間 (TTI) 和總阻塞時間 (TBT)，但關註三個 CWV 指標將對其他指標產生直接影響。 例如，如果沒有快速 FCP，快速 LCP 是不可能的，而高 FID 分數直接受 TBT 和 TTI 影響。
最大內容繪製優化技巧
LCP 指標由眾多個體因素組成，並直接受到高 FCP 的影響。 如果 FCP 被標記為差，您可能需要從這裡開始。 網絡連接、服務器響應、首字節時間 TTFB 和渲染阻塞文件等任何因素都會影響 FCP 值。 要更深入地了解這些更通用的頁面速度建議中的一些，除了下面的 LCP 特定提示外，請查看我們關於該主題的頁面速度電子書。
如果 LCP 值遠高於 FCP，那麼我們需要看看如何更好地簡化這個最大元素的顯示。
確定最大元素
您可能想要做的第一件事是確定最大的元素是什麼。 最大的元素基於像素區域，它可以在不同的斷點處發生變化，因此視覺掃描不一定能識別正確的元素。
在 PSI 中，診斷部分應該有一個“最大的內容繪製元素”面板。 或者，您可以通過將鼠標懸停在 Chrome 性能監控工具中的指示器上來查看 LCP，如下所示。 
在上例中的 Hallam 站點上，性能監視器將 LCP 顯示為主要的“Thrive Online”標題。 理想情況下，LCP 應立即遵循 FCP，如本例所示，如果兩者之間存在差距，我們需要嘗試了解原因。
字體優化了嗎？
如果折疊元素上方最大的是排版，那麼我們需要確保字體交付盡可能精簡。 這包括：
- 使用 CSS 字體顯示：swap; 以確保在加載字體文件時立即顯示字體。 Google Fonts 和 Adobe 的 Typekit 都可以設置字體“顯示”參數。
- 嘗試在服務器上本地託管 .woff 和 .woff2 字體文件，而不是向第三方字體發出跨域請求。 Google Fonts 相當快，Typekit 字體較慢，某些第三方字體代工廠的可靠性較低。
- 預加載字體文件會有所幫助。 本地託管的字體通常包含在網站的主樣式表中，但必須先下載並解析此樣式表，然後才能對其中的字體發出額外請求。 預加載告訴瀏覽器更快地開始下載字體，而不用等待 CSS 被解析。
- 對第三方字體代工廠使用 preconnect 和 dns-prefetch。 這些指令將有助於在對字體發出請求之前在第三方域之間建立 DNS、TLS 和 TCP 連接。
- 僅包含折疊顯示上方所需的排版字體文件。 Font Awesome 等圖標庫的字體資產是出了名的繁重，但對這些（以及相應的圖標庫 CSS）的請求通常可以在 <head> 元素之後延遲和加載。
- 不要對主站點樣式表中的字體文件發出跨域請求，因為這依賴於連接性和對第三方域的額外查找。
- 考慮網絡安全字體。 這些不需要對字體文件的任何請求，儘管在美學方面可能非常有限。
圖片優化了嗎？
通常，折疊元素上方最大的圖像將是確保圖像優化的重要圖像。 以下是一般的良好做法，但對於 LCP 元素尤其重要。
- 使用正確的圖像文件類型。 JPG 圖像應該用於照片，SVG 用於矢量圖形和圖標，或者 PNG 用於更複雜的非照片圖像，如果需要透明度。
- 確保以 50-60% 的質量保存或輸出 JPG 圖像。 在這個水平上，應該沒有明顯的質量損失。 此外，請確保圖像已從中剝離元數據。
- tinypng.com 等壓縮插件或服務可以自動批量優化圖像並去除不必要的元數據。
- 圖像的大小應適合它們顯示的區域。不要在移動設備上輸出高質量的桌面圖像。
- 圖像應使用標準 <img> 標籤和響應式圖像的 'srcset' 屬性輸出。
- 折疊下方或屏幕外圖像應使用 loading=”lazy” 屬性。
- 使用下一代 .web 圖像文件格式以獲得更高的壓縮率。 這可以輕鬆節省 30%，在許多情況下甚至更高。
- 考慮預加載最大的首屏圖像，以便在其他可能不太重要的內容之前更快地啟動下載。
減少渲染阻塞文件
<head></head> 元素中加載的任何 JavaScript 或 CSS 文件都被視為阻塞渲染，因為需要在頁面開始渲染之前下載這些文件。 這會對 FCP 和 LCP 指標產生巨大影響。 僅當它們對頁面上首屏折疊顯示至關重要時，才應使用頭部中的渲染阻塞文件。
刪除 <head> 中任何未使用的文件，在頁腳中加載非關鍵文件，或將多個文件合併到更少的文件中，將減少渲染阻塞資產的數量。
不要使用 JavaScript 來顯示 LCP
在 CWV 之前，這沒什麼大不了的。 JavaScript 通常用於動畫或顯示在折疊元素上方，例如淡入淡出的文本或英雄輪播，通常對速度得分幾乎沒有影響。
如果最大元素的顯示依賴於 JavaScript，這通常會導致很長的延遲，因為必須在元素出現之前下載、解析和執行 JavaScript。 JavaScript 文件通常（並且非常正確）在 <head> 元素之後加載，因此它們不會“阻止渲染”，但這意味著它們仍然可以有效地阻止 LCP 的渲染。
看看下面的例子（標誌模糊和標題改變）這是來自 PSI 中一個高分網站。 LCP（主標題文本）與 FCP 相距幾秒鐘，這是由於 JavaScript（由黃色帶錶示）在文本淡入之前下載、解析和執行的要求造成的。
文本本身的褪色也可能是一個問題，導致最大元素的延遲顯示。
像這樣的 JavaScript 技術可以立即將整體速度得分降低 25%，並且不應以任何方式用於阻礙或阻止最大元素的加載。
在窗口加載時執行腳本
JavaScript 很少需要（也不應該被要求）來顯示重要的首屏內容，但我們看到的一個常見問題是，一旦 DOM 準備好就可以觸發函數。 在流行的 jQuery 框架中，這是通過 'ready' 事件完成的。 谷歌標籤管理器還可以在就緒時觸發功能或“標籤”。
考慮在加載主頁面內容後觸發窗口加載事件上的關鍵內容顯示不需要的所有 JavaScript，以防止對折疊內容和 LCP 元素的渲染產生任何潛在干擾。
切換 LCP
無論圖像如何優化和簡化，與排版元素相比，下載和顯示幾乎總是需要更長的時間。 儘管完全有可能為圖像獲得快速的 LCP 分數，但有時調整以減少最大的圖像元素使其小於最大的文本元素將意味著文本可以用於 LCP。
如果設計允許，這會對分數產生很大的影響，如下面的示例所示，其中 LCP 已切換到文本元素。 
首次輸入延遲優化技巧
正如我們之前提到的，FID 衡量頁面對用戶輸入的響應程度。 它結合了 Time To Interactive TTI 和 Total Blocking Time TBT，可佔總速度分數的 35%。
這些指標主要受加載頁面時解析和執行的腳本的影響； 阻塞 CPU 的主線程並可能影響設備響應能力，尤其是對於低端智能手機設備。
請務必注意，PSI 中顯示的“實驗室數據”不直接測量 FID。 這是由於難以模擬的用戶點擊或點擊測量的交互性。 相反，它是由“現場數據”收集的； 基於 Chrome 用戶體驗報告 CrUX 在 28 天內從實際用戶收集的測量結果。
因此，直接針對 FID 進行優化有點困難，因為我們無法更改某些內容並等待 28 天以收集更多數據。 因此，我們應該為此使用實驗室數據中的 TTI 和 TBT 指標，因為這些指標的低時間將與低 FID 相關。
那麼我們如何針對這些指標進行優化呢？
審核您的 JavaScript
JavaScript 可以有各種形狀和大小，單個視頻嵌入、聊天小部件、ReCaptcha 腳本或 HubSpot 集成成為高 FID、TTI 和 TBT 指標背後的唯一原因並不少見。
Page Speed Insights 中的診斷面板是一個很好的起點。 “最小化主線程工作”部分將告訴您 JavaScript 佔用了多少執行時間，“減少 JavaScript 執行時間”部分將指示哪些文件具有較高的解析和執行時間以及“減少第三方的影響”代碼”將突出顯示和分組高影響的第三方腳本。
下面的屏幕截圖顯示了一個站點，該站點具有多個繁重的腳本，交互時間指標為 15 秒。 許多腳本來自第三方，包括 HubSpot 和 Vimeo。
為了更深入地分析和可視化這些腳本如何影響頁面加載，Chrome 的性能監視器工具可以是深入了解觸發哪些腳本和函數、這些腳本的相對影響以及頁面加載這些腳本的位置的好方法正在執行冗長的腳本。
下面的示例來自同一站點，顯示由黃色、粉紅色和橙色條表示的 JavaScript，較長的條顯示執行時間較長的任務。 當我們點擊這些較長的任務時，我們可以看到突出顯示的腳本與上面 PSI 突出顯示的大腳本相關。
一旦我們更好地了解了哪些腳本正在影響性能，我們可以使用多種技術來最大限度地減少它們的影響，如下所述。
異步加載腳本
JavaScript 默認會按順序執行。 如果有任何腳本不依賴於其他腳本的加載，則這些腳本應該使用 'async' 屬性加載，這樣它們就不會阻止其他腳本的解析和執行。
有條件地加載 JavaScript
我們在許多網站上看到的一個常見問題是，大量腳本在不需要時在全局或頁面上加載。 例如，如果您需要使用 ReCaptcha 來幫助阻止表單提交中的垃圾郵件，請確保僅在具有表單的頁面上加載腳本。
簡化 JavaScript 包
JavaScript 庫（例如 jQuery UI 或 Bootstrap）通常用於提供額外的 JavaScript 特性和功能。 如果使用捆綁包，請確保只在捆綁包中包含相關功能，以避免下載和解析不必要的 JavaScript。
需要時延遲加載腳本
即使 JavaScript 只加載到需要它的頁面上，腳本本身也不一定需要在頁面加載或窗口加載事件期間解析和執行。 僅在實際需要時才加載 JavaScript 會對 TTI、TBT 和 FID 指標產生巨大影響。 這裡有些例子：
- YouTube 和 Vimeo 等視頻嵌入通常具有很高的影響力。 請考慮僅在單擊視頻縮略圖時加載這些腳本。
- 第三方表單集成（例如 HubSpot）可能是密集型的。 如果表單出現在模式中或頁面底部，請考慮在滾動或模式激活而不是頁面加載時加載或註入所需的腳本。
- 實時聊天小部件可以將整體速度得分影響高達 35%。 考慮將實時聊天小部件移動到支持全局“實時聊天”CTA 的專用聯繫頁面，或僅在單擊“與我們聊天”按鈕時才注入實時聊天腳本。
- 在基於 iFrame 的嵌入式內容上添加 'loading="lazy" 屬性會有所幫助，但這是一項新的瀏覽器功能，需要根據所使用的 iFrame 嵌入進行測試。
評估商業智能工具
使用 Hotjar 等工具或 VWO 等 A/B 測試軟件分析用戶行為對於商業智能非常重要，在許多情況下，它們的好處將超過對網站速度的影響。
話雖如此，仍然值得根據分析數據的頻率來評估 24/7 全天候運行這些工具的重要性。 例如，如果沒有活動測試正在運行，則應關閉 A/B 測試，並且在收集和處理足夠的數據後可能會停用 Hotjar 等行為分析工具。
累積佈局移位優化的技巧
累積佈局偏移 (CLS) 可能僅佔整體速度得分的 5%，但仍然是整體圖片的重要組成部分，尤其是頁面加載時大量的切換元素可能會給用戶帶來不和諧的體驗。
確定 CLS 元素
有時可能會很明顯是什麼元素或元素導致內容髮生變化，但始終值得通過 PSI 中的 Layout Shift 面板驗證這一點，如下所示。
CLS 指標應低於 0.1，但在上面的示例中，超過了 400%，分數將下降 5%。 如果這是一個全球性問題，那麼每頁 5%。
應該按照影響的順序確定和處理變化的元素，並且可能包括折疊上方和下方的元素。 我們在下面重點介紹了佈局轉換的一些最常見原因和解決方法。
注意動畫
使用某些動畫技術來改變向用戶呈現內容的方式是很常見的，例如，當用戶向下滾動頁面時，圖像、文本或內容面板的淡入淡出或滑動。 雖然這些可能在美學上令人愉悅（取決於您問誰），但這些技術在頁面加載期間不會移動任何內容是很重要的。
如果您必須對用戶隱藏然後淡入淡出內容，請確保容器大小或總頁面高度不會隨著內容加載而改變。可以使用 CSS 可見性規則隱藏內容（如有必要）而不是 display: none; 這將保留它所需的基本空間量。
指定圖像尺寸
如果 <img> 標籤沒有設置 width 和 height 屬性，或者沒有使用 CSS 來設置圖像的尺寸或比例，瀏覽器需要先下載圖像，然後才能確定它需要的像素區域顯示在。這會導致在圖像加載時呈現在圖像下方的任何內容髮生偏移。
在下載圖像之前在 CSS 中指定圖像的寬度和高度，或設置圖像（或父容器）的尺寸或比例將確保瀏覽器知道圖像需要顯示的區域並避免潛在的佈局轉移。
橫幅
廣告、cookie 法條或用於在橫幅中顯示重要信息的任何其他信息可能是高 CLS 的最常見原因之一。
橫幅內容從外部數據源加載或通過 JavaScript 從同一站點加載是很常見的，這意味著在加載內容之前可能無法計算橫幅容器的大小。 發生這種情況時，一旦橫幅內容加載並顯示給用戶，橫幅下方的內容將向下移動。
對此有許多決議：
- 在 CSS 中為橫幅或橫幅容器設置最小高度，以便瀏覽器可以有效地呈現佔位符。 儘管如果內容量是動態的且未知的，這可能會出現問題。
- 絕對或固定橫幅在屏幕頂部或底部的位置。 對於可以關閉或關閉的橫幅，這是一個很好的考慮，因為固定元素不會影響任何其他元素的定位。
- 如果可能，查看橫幅內容的服務器端呈現，這意味著內容和橫幅尺寸可以在到達用戶之前預先加載。
概括
希望您會發現上面突出顯示的一些技術在診斷和排除 Google 新 Core Web Vitals 的性能問題方面很有用。 在過去的幾個月裡，我們在 Hallam 的速度審核和開發團隊的直接改進方面幫助了許多客戶提高了他們網站的性能。
如果您發現這篇文章有幫助，您可能還想查看我們的網站性能電子書，該書深入探討了一些關於頁面速度的更通用的建議，任何構建或管理網站的人都可以從中受益。