企業業務的核心 Web 生命力：與 Kathy Brown 和 Karl Kleinschmidt 的問答

企業業務的核心 Web Vitals：與我們自己的 Kathy Brown 和 Karl Kleinschmidt 的問答

2 月 18 日，我們舉辦了企業業務核心 Web Vitals 會議，以解決 Google 新的頁面體驗排名因素更新。 會議的重點是什麼是核心網絡生命力以及它們為何重要。 我們的專家深入研究了每個新排名信號的含義以及它們將如何影響 SEO。 儘管我們提供了可操作的提示和建議，但仍有許多關於 FID、LCP、CLS 等的問題。

以下是從我們的聽眾那裡收集的問題，我們的專家 Kathy 和 Karl 解決了這些問題。

現場數據和實驗室數據有什麼區別？

Kathy ：實驗室數據是你在特定環境中看到的性能數據。 諸如 Chrome 開發工具之類的工具以及諸如 pagestest.org 之類的工具正在為您提供實驗室數據。 字段數據是從使用 Chrome 瀏覽您網站頁面的許多用戶那裡收集的數據。 您可以在 Google Search Console 中查看字段數據，並且通常在 Google Page Speed Insights（它將報告頁面的實驗室和字段數據）中查看。 對於自動化需求，可通過 BigQuery 訪問字段數據。 請記住，實驗室數據用於測試，現場數據用於排名。 根據 John Mueller 的評論，我們預計 CWV 最初只會影響移動排名，您需要“處於綠色”狀態才能使所有三個指標排名更高。

當沒有可用的現場數據時，您會怎麼做？

Kathy ：如果沒有可用的字段數據，這可能意味著該頁面沒有獲得大量流量。 使用 Google Page Speed Insights 檢查您最受歡迎的頁面，以查看這些頁面是否有可用的字段數據。 然後，您可以推斷屬於該頁麵類型的所有頁面的結果。 嘗試設置一個 CrUX 報告以查看您的來源（您的域）是否有一個報告。 您可以找到一個預構建的 Google Data Studio 模板，這將為您提供網站的整體性能數據。

如果您仍然找不到任何 Field 數據，請確定訪問您網站的最常用設備和瀏覽器，並使用這些環境進行測試。 請記住設置節流和帶寬控制以模擬盡可能接近訪問者的環境。

在開發過程中，我們的網站在比我們的生產服務器慢得多的輔助服務器上運行。 在這種情況下，您如何測試頁面速度？

Kathy：大量的 Core Web Vital 評分將取決於客戶端及其運行的代碼。 因此，較差的 CLS 分數與慢速服務器無關。 但是，由於連接握手速度較慢以及發送資源所需的時間，LCP 可能會受到速度較慢的服務器的影響。 要考慮的一種方法是為您的服務器創建一個指標比較，例如各種頁面的 TTFB（到第一個字節的時間），以及比較交付每 1 KB 數據的時間。 此外，如果您有數據庫操作或服務器端 JS，了解每個服務器中這些執行時間之間的差異也會有所幫助。 比較兩者之間的瀑布圖，看看在開發環境中還有多少額外的等待時間。 了解這些差異將有助於更輕鬆地評估開發服務器上的 LCP 性能。

你認為預加載鏈接（對於後續頁面）會影響 LCP 還是你認為 LCP 僅依賴於用戶加載的第一頁？

Kathy：對於現場數據，所有頁面的性能都很重要。 緩存靜態資產（有助於後續訪問和頁面）將有助於您的字段得分。 使用鏈接預加載 CSS 樣式，預加載也可能有助於提高所有頁面的性能。

具有良好緩存優化的 CDN 能否顯著降低 LCP 分數？

Kathy：如果 LCP 對所有用戶（新用戶和老用戶）出現得更快，那麼你的 LCP 分數肯定會提高。

如何在不影響 Core Web Vitals 的情況下使用彈出窗口？

Karl：對於 LCP 問題，請確認彈出窗口不會佔用太大的視口百分比，尤其是在移動設備上。

對於 CLS 問題，請確認彈出窗口不會使您的其餘元素移動，而是在它們前面。

在移動優先索引的背景下，我們應該如何考慮 CWV？

Karl： CWV 將首先推出移動端，然後推遲到桌面端（我們不知道會延遲多少）。 CWV 並不是關於 Google 如何抓取您的網站，而是關於訪問者如何與您的網站互動，因此移動優先索引不應該有所作為。

總阻塞時間 (TBT) 和 FID 有什麼區別？

Karl：總阻塞時間是主線程阻塞任務阻塞交互的總毫秒數（每個任務減去 100 毫秒）。 FID 是您的網站響應訪問者互動所需的平均時間。 因此，總阻塞時間是頁面加載過程中 FID 可能高於 0 的總毫秒數，而 FID 捕獲用戶實際與您的站點交互的方式。

我們在 Google Search Console 中看到了分數變化，而我們自己卻沒有進行更改/改進。

搜索控制台內出現這些波動的原因是什麼？

Karl：因為 Search Console 是字段數據，它取決於用戶如何與您的網站進行交互。 用戶行為的變化可能意味著不同的 CLS 分數，因為訪問者滾動不同或不同的 LCP 分數，因為更高百分比的訪問者是回頭客，因此他們緩存了某些圖像。 指標波動的可能原因有很多，請記住數據延遲了大約 28 天，因此您可能在 28 天前發布了一些內容，現在看到了數據的變化。

如果有人從 Search Console 和 PageSpeedTest 獲得不同的結果，我們是否應該只擔心 Search Console 上報告的內容？

Karl：在現場數據與實驗室數據之外，搜索控制台與頁面速度洞察之間數據不同的主要原因有兩個。 如果您的某個頁面沒有獲得足夠的流量，Google 會在頁面速度洞察中使用類似的頁面數據，而在搜索控制台中，則會對可能有足夠數據的類似頁面進行分組。 因此，也有可能您的某個頁面有足夠的流量，但沒有一個相似的頁面有足夠的流量，這也可能導致分數差異。 搜索控制台報告也有更新，這可能會產生影響。

需要額外資源？

我們有很多關於這個主題的精彩內容。 查看我們的 Core Web Vitals 頁面，我們在其中匯集了專家資源庫，如播客、網絡研討會和博客。 您可以找到為 Google 的頁面體驗排名因素更新做好準備所需的一切。