Core Web Vitals 101 和開髮指南

已發表: 2021-04-01

（最後更新於：2021 年 11 月 30 日）

正在發生和改變的是什麼？

2021 年 5 月，谷歌啟動了核心算法更新的推出，該更新為頁面排名信號增加了一個額外因素，因為它與頁面速度和用戶體驗有關。核心更新的推出也一直持續到 2021 年 6 月，這也使其成為歷史上最大的核心變化之一。 Core Web Vitals 將加入舊的排名信號，例如 HTTPS 安全站點、移動友好性和非侵入式插頁式廣告作為整體頁面體驗排名因素中的搜索信號。

核心網絡生命力排名信號

Core Web Vitals 的三個組成部分包括：

Largest Contentful Paint (LCP) ：測量感知加載速度並在頁面主要內容可能加載時標記頁面加載時間軸中的點。 為了提供良好的用戶體驗，網站應努力讓LCP 在頁面開始加載的前 2.5 秒內發生。
First Input Delay (FID) ：衡量響應能力並量化用戶在首次嘗試與頁面交互時的體驗。 為了提供良好的用戶體驗，網站應努力使FID 小於 100 毫秒。
Cumulative Layout Shift (CLS) ：測量視覺穩定性並量化可見頁面內容的意外佈局偏移量。 為了提供良好的用戶體驗，網站應努力使CLS 分數低於 0.1 。

谷歌官方關於本次算法更新的發布聲明： https ://developers.google.com/search/blog/2020/11/timing-for-page-experience

此外，Google 發布了有關 CLS 更改的更多信息，因為他們在推出期間繼續監控性能。結果，許多站點由於最近的更改而獲得了更高的分數，並且避免了很多開發工作來調整其站點佈局。與往常一樣，這些更改可能會發生變化，因此我們建議將監控 CWV 作為每週或每月檢查清單的一部分。

我們對排名更新了解多少？

與大多數谷歌算法更新一樣，就它將如何影響當前的搜索格局而言，還有很多未知數。我們知道這將是網頁排名的一個因素。但是，我們不知道一個因素在算法中的百分比或影響有多大。另一個未知因素是直接競爭對手是否會適應或採取行動更新其網站以遵守新因素。根據競爭對手的行為，與那些同行相比，這反過來會對您網站的排名產生積極或消極的影響。我們所知道的是，谷歌將繼續優先考慮其認為有價值或與用戶相關的內容，而不是速度較快但內容薄弱的網站。

事實上，隨著谷歌提供更多關於更新的信息，他們確認相關內容仍然是搜索排名中最重要的元素之一。

“我們的系統將繼續優先考慮整體信息最好的頁面，即使頁面體驗的某些方面不盡如人意。 良好的頁面體驗並不能取代優秀的相關內容。”

如何為谷歌頁面體驗排名更新做準備？

由於與此更新相關的未知因素以及 Google 的 6 個月通知窗口，此更改似乎表明這將成為排名因素。因此，強烈建議 SEO 和開發團隊審查您網站當前的核心網絡生命力性能，並迅速採取行動審查和更新與排名信號更新相關的問題。確保你是主動的而不是被動的很重要，因為任何排名下降都需要相當長的時間才能恢復。我們都知道 SEO 是一場持久戰！

如何識別站點問題、基於問題的後續步驟和其他提示？

Core Web Vitals 在您網站的 Google Search Console 帳戶的“增強功能”下進行了概述。此外，帳戶的“概覽”部分中有一個總體視圖，看起來類似於下面的示例（可能會出現一些差異，因為您的帳戶取決於特定於您站點的潛在問題）。還有一個部分概述了桌面和移動設備。在這個例子中，我們正在研究與移動相關的問題。

谷歌搜索控制台核心網絡活力報告

由於截至 2020 年 9 月所有網站都以移動設備為先編入索引，我們建議首先將開發時間花在移動設備問題上。話雖如此，如果您的網站是響應式的，那麼您在移動設備上所做的更新很可能也會對桌面產生積極影響。此外，根據站點的大小，可能會出現一系列“差”和“需要改進”的問題。我們強烈建議關注“糟糕”的 URL，因為“需要改進”的項目可能不值得付出努力與影響或 80/20 規則，我們將在稍後深入探討！

在查看 Google Search Console 中列出的顯示不佳性能的 URL 時，請務必記住Google 的 John Mueller透露的內容，即 Google 在某些情況下可能如何將核心網絡生命值分數計算為多個頁面的平均值：

