如何針對 Google 的核心 Web Vitals 優化您的網站

Google 的使命是通過 Core Web Vitals 提高網路性能。為什麼？因為谷歌的業務主要基於網路——緩慢的網站和網路應用程序將用戶推回原生應用程序。

嘗試免費演示

您在 Google 搜索結果中的位置很大程度上取決於搜索詞的關鍵字、這些關鍵字在您的網頁中的使用情況以及您網頁的受歡迎程度（根據來自其他地方的鏈接的數量（和質量））。從 2021 年 8 月起，Google 還將努力根據性能評估頁面。

本文將向您展示如何針對 Google 的 Core Web Vitals 指標優化您的網站。

為什麼選擇核心 Web Vitals？

內容仍然至關重要。但是，如果您比較兩個具有相似文本和流行度的站點，則提供最佳網路體驗的站點將在 Google 搜索結果中獲得更高的優先順序。

除了提高頁面排名外，高性能網站也有資格加入移動搜索輪播。這以前是為 Accelerated Mobile Pages (AMP) 保留的，它要求您將內容移植到單獨的 Google 託管網站中。AMP 引起了批評，特別是因為頁面並不總是比優化良好的 WordPress 或靜態網站快。但是，這不再是必需的。

無論您選擇什麼，您的網站越快、響應速度越快，它在 Google 搜索結果中的排名就越高。

當您考慮到平均頁面大約為 2 MB，發出超過 60 個 HTTP 請求，並且需要 16 秒才能在移動設備上完全呈現時，您會發現您的網站還有一些改進空間。我們將向您展示實現這些改進的最佳方法。

谷歌的關鍵排名因素

在開始評估性能之前，需要檢查四個關鍵的排名因素：

HTTPS：HTTPS 必不可少。您的站點是否在用戶瀏覽器和網路伺服器之間建立了安全連接？
移動友好性：您的網站必須在移動設備上運行良好。您的網站可以在小屏幕設備上使用嗎？它是否在沒有內容溢出的情況下呈現？文字夠大嗎？可點擊區域是否足以用於觸摸控制？
無插頁式廣告：避免需要過多屏幕空間的侵入式插頁式廣告。您的內容始終可讀嗎？它是否被彈出式插頁式廣告或橫幅部分遮擋？您的廣告或營銷促銷活動是否使網站難以使用？
安全瀏覽：您的網站應該沒有惡意軟體、病毒、網路釣魚、欺詐和其他詐騙。

一旦您滿足這些要求，您的網站將進行性能評估。

它對抗競爭對手的機會越大。💪點擊推文

Google 如何評估 Web 性能？

讓您的網站快速載入、快速呈現並更快響應至關重要。但是用戶感覺很快嗎？

瀏覽器 DevTools 等性能測量應用程序報告技術測量，例如：

阻塞時間：等待下載開始所花費的時間，通常是因為樣式表和腳本等其他資產具有更高的優先順序。
DNS 解析：將主機名解析為 IP 地址以檢索資產的時間。
連接時間：初始化 TCP 連接的時間。
Time to First Byte (TTFB)：請求和響應的第一個位元組之間的總時間。
接收時間：檢索整個資產的時間。
DOM 載入時間：下載和呈現 HTML 文檔對象模型的時間。這通常是分析或修改 DOM 的腳本可以可靠運行的第一個點。
頁面載入時間：下載頁面和所有資產（如圖像、樣式表、腳本等）的時間。
總頁面權重：所有資產的總大小。它通常以壓縮（下載）大小和未壓縮大小報告。
DOM 元素數：頁面上 HTML 元素的總數。元素越多，頁面處理的時間就越長。
First Contentful Paint (FCP)：瀏覽器呈現第一個內容像素之前所用的時間。
首次有意義的繪製 (FMP)：主頁面內容對用戶可見之前所用的時間。
交互時間 (TTI)：頁面完全交互並能夠可靠地響應用戶輸入之前所花費的時間。
First CPU Idle：CPU 渲染頁面和運行所有初始化腳本的時間，等待進一步輸入。
CPU 使用率：呈現頁面和響應用戶輸入時所需的處理活動。
每秒布局數：瀏覽器必須重新計算樣式和頁面布局的速率。

