衡量並最佳化 Google Core Web Vitals：SEO 技術指南

收集有關網站效能的數據是提供出色使用者體驗的第一步。 多年來，Google 提供了各種工具來評估和報告網路效能。

其中包括 Core Web Vitals，這是 Google 認為對所有網路體驗至關重要的一組效能訊號。

本文介紹了目前的一組核心 Web 生命週期以及提高 Web 效能的關鍵技巧和工具，從而為使用者提供良好的頁面體驗。

看看網路效能的演變

直接提高網站效能的日子已經一去不復返了。

過去，臃腫的資源和緩慢的連結常常會導致網站癱瘓。 但是，您可以透過壓縮一些圖像、啟用文字壓縮或縮小樣式表和 JavaScript 模組來超越競爭對手。

如今，連線速度更快了。 大多數資源預設是壓縮的，許多插件處理映像壓縮、快取部署等。

谷歌對更快網路的追求始終如一。 PageSpeed Insights (PSI) 仍然存在於 web.dev 上，是評估單一頁面載入的最佳工具。

儘管許多人認為 PSI 評級具有不必要的懲罰性，但它仍然是我們能了解到的最接近 Google 如何透過頁面速度訊號對網站進行權衡和排名的方式。

要通過 Google 頁面速度測試的最新版本，您需要滿足核心網路生命評估。

了解核心網路生命線

核心網路生命是整合到 2021 年推出的更廣泛的頁面體驗搜尋訊號中的一組指標。每個指標「代表用戶體驗的一個獨特方面，可以在現場進行測量，並反映關鍵用戶的真實體驗 -以結果為中心”，Google表示。

目前一組的核心 Web Vitals 指標包括：

• 第一次內容豐富的繪畫
• 首次輸入延遲（由與下一次繪製的交互取代）
• 與下一個繪畫的交互
• 到第一個字節的時間
• 最大的內容塗料
• 累積佈局偏移

Web.dev 解釋了每個指標的工作原理如下。

首次內容繪製 (FCP)

「首次內容繪製 (FCP) 指標衡量從頁面開始載入到頁面內容的任何部分呈現在螢幕上的時間。 對於此指標，“內容”是指文字、圖像（包括背景圖像）、 <svg>元素或非白色<canvas>元素。”

這對於技術 SEO 意味著什麼

FCP 相當容易理解。 當網頁載入時，某些元素會先於其他元素到達（或「繪製」）。 在這種情況下，「繪畫」意味著螢幕上的渲染。

一旦頁面的任何部分被渲染（假設主導航列在其他元素之前載入），FCP 將在此時被記錄。

將其視為頁面開始為使用者可見載入的速度。 頁面加載尚未完成，但已經開始。

首次輸入延遲 (FID)

「FID 測量從使用者第一次與頁面互動（即，當他們點擊連結、點擊按鈕或使用自訂的 JavaScript 驅動的控制項）到瀏覽器實際上能夠啟動的時間處理事件處理程序以回應該互動。 」

這對於技術 SEO 意味著什麼

FID 是一項使用者互動回應指標，將於 2024 年 3 月被 Interaction to Next Paint (INP) 取代。

如果使用者與頁面上的元素（即連結、對表格進行排序或應用分面導航）進行交互，網站需要多長時間才能開始處理該請求？

與下一個油漆的互動 (INP)

「INP 是一種指標，透過觀察使用者造訪頁面的整個生命週期中發生的所有點擊、敲擊和鍵盤互動的延遲來評估頁面對使用者互動的整體回應能力。 最終的 INP 值是觀察到的最長相互作用，忽略異常值。”

這對於技術 SEO 意味著什麼

如前所述，INP 將於 2024 年 3 月取代 FID 成為核心網路生命線。

INP 考慮了更深層的資訊（顯然延伸到鍵盤）並且可能更詳細和複雜。

第一個字節的時間 (TTFB)

“TTFB 是一種衡量資源請求與響應第一個位元組開始到達之間時間的指標。”

這對於技術 SEO 意味著什麼