這是問題：

“當這成為排名信號時……它會是頁面級別還是域級別？”

穆勒回答：

“......現場數據發生的情況是我們沒有每個頁面的數據點。

因此，在大多數情況下，我們需要對各個頁面進行分組。

根據我們擁有的數據量，這可以是整個網站（域的一種）的分組。

......我認為在 Chrome 用戶體驗報告中，他們使用的來源是子域和那裡的協議。

所以這將是一種總體分組。

如果我們有更多關於網站各個部分的數據，那麼我們將嘗試使用它。

我相信這也是您在搜索控制台中看到的東西，我們將在其中顯示一個 URL 並說……有很多其他頁面與之相關聯。 這就是我們將在那裡使用的分組。”

您可能會問自己，為什麼我們要在圍繞 Core Web Vitals 的對話開始時提出這個問題？ Mueller 解釋說，Google Search Console 報告概述了 URL 問題，試圖將具有相同問題的頁面分類並報告到一個分組中。不幸的是，在實踐中，根據我們的經驗，這些 URL 分組對某些網站的幫助不大。

有時，我們會審查在 Google Search Console 報告中顯示為“性能不佳”的 URL，結果發現在使用 Lighthouse 和 Page Speed Insights 進行測試時，同樣的頁面似乎健康狀況良好。

總之，在查看 Google Search Console 報告中列出的 URL 問題時，我們建議“持保留態度”。我們最好的猜測是，谷歌打算根據 28 天的實際真實世界瀏覽數據（谷歌語言中的“現場數據”）歷史記錄對頁面的“網絡生命力”得分進行排名。但是，如果頁面流量不高，那麼真實世界的數據很可能是從整個域（或 Google 中的“來源”）聚合而來的。雖然 Search Console 有助於確定您的網絡生命力需要一些 TLC 的事實，但不要依賴它來進行審核。此外，在執行和審核或驗證修復時，要小心查看實驗室數據（實時測試頁面的個別結果），而不是現場數據（可以用於多個頁面，並且總是超過 28 天的回溯窗口）。

一旦您知道自己有問題，如果您無法確定源頁面，請從每個核心模板的實驗室測試示例頁面開始。例如，主頁、產品頁面、類別頁面、博客文章等。通常，結構問題可以在特定頁麵類型的每個實例中找到，並由 Web 開發人員通過更新基礎模板一次性修復代碼。如果這不能解決問題，請考慮從訪問量最大的頁面開始對單個頁面的子集進行類似的分析。我們發現在此過程中有用的工具是通過 Screaming Frog 審核 Core Web Vitals 。

Cumulative Layout Shift (CLS) 改進指南

Cumulative Layout Shift (CLS)衡量在頁面的整個生命週期內發生的每個意外佈局偏移的所有單獨佈局偏移分數的總和。 每當可見元素將其位置從一個渲染幀更改為下一個渲染幀時，就會發生佈局偏移。

Google 就如何通過堅持一些指導原則來改進大多數網站的 CLS 提供了以下指導：

始終在您的圖像和視頻元素上包含尺寸屬性，或者使用諸如CSS 長寬比框之類的東西保留所需的空間。這種方法確保瀏覽器可以在加載圖像時在文檔中分配正確的空間量。請注意，您還可以使用unsized-media 功能策略在支持功能策略的瀏覽器中強制執行此行為。
切勿在現有內容之上插入內容，除非是為了響應用戶交互。這確保了預期發生的任何佈局偏移。
更喜歡轉換動畫而不是觸發佈局更改的屬性動畫。以提供上下文和從狀態到狀態的連續性的方式動畫轉換。

Google 建議使用以下操作過程來分析、測試和部署整個站點的更新：

確定需要改進的頁面（如上文所述）後，使用PageSpeed Insights診斷頁面上的實驗室和現場問題。
準備好在實驗室本地優化您的站點了嗎？使用Lighthouse和Chrome DevTools來衡量 Core Web Vitals 並獲得有關確切修復內容的可操作指南。 Web Vitals Chrome 擴展程序可以讓您在桌面上實時查看指標。
尋找指導？ web.dev/measure可以使用 PSI 數據測量您的頁面並向您展示一組優先指南和代碼實驗室以進行優化。
最後，在拉取請求中使用Lighthouse CI以確保在將更改部署到生產環境之前，Core Web Vitals 沒有任何回歸。