這些可用於確定特定的瓶頸，例如伺服器負載、CMS 緩存、瀏覽器緩存、下載速度和 JavaScript 效率。但是他們無法確定頁面提供的用戶體驗是好是壞。例如：

應用程序可以快速下載並出現，但在第一次交互後變得無響應，因為它正在執行大量未優化的 JavaScript 代碼。
聊天應用程序可以在用戶發布消息時不斷下載數據。儘管頁面感覺響應，但評估工具可能會假定它從未完成載入。

Core Web Vitals 是 Google 試圖解決這些困境的嘗試。

什麼是核心 Web 要素？

Google 的 Core Web Vitals (CWV) 是評估真實用戶體驗的三個性能指標：

最大內容繪製 (LCP)：載入性能
首次輸入延遲 (FID)：交互性能
Cumulative Layout Shift (CLS)：視覺穩定性表現

這項新的 Google 演算法更新已於 2021 年 8 月底開始在全球範圍內推出。 Core Web Vitals 指標主要影響移動搜索結果，但如果實驗成功，桌面等效指標也會隨之而來。

頁面的 LCP、FID 和 CLS 分數基於過去 28 天通過 Chrome 瀏覽器匿名收集的真實用戶指標。這些測量值可能因用戶的設備、連接和其他並發活動而異，因此計算的是第 75 個百分位數，而不是平均值。

換句話說，所有用戶的指標從最好到最差排序，取四分之三點的數字。因此，四分之三的站點訪問者將體驗到該級別或更好的性能。

任何在所有三個 Core Web Vitals 指標上都獲得良好（綠色）分數的頁面將在搜索結果中獲得更高的排名，並被包含在 Google 新聞應用程序的「頭條新聞」輪播中。

在以下部分中，我們將介紹用於計算指標的演算法、可用於確定頁面分數的工具、低分數的典型原因以及解決性能問題可採取的步驟。

最大的內容繪製 (LCP)

Largest Contentful Paint 衡量載入性能。本質上，可用內容在頁面上呈現的速度有多快？

LCP 分析最大圖像或文本塊在瀏覽器視口（首屏）中可見所需的時間。在大多數情況下，最突出的項目是英雄圖片、橫幅、標題或大文本塊。

以下任何元素都有資格進行最大內容繪製分析：

圖像（<img> 元素）
矢量圖形中的圖像（嵌入到 <svg> 中的 <image>）
視頻縮略圖（在 <video> 元素中設置為圖像 URL 的海報屬性）
帶有背景圖像的元素（通常使用 CSS background-image url() 屬性載入）
包含文本的塊級元素

在頁面載入的前 2.5 秒內完成最大內容繪製的頁面被認為是好的（綠色）。超過 4.0 秒的頁面被認為是差的（紅色）：

最大的內容繪製。

最大的內容繪製分析工具

LCP 是最容易理解的 Core Web Vital 指標，但選擇哪個元素進行分析可能並不明顯。

DevTools Lighthouse 面板在基於 Chromium 的瀏覽器中提供，例如 Chrome、Edge、Brave、Opera 和 Vivaldi。從瀏覽器菜單打開 DevTools – 通常在更多工具 > 開發者工具或鍵盤快捷鍵 Ctrl | Cmd + Shift + i 或 F12 – 然後導航到 Lighthouse 選項卡（舊版本可能將其命名為 Audit）。

生成移動性能報告，然後檢查生成的性能部分。最大內容繪製時間顯示有一個可擴展的部分，用於標識所選元素：

DevTools Lighthouse 移動性能報告。

如果您無法訪問基於 Chromium 的瀏覽器，您可以在在線 PageSpeed Insights 和 web.dev Measure 工具中生成相同的信息：

PageSpeed Insights 最大的內容繪製分析。