一旦要求「資源」（即嵌入圖像、JavaScript 模組、CSS 樣式表等），網站需要多長時間才能開始提供該資源？

假設您造訪一個網頁，該頁面上有一個嵌入的圖像。 它開始加載但尚未完成加載。 該圖像的第一個位元組從伺服器傳送到客戶端（Web 瀏覽器）需要多長時間？

最大內容塗料 (LCP)

“最大內容繪製 (LCP) 指標會報告視窗中可見的最大圖像或文字區塊的渲染時間，相對於頁面首次開始載入的時間。”

這對於技術 SEO 意味著什麼

LCP 是最重要但最難滿足的指標之一。

一旦載入了最大的視覺媒體區塊（即文字或圖像），就會記錄 LCP。

您可以將其理解為，加載頁面的大部分主要內容需要多長時間？

也許頁面下方仍然有一些加載的內容，而大多數用戶不會注意到這些內容。

但是，當記錄 LCP 時，頁面的大部分明顯內容已載入。 如果發生這種情況的時間過長，您將無法通過 LCP 檢查。

累積佈局偏移 (CLS)

「CLS 是衡量頁面整個生命週期中發生的每次意外佈局變化的最大佈局變化分數爆發的指標。

每當可見元素將其位置從渲染幀更改為下一幀時，就會發生佈局轉換。 （有關如何計算各個佈局轉變分數的詳細信息，請參閱下文。）

突發局轉換（稱為會話視窗）是指快速連續發生一個或多個單獨的佈局轉換，每次轉換之間的間隔不到 1 秒，總視窗持續時間最多為 5 秒。

最大的突發是該視窗內所有佈局變化的累積得分最大的會話視窗。”

這對於技術 SEO 意味著什麼

回到過去，當頁面速度優化更簡單時，許多網站所有者意識到，只需推遲所有渲染阻塞資源（通常是 CSS 表和 JavaScript 模組），他們就可以實現令人難以置信的高頁面速度評級。

這對於加快頁面載入速度很有幫助，但也讓網路的導航體驗變得更加故障和煩人。

如果您的 CSS（控制頁面的所有樣式）被延遲，則頁面的內容可以在套用 CSS 規則之前載入。

這意味著頁面的內容將加載無樣式的內容，然後隨著 CSS 加載而稍微跳躍。

如果您加載頁面並單擊鏈接，但隨後鏈接跳轉並且您單擊了錯誤的鏈接，這確實很煩人。

如果你像我一樣有點強迫症，這樣的經歷絕對令人惱火（儘管它們只花費幾秒鐘的時間）。

由於網站所有者試圖透過推遲所有資源來「遊戲」頁面速度評級，因此 Google 需要一個反制指標，以抵消所有頁面速度的提升與用戶體驗的不足。

輸入累積佈局偏移 (CLS)。 這是一個棘手的客戶，如果您嘗試粗略地應用頁面速度提升而不考慮您的用戶，那麼他就會毀掉您的一天。

CLS 基本上會分析您的頁面載入是否有故障變更和延遲的 CSS 規則。

如果太多，儘管您已滿足所有與速度相關的指標，但您仍將無法通過 Core Web Vitals 評估。

評估您的核心網路生命以獲得更好的使用者體驗和搜尋引擎優化結果

分析單一網頁效能的最佳方法之一是將其載入到 PageSpeed Insights 中。 此視圖分為以下組合：

• URL 級資料。
• 原始（域級）資料。
• 實驗室數據。
• 現場數據。

為了理解這一點，我們需要看一個例子：

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

在這裡，我們可以看到 TechCrunch 主頁的頁面速度評級和指標。

在上面，您可以看到核心 Web Vitals 評估失敗。

在行動優先的網路中，選擇「移動結果」標籤非常重要，該標籤應預設呈現（這些是真正重要的結果）。

選擇「來源」開關，以便您看到整個網站網域的平均一般數據，而不僅僅是主頁（或您放入掃描的任何頁面）。