要深入了解如何改進 CLS，請參閱優化 CLS 。

Largest Contentful Paint (LCP) 改進指南

Largest Contentful Paint (LCP)指標報告視口內可見的最大圖像或文本塊的渲染時間。

正如目前在Largest Contentful Paint API中指定的那樣，Largest Contentful Paint考慮的元素類型是：

<img>元素
< svg>元素內的<image>元素
<video>元素（使用海報圖像）
具有通過url()函數加載的背景圖像的元素（與CSS 漸變相反）
包含文本節點或其他內聯級文本元素子元素的塊級元素

谷歌推薦以下關於如何改進 LCP 的指南，這主要受四個因素的影響：

服務器響應時間慢
渲染阻塞 JavaScript 和 CSS
資源加載時間
客戶端渲染

如需深入了解如何改進 LCP，請參閱優化 LCP 。有關也可以改進 LCP 的個人性能技術的其他指導，請參閱：

使用 PRPL 模式應用即時加載
優化關鍵渲染路徑
優化你的 CSS
優化您的圖片
優化網絡字體

優化您的 JavaScript （針對客戶端呈現的網站）

迄今為止開發的核心 Web 重要發現

我們的開發團隊已經看到，大部分 Core Web Vitals 排名更新都需要在開發方面進行大量測試，以確保所做的更新符合 Google 制定的標準。

在許多情況下，對於較小的站點，其中許多項目將超出 Web 開發人員的控制範圍。例如，服務器速度主要由託管服務提供商控制，而對於共享託管（如 WP Engine 或 Shopify），開發人員將無法控制。同樣，開箱即用的網站主題通常會“內置”阻止渲染的 Javascript 和 CSS。在這些情況下，解決許多報告的問題可能不切實際。由於這些原因，需要進行批判性分析以確定 (1) 哪些問題影響最大，以及 (2) 哪些問題是由開發團隊可以並且應該更改的代碼引起的交集。

在開始審查幾個客戶的 Core Web Vitals 問題之後，我們發現 Google 提供的許多相關工具仍然不成熟，因為它能夠識別問題（例如內容負載轉移），但不是總是有助於查明具體原因。雖然我們希望此工具（特別是在 Chrome 開發工具中）的即將迭代中成熟，但我們發現可能需要替代診斷過程來識別某些問題。

我們還發現，努力改進這些指標在本質上與提高整體頁面速度性能相似。在每種情況下，我們都建議不要追求“完美分數”。相反，80/20 規則適用。如果您解決了唾手可得的問題，您可能會看到指標的顯著改善。在那之後，改進變得更耗時、更昂貴且影響更小。

谷歌建議在所有圖像、視頻和容器元素上包含保留空間的標記或 CSS 等基本指南通常是很好的建議，而且易於實施。其他問題更難追踪，除非它們對您的指標產生過度影響（如某些建議工具所報告），否則最好將這些問題擱置一旁。

站點架構也將在相對容易地處理這些項目方面發揮重要作用。 Shopify 和 WordPress 等流行網站平台，以及 WP Bakery 和 Shogun 等圖形頁面構建器，“在幕後”處理部分 HTML 生成過程。如果不對站點進行根本性更改或平台、主題或插件/應用程序供應商的支持，頁面構建器組件掩蓋的問題（例如，某些圖像的延遲加載）可能不容易解決。

上述概念擴展到使用 javascript 將小部件延遲加載到您的頁面的第三方（例如，來自 Klaviyo 等電子郵件平台的嵌入式註冊表單）。在某些情況下，在有問題的組件的嵌入代碼周圍放置一個適當且明確大小的容器元素是一個可行的解決方案。在其他情況下，供應商自己可能需要進行更改。

我們建議開始任何具有影響力的問題的補救過程，這些問題可以通過更改易於訪問的核心站點模板（例如，產品頁面、產品集合頁面等）來解決。這通常允許一次代碼更改來改進數十或數百個站點頁面的結果。接下來，處理主頁，因為它幾乎總是網站上訪問量最大的頁面。最後，根據問題的嚴重性和頁面的可見性，確定需要修復的其他單個頁面的優先級。

與提高頁面速度的情況一樣，管理 Core Web Vitals 很重要，但它只是 Google 排名算法中眾多變量中的一個，而且 SEO 還必須與其他爭奪時間和預算資金的網站和業務優先事項保持平衡。