DevTools 性能面板還顯示 LCP 指示器。首先，單擊圓形記錄圖標，重新載入頁面，然後單擊停止按鈕查看報告。單擊「計時」部分中的 LCP 圖標以標識元素並查看統計摘要。

DevTools 性能面板 LCP 指示器。

Web Vitals 擴展程序可用於 Google Chrome，但可以安裝在大多數基於 Chromium 的瀏覽器上。它為您訪問的每個站點計算 Core Web Vitals 指標，其圖標會根據結果變為綠色、橙色或紅色。您還可以單擊擴展圖標以查看更多 LCP 詳細信息：

Web Vitals 擴展 LCP。

如果您的網站被添加為屬性，Google 的 Search Console 現在會提供一個 Core Web Vitals 部分。該報告說明了 CWV 指標如何隨時間變化。請注意，它不會識別特定的 LCP 指標，並且只有具有相當高流量的站點可用：

Google Search Console 核心 Web 要素

Google Search Console 核心 Web Vitals。

Chrome 用戶體驗報告允許您查詢特定 URL 的真實使用統計數據，包括跨國家、連接和設備的 LCP。這是 Google BigQuery 上的一個公共項目，因此您必須註冊一個 Google Cloud Platform 帳戶並提供帳單明細。同樣，該報告僅在 URL 具有相當高的流量時才有用。

最後，web-vitals JavaScript 庫是一個 1 kB 的小腳本，可以為您的實時站點上的真實用戶計算 LCP 和其他 Core Web Vital 指標。由於它可以從 CDN 下載，因此您可以將以下腳本添加到 HTML <head>：

<!DOCTYPE html>
<html lang=”en”>
<head>
<meta charset=”UTF-8″>
<title>我的頁面</title>
<script type=”module”>
import { getLCP } from ‘https ://unpkg.com/web-vitals?module’;
getLCP(console.log);
</script>
<!– 其餘頁面 –>

getLCP() 是一個非同步函數，它會傳遞一個在計算 LCP 值時觸發的回調（儘管如果頁面在後台選項卡中載入，它可能永遠不會觸發）。回調函數被傳遞一個包含以下內容的對象：

名稱：指標的名稱（在本例中為「LCP」）
值：計算值
id：表示當前頁面的此指標的唯一 ID
delta：當前值與上次報告值之間的差值
條目：值計算中使用的條目數組

上面的腳本將對象輸出到控制台，儘管將數據發送到伺服器或 Google Analytics 進行進一步分析更為實用。

最大內容油漆得分不佳的常見原因

糟糕的 LCP 分數通常是由於頁面載入緩慢導致最大塊無法快速出現：

訂閱時事通訊

想知道我們是如何將流量增加超過 1000% 的嗎？

加入 20,000 多名其他人，他們會收到我們的每周時事通訊，其中包含 WordPress 內幕技巧！

現在訂閱

伺服器響應可能很慢，因為它過載或渲染頁面的工作量太大。這可能不一定是您網站的錯——如果您使用的是共享託管服務，則可能是由於伺服器限制。
如果在主要內容上方的 HTML 中引用了阻止渲染的 CSS 和 JavaScript，則它們可能會延遲頁面載入。
其他資源（如大圖像和視頻）會減少可用帶寬並需要更長的時間來渲染。
在客戶端而不是伺服器上生成的頁面內容也需要更長的時間才能出現。

如何提高最大的內容繪製分數

徹底的審計可以識別載入問題，但通常是減少發送到瀏覽器的數據量的問題。以下提示將有助於獲得更健康的 LCP 分數：