在頁面的下方，您將看到舊的、熟悉的數位頁面速度評級：

那麼，新的 Core Web Vitals 評估和舊的頁面速度評級有什麼區別呢？

本質上，新的 Core Web Vitals 評估（通過/失敗）是基於現場（真實用戶）數據。

舊的數位評級是基於模擬的行動爬行和實驗室數據，這只是估計值。

本質上，Google在修改搜尋排名方面已經轉向核心網路生命力評估。

需要明確的是，類比實驗室數據可以很好地細分出問題所在，但谷歌並沒有在其排名演算法中使用該數字評級。

相反，Core Web Vitals 評估並沒有提供太多詳細資訊。 然而，這項評估已被納入Google的排名演算法中。

因此，您的主要目標是使用更豐富的實驗室診斷，以便最終透過 Core Web Vitals 評估（透過現場數據得出）。

請記住，當您對網站進行更改時，雖然數位評級可能會立即觀察到變化，但您必須等待 Google 提取更多現場數據，然後才能最終通過 Core Web Vitals 評估。

您會注意到，核心 Web Vitals 評估和舊頁面速度評級都使用一些相同的指標。

例如，它們都引用第一內容繪製（FCP）、最大內容繪製（LCP）和累積佈局移位（CLS）。

在某種程度上，每個評級系統檢查的指標類型都非常相似。 這是所檢查資料的詳細程度和來源不同。

您必須致力於透過基於現場的 Core Web Vitals 評估。 然而，由於數據不太豐富，您可能希望利用傳統的實驗室數據和診斷來取得進展。

希望您能夠透過解決實驗室機會和診斷問題來透過 Core Web Vitals 評估。 但請記住，這兩個測試沒有本質上的聯繫。

透過 PageSpeed Insights 評估您的 CWV

現在您已經了解了主要的 Core Web Vitals 指標以及如何在技術上滿足這些指標，現在是時候執行一個範例了。

讓我們回到對 TechCrunch 的檢查：

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

此處，FID 得到滿足，而 INP 僅以微弱優勢失敗。

CLS存在一些問題，但主要問題是LCP和FCP。

讓我們看看 PageSpeed Insights 在機會和診斷方面有什麼說法。

我們現在必須從現場數據轉向實驗室數據，並嘗試隔離可能影響核心網路生命的任何模式：

在上面，您可以在右上角看到一個綠色框內的小子導航。

您可以使用它來縮小對某些 Core Web Vitals 指標的不同機會和診斷範圍。

然而，在這種情況下，數據講述了一個非常清晰的故事，而沒有縮小範圍。

首先，我們被告知要減少未使用的 JavaScript。 這意味著有時 JavaScript 會被載入但未被執行。

還有減少未使用 CSS 的註解。 換句話說，某些 CSS 樣式正在加載，但尚未套用（類似問題）。

我們也被告知要消除渲染阻塞資源，這些資源幾乎總是與 JavaScript 模組和 CSS 表相關。

必須延遲渲染阻塞資源以阻止它們阻塞頁面載入。 然而，正如我們已經探討過的，這可能會擾亂 CLS 評級。

因此，明智的做法是開始設計關鍵的 CSS 和關鍵的 JavaScript 渲染路徑。 這樣做將內聯首屏所需的 JavaScript 和 CSS，同時推遲其餘部分。

這種方法使網站所有者能夠滿足頁面載入需求，同時與 CLS 指標保持平衡。 這不是一件容易的事，通常需要高級 Web 開發人員。

由於我們也發現了未使用的 CSS 和 JavaScript，因此我們也可以發佈一般 JavaScript 程式碼審核，看看是否可以更聰明的部署 JavaScript。

讓我們回到機會與診斷：

現在，我們要專注於診斷。 Google 故意透過較差的 4G 連線來限制這些檢查，因此主執行緒工作等項目看起來很長（17 秒）。

這是有意為之的，目的是為了滿足全球範圍內常見的低頻寬和/或慢速設備的用戶的需求。