升級您的伺服器和/或託管服務。確保下載速度即使在高使用率時也能保持快速。
激活伺服器壓縮和 HTTP/2+。沒有理由不這樣做！
減少伺服器工作量。刪除未使用的代碼和 CMS 插件，然後啟用有效緩存。
確保瀏覽器可以有效緩存文件。在 HTTP 標頭中設置適當的 Expires、Last-Modified 和/或 ETag 哈希值，以便不再請求文件。
使用內容交付網路 (CDN) 在地理位置更靠近用戶的伺服器上拆分負載和託管資產。
優化您的圖像。將它們縮小到最小尺寸並使用適當的格式來最小化文件大小。確保儘早請求最大內容塊中的任何圖像；預載入可能會有所幫助。
通過添加 loading=”lazy” 屬性延遲載入圖像。添加寬度和高度屬性以確保在圖像完成載入之前在頁面上保留適當的空間。
盡量減少第三方請求，並考慮將資產移動到您的主域以避免無關的 DNS 查找。
最小化請求文件的數量和大小，尤其是在 HTML 頂部。
確保僅載入所需的 Web 字體。切換到網路安全字體以獲得最佳性能。
刪除未使用的 JavaScript 和 CSS 文件。
連接並縮小您的 JavaScript 和 CSS 文件。
避免使用 CSS @import 語句——它們是連續渲染和載入樣式。
避免 Base64 編碼——它會增加文件大小並需要額外的處理。
考慮關鍵的內聯 CSS。在頁面頂部的 <link> 塊中嵌入必要的「首屏」CSS，然後非同步載入更多樣式表。
使用非同步、延遲或 ES 模塊 JavaScript 稍後運行腳本。在 Service Worker 中執行長時間運行的 JavaScript 進程。

首次輸入延遲 (FID)

首次輸入延遲衡量頁面的響應能力。本質上，它對點擊、點擊和滾動等用戶操作的響應速度有多快？

FID 指標計算為用戶交互和瀏覽器處理其請求之間的時間。它不測量運行處理程序函數的時間，處理程序函數通常會處理輸入並更新 DOM。

FID 時間為 100 毫秒或更短的頁面被認為是好的（綠色）。超過 300 毫秒的頁面被認為是差的（紅色）：

第一輸入延遲。

首次輸入延遲分析工具

First Input Delay 無法模擬，因為它只能在頁面提供給與頁面交互的實際用戶時進行測量。因此，結果取決於每個設備的處理器速度和功能。

未在 DevTools Lighthouse 面板或 PageSpeed Insights 中計算 FID。但是，他們可以確定總阻塞時間 (TBT)。這是第一輸入延遲的合理近似值。它測量以下時間的差異：

第一次內容繪製 (FCP)，或頁面內容開始呈現的時間，以及
交互時間 (TTI)，或頁面可以響應用戶輸入的時間。當沒有長時間運行的任務處於活動狀態且尚未完成的 HTTP 請求少於三個時，將假定 TTI。

PageSpeed Insights 總阻塞時間。

Google Chrome 的 Web Vitals 擴展程序還可以在通過滾動或單擊與頁面交互後顯示 FID 指標。單擊擴展程序的圖標以顯示更多信息：

Web Vitals 擴展 FID。

與 LCP 一樣，Chrome 用戶體驗報告允許您查詢針對特定 URL 在不同國家、連接和設備上記錄的真實 FID 統計信息。

web-vitals JavaScript 庫還可以計算實時站點上真實用戶的 FID 指標。您可以將以下腳本添加到 HTML <head> 以將 FID 指標輸出到回調函數：

<!DOCTYPE html>
<html lang=”en”>
<head>
<meta charset=”UTF-8″>
<title>我的頁面</title>
<script type=”module”>
import { getFID } from ‘https ://unpkg.com/web-vitals?module’;
getFID(console.log);
</script>
<!– 其餘頁面 –>

首次輸入延遲分數不佳的常見原因

FID 和 TBT 分數不佳通常是由佔用處理器的客戶端代碼引起的，例如：

厭倦了沒有答案的低於 1 級的 WordPress 託管支持？試試我們世界一流的支持團隊！查看我們的計劃

大量阻止渲染的 CSS 和 JavaScript，它們會在下載和解析代碼時停止頁面載入
在頁面載入時立即運行的大型流程密集型腳本
長時間運行或優化不佳的 JavaScript 任務

默認情況下，瀏覽器運行在單個線程上，一次只能處理一個任務。如果 JavaScript 函數需要一秒鐘來執行，則所有其他渲染進程在該秒鐘內都會被阻止。頁面無法響應用戶輸入、更新 DOM、顯示動畫等。甚至 GIF 動畫也可以在較舊的瀏覽器中被阻止。

如何提高首次輸入延遲分數

客戶端 JavaScript 審計可以識別問題，但通常是刪除冗餘代碼並確保快速執行任務。

以下提示將有助於獲得更健康的 FID 分數：

在伺服器上生成和緩存儘可能多的靜態 HTML 內容。盡量不要依賴客戶端 JavaScript 框架來為每個人呈現相同的 HTML。
確保瀏覽器可以有效緩存文件。在 HTTP 標頭中設置適當的 Expires、Last-Modified 和/或 ETag 哈希值，因此不會再次請求文件。
採用漸進式增強技術，因此在運行 JavaScript 之前，界面可以在 HTML 和 CSS 中使用。
刪除未使用的 JavaScript 和 CSS 文件。
連接並縮小您的 JavaScript 和 CSS 文件。
避免過度使用昂貴的 CSS 屬性，例如 box-shadow 和 filter。
使用非同步、延遲或 ES 模塊 JavaScript 稍後運行腳本。
最大限度地減少第三方 JavaScript 對分析、社交媒體小部件、論壇等的請求。這些可以快速安裝到幾兆位元組的 JavaScript。
按需延遲載入 JavaScript 組件，例如聊天小部件、視頻播放器等。
延遲載入不太重要的腳本，例如分析、廣告和社交媒體工具。
將長時間運行的 JavaScript 任務分解為一系列較小的作業，這些作業在短暫的 requestIdleCallback、setTimeout 或 requestAnimationFrame 延遲後執行。
考慮在使用後台線程的 Web Worker 中執行長時間運行的 JavaScript 進程。

累積布局偏移 (CLS)

CLS 測量頁面的視覺穩定性。本質上，頁面內容是否會意外移動或跳躍，尤其是在初始載入期間？

當元素在沒有警告或用戶交互的情況下移動時，CLS 會計算一個分數。在移動設備上閱讀文章時，您可能遇到過這種情況——文本突然跳出屏幕，您失去了自己的位置。最糟糕的例子可能會導致您點擊錯誤的鏈接。

當大圖像或廣告載入到當前滾動位置上方並且零高度空間立即增加數百像素時，CLS 問題最為突出。

累積布局偏移分數是通過將以下指標相乘來計算的：

影響分數：這是視口中所有不穩定元素的總面積，即那些將「跳躍」的元素。如果覆蓋 60% 視口的元素在頁面載入期間發生位移，則影響分數為 0.6。請注意，導致這種變化的元素（例如圖像或廣告）被認為是穩定的，因為它們在渲染後不一定會移動。
距離分數：這是視口中任何單個不穩定元素移動的最大距離。如果最大位移發生在從 0,100 移動到 0,800 的元素上，則它已移動了 700 個垂直像素。如果設備視口的高度為 1,000 px，則距離分數為 700 px / 1000 px = 0.7。因此，計算出的累積布局偏移分數為 0.6 x 0.7 = 0.42。

Google 已更改 CLS 指標以適應以下情況：

布局轉換被分組為「會話」，持續五秒，但如果沒有進一步的布局轉換髮生，則在一秒後關閉。如果在一秒鐘內發生兩次或更多輪班，則將他們的分數相加。
用戶交互（例如單擊）後 500 毫秒內不會記錄布局轉換。在某些情況下，這會觸發 DOM 更新（例如，打開菜單、顯示錯誤消息、顯示模式對話框等）。
保持打開更長時間並進行大量 DOM 更新的單頁應用程序不會受到不利影響。

CLS 分數為 0.1 或更低的頁面被認為是好的（綠色）。超過 0.25 的頁面被認為是差的（紅色）：

累積布局偏移。

累積布局偏移分析工具

CLS 指標在 DevTools Lighthouse 面板、PageSpeed Insights 和 web.dev Measure 工具中計算：

PageSpeed 洞察 CLS。

Google Chrome 的 Web Vitals 擴展程序還顯示了 CLS 指標：