我想提請您注意“最小化主線程工作”。 這個單一條目通常是洞察力的金礦。

預設情況下，大部分網頁的渲染和腳本執行 (JavaScript) 任務都是透過客戶端 Web 瀏覽器的主處理執行緒（一個處理執行緒）推送的。 您可以了解這如何導致嚴重的頁面載入瓶頸。

即使所有 JavaScript 都被完美壓縮並快速傳送到使用者的瀏覽器，預設情況下它也必須在單執行緒處理佇列中等待，這意味著一次只能執行一個腳本。

因此，將 JavaScript 負載快速發送給使用者就相當於向一堵一公分間隙的磚牆發射消防水龍。

交付工作做得很好，但並不是一切都會成功！

Google 越來越多地將推動客戶端速度回應能力作為我們的責任。 喜歡它或討厭它，就是這樣（所以你最好熟悉一下）。

你可能會沮喪地說：「為什麼會這樣！？ Web 瀏覽器多年來一直可以存取多個處理線程，甚至行動瀏覽器也迎頭趕上。 事情沒必要弄得這麼尷尬吧？”

其實，是。 有些腳本在執行之前依賴其他腳本的輸出。

很可能，如果所有瀏覽器突然開始並行、不按順序處理所有 JavaScript，那麼大多數網路可能會崩潰並燒毀。

因此，順序腳本執行是現代 Web 瀏覽器的預設行為是有充分理由的。 我一直強調「默認」這個詞。 這是為什麼？

這是因為還有其他選擇。 一是透過代表使用者處理腳本來防止客戶端瀏覽器處理任何腳本。 這稱為伺服器端渲染 (SSR)。

它是解開客戶端 JavaScript 執行結的強大工具，但也非常昂貴。

您的伺服器處理所有腳本請求（來自所有使用者）的速度必須比普通使用者的瀏覽器處理單一腳本的速度快。 讓這個想法沉入一會兒。

不喜歡這個選項？ 好的，讓我們探討一下 JavaScript 並行化。 基本想法是利用網路工作人員來定義哪些腳本將按順序加載，哪些腳本可以並行加載。

雖然您可以強制 JavaScript 並行加載，但預設情況下這樣做是非常不可取的。 在大多數情況下，整合此類技術將在很大程度上減輕對 SSR 的需求。

然而，實現起來會非常繁瑣，並且需要（你猜對了！）高級 Web 開發人員的時間。

您僱用的負責完整 JavaScript 程式碼審核的同一個人也可能能夠幫助您完成此任務。 如果您將 JavaScript 並行化與關鍵 JavaScript 渲染路徑結合起來，那麼您就真的飛了。

在這個例子中，真正有趣的是：

您可以立即看到，雖然主執行緒佔用了 17 秒，但 JavaScript 執行卻佔用了 12 秒。

這是否意味著執行緒工作的 17 秒中有 12 秒是 JavaScript 執行？ 這是很有可能的。

我們知道所有 JavaScript 預設都是透過主執行緒推送的。

這也是活動 CMS WordPress 的預設設定方式。

由於網站運行的是 WordPress，所有這 12 秒的 JavaScript 執行時間可能都來自 17 秒的主執行緒工作。

這是一個很好的見解，因為它告訴我們主處理執行緒的大部分時間都花在了執行 JavaScript 上。 看看引用腳本的數量，這並不難相信。

向 Chrome 開發工具發起十字軍東徵

是時候學習科技並移除輔助輪了。

開啟 Chrome 的新實例。 您應該打開訪客個人資料，以確保沒有混亂或啟用的插件來誇大我們的發現。

請記住：從乾淨的訪客 Chrome 設定檔中執行這些操作。

載入您要分析的網站。 在我們的例子中，這就是 TechCrunch。

根據需要接受 cookie。 頁面載入後，開啟 Chrome DevTools（右鍵點擊頁面並選擇Inspect ）。

導航至效能 > 螢幕截圖。

點擊重新載入按鈕來記錄頁面載入。 然後將產生一份報告：