Web Vitals 擴展 CLS。

與 LCP 和 FID 一樣，Chrome 用戶體驗報告允許您查詢針對特定 URL 的不同國家、連接和設備記錄的真實 CLS 統計信息。

web-vitals JavaScript 庫還可以計算實時站點上真實用戶的 CLS 指標，就像它使用 LCP 和 FID 一樣。可以將以下腳本添加到 HTML <head> 以將 CLS 指標輸出到回調函數：

<!DOCTYPE html>
<html lang=”en”>
<head>
<meta charset=”UTF-8″>
<title>我的頁面</title>
<script type=”module”>
import { getCLS } from ‘https ://unpkg.com/web-vitals?module’;
getCLS(console.log);
</script>
<!– 其餘頁面 –>

累積布局班次得分不佳的常見原因

糟糕的 CLS 分數通常是由載入緩慢的頁面資產和動態或未調整大小的 DOM 元素引起的：

頁面上的空間不是為圖像、iframe、廣告等保留的。
內容被動態注入到 DOM 中，通常是在網路請求廣告、社交媒體小部件等之後。
Web 字體載入會導致明顯的不可見文本 (FOIT) 閃爍或無樣式文本 (FOUT) 閃爍。

如何提高累積布局班次得分

客戶端審計可以識別問題，但通常是確保在下載內容之前為內容保留空間。為 Largest Contentful Paint 建議的伺服器優化技巧會有一些好處，但可能會進一步改進：

將寬度和高度屬性添加到 HTML <img> 和 <iframe> 標籤或使用新的 CSS 縱橫比屬性以確保在資源下載之前在頁面上保留適當的空間。
為包含載入速度較慢的第三方內容（如廣告和小部件）的容器元素設置適當的尺寸。
確保儘早請求出現在頁面頂部的圖像和其他資產——預載入可能會有所幫助。
盡量減少 Web 字體的使用，並在可能的情況下考慮使用常用的操作系統字體。
載入 Web 字體並將 CSS 字體顯示設置為可選或交換。確保使用類似大小的後備字體來最小化布局偏移。
避免向頁面頂部插入元素，除非它響應用戶操作，例如單擊。
確保用戶交互在輸入觸發後 500 毫秒內完成。
使用 CSS 變換和不透明度來實現更高效的動畫，不會導致重新布局。
考慮關鍵的內聯 CSS。在頁面頂部的 <link> 塊中嵌入必要的「首屏」CSS，然後非同步載入其他樣式表。
如有必要，請考慮包含，這是一項新的 CSS 功能，可讓您識別頁面的孤立子樹。瀏覽器可以通過渲染或不渲染特定的 DOM 內容塊來優化處理。

想要查看速度更快的網站…並確保您有資格使用 Google 的移動搜索輪播等功能？👀從這裡開始⤵點擊推文

概括

開發人員並不總是熱衷於跟隨 Google 的節奏跳舞。該公司擁有相當大的權力，微小的搜索引擎更新會對基於 Web 的組織的生產力和盈利能力產生不利影響。

也就是說，Core Web Vitals 採取「胡蘿蔔」而不是「棒」的方法。與提供糟糕移動用戶界面的臃腫、彈出式密集型網站相比，放棄暗模式的優化良好、可用的網站有更大的成功機會。

Core Web Vitals 提供了一種可衡量的方式來評估用戶體驗，以幫助您專註於最關鍵的改進。生命體征的變化可能不會增加收入，但您的用戶會更快樂、更忠誠。

您還有其他關於改進 Core Web Vitals 的技巧嗎？在評論部分分享它們！

通過以下方式節省時間、成本並最大限度地提高站點性能：

來自 WordPress 託管專家的即時幫助，24/7。
Cloudflare 企業集成。
全球受眾覆蓋全球 28 個數據中心。
使用我們內置的應用程序性能監控進行優化。

所有這些以及更多，都在一個沒有長期合同、協助遷移和 30 天退款保證的計劃中。查看我們的計劃或與銷售人員交談以找到適合您的計劃。