這是我們都需要深呼吸並盡量不要驚慌的地方。

在上面的綠色框內，您可以看到一個薄窗格，其中說明了隨時間變化的請求。

在此方塊中，您可以拖曳滑鼠選擇一個時間片，頁面的其餘部分和分析將自動適應。

我手動選擇的區域是被半透明藍色框覆蓋的區域。

這就是主頁加載發生的地方，也是我有興趣檢查的地方。

在本例中，我粗略地選擇了 32 毫秒到 2.97 秒之間的時間和事件範圍。 讓我們把目光聚焦在主線程的內部：

你知道之前我有說過大多數渲染任務和 JavaScript 執行都是被迫通過主執行緒的瓶頸嗎？

好吧，我們現在正在隨著時間的推移查看該主線程的內部。 是的，在黃色中，您可以看到很多腳本任務。

在最上面幾行，隨著時間的推移，有越來越多的深黃色區塊確認所有正在執行的腳本以及它們需要多長時間來處理。 您可以點擊各個條塊來取得每個項目的讀數。

儘管這是一個強大的視覺效果，但您會在「摘要」部分找到更強大的視覺效果：

這匯總了所有細粒度數據，並透過易於理解的圓環圖視覺媒介分解為簡單的主題部分（例如，腳本、載入、渲染）。

如您所見，腳本（腳本執行）佔用了大部分頁面載入。 因此，我們先前根據 Google 的現場和實驗室數據混合得出的假設（指出主線程中的 JavaScript 執行瓶頸）似乎是準確的。

到 2023 年，這是最廣泛遇到的問題之一，幾乎沒有簡單、現成的解決方案。

建立關鍵的 JavaScript 渲染路徑很複雜。 執行 JavaScript 程式碼審計需要專業知識，並且採用 JavaScript 並行化或 SSR 並不是那麼簡單。

現在讓我們看看呼叫樹：

呼叫樹通常比自下而上更有用。

資料相似，但呼​​叫樹將按主題將任務分組到方便的儲存桶中，例如評估腳本（腳本執行）。

然後，您可以單擊一個群組，將其展開並查看腳本以及加載所需的時間。 11% 的時間用於載入pubads_impl.jsm ，而 6% 的時間用於載入opus.js 。

我不知道這些模組是什麼（您可能也不知道），但這通常是優化之旅開始的地方。

我們現在可以退後一步：

• 谷歌搜尋這些腳本，看看它們是否是第三方庫的一部分、它們的作用以及影響是什麼。
• 請諮詢開發人員，以了解如何更聰明地部署這些內容。
• 將問題縮小到個人資源並尋找替代方案。
• 解決效能缺陷（或者，爭取更多資源/頻寬、強大的託管環境——如果確實需要的話）。

用於衡量和最佳化 Core Web Vitals 的其他工具

如果你能堅持到現在，恭喜你。 在深度 Core Web Vitals 和頁面速度分析方面，我們僅使用：

• PageSpeed 見解
• Chrome 開發者工具（ 「效能」標籤）

是的，你真的可以那麼苗條。 但是，還有其他工具可能對您有很大幫助：

• GTMetrix ：對其瀑布圖特別有用（需要免費的瀑布帳戶），您可以在此處了解如何閱讀。 不要忘記 GTMetrix 預設將不受限制地運行，從而給出非常有利的結果。 請務必將其設定為 LTE 連線。
• Google Search Console ：如果您設定了此選項並驗證您的網站，您可以看到一段時間內的大量效能和可用性數據，包括跨多個頁面的 Core Web Vitals 指標（聚合）。
• Screaming Frog SEO Spider ：這可以連接到頁面速度 API，以允許批量獲取 Core Web Vitals 通過或失敗等級（針對多個頁面）。 如果您使用免費的頁面速度 API，請不要以不合理的方式對其進行錘擊

提高頁面速度評級過去就像壓縮和上傳一些圖像一樣簡單。

如今？ 這是一場複雜的核心網路生命運動。

準備充分參與。 任何不足都會導致失敗。