A/B 測試的核心 Web 生命力：您的 A/B 測試軟件是否會降低您的網站速度？

谷歌剛剛放棄了他們的 Core Web Vitals 更新，我們需要注意它。

為什麼關心？

作為 CRO，我們通常不會過多擔心流量方面，因為我們關注的是當人們登陸我們的網站時會發生什麼以及他們採取的行動。

問題是，此新更新側重於用戶體驗，因此它不僅與我們作為優化者相關，而且您的測試實際上可能會對您網站的頁面體驗分數和流量產生負面影響。

不太好，對吧？

在本文中，我將向您介紹此更新是什麼，它是如何工作的，您的測試如何影響它，一些最佳實踐，不僅可以減少這個新的 SEO 更新的影響，還可以實際提高您的分數並且可能因此而獲得更多的自然流量。

我的 A/B 測試工具會減慢我的網站並影響我的核心 Web Vitals 分數嗎？

讓我們在上面解決這個問題。 只要您遵循測試和 CWV 設置的最佳實踐，Convert 應用程序的速度非常快，不會對您的頁面體驗或核心 Web Vitals 分數產生負面影響。

但是，並非每個站點都遵循最佳實踐，在這些情況下，您的 A/B 測試可能會影響您的頁面加載速度、首次輸入延遲、累積佈局偏移或最大內容繪製，具體取決於您的測試和站點設置方式.

好消息？

這些元素中的每一個都很容易修復。 我們將在本指南中介紹所有這些內容，以及如何提高您的基準頁面體驗和 CWV 分數，並且在測試時不破壞它們。

Core Web Vitals 和 Google 頁面體驗有什麼區別？

它們看起來很複雜，名字也很花哨，但它們基本上可以分解為跟踪用戶頁面體驗中的關鍵時刻：

• 您的頁面加載速度有多快？
• 用戶能多快看到頁面上的主要元素並理解它的含義？
• 他們多久可以與頁面交互？
• 從單擊按鈕到發生動作，這種交互作用需要多長時間？
• 頁面外觀如何，是否易於使用？

我們為什麼關心？

我們關心，因為谷歌關心，這是他們指出特定排名因素、它如何工作以及如何改進它的非常罕見的事件之一。 發生這種情況時，值得關注，因為這是即將發生的事情的徵兆。

為什麼 Google 關心用戶體驗？

簡而言之，如果他們推薦的結果提供了糟糕的體驗或不正確的結果，那麼他們的用戶就有可能開始轉向他們的競爭對手。

頁面體驗尚未被視為主要排名因素。 谷歌最近表示，在你和競爭對手之間一切平等的情況下，頁面體驗更有可能成為決定誰排名更高的決定因素，這僅僅是因為你提供了最好的體驗，但這不是唯一的因素。

（精彩的內容、優惠、EAT 和反向鏈接總是最能發揮作用。）

然而……谷歌似乎正在朝著用戶體驗成為未來主要搜索排名因素的方向邁出一大步。 他們將整個排名指數結果更改為專注於移動優先體驗和結果。

這意味著雖然頁面體驗是一種以移動為中心的算法，因為它們的整個索引現在都是移動優先的，但這會影響所有網站所有者以及它們在桌面結果中的顯示方式。

您可能在桌面上有很多內容，但它是移動版本，而不是桌面版本，這會影響您在結果中的排名。 不僅如此，谷歌還關心頁面的加載速度和佈局。 他們多次更新並提高了所需內容的標準，設定了加載時間等標準，所有這些都是為了改進移動搜索。

我之前說過，但最好現在就對此有所了解並開始實施最佳實踐，特別是因為用戶體驗可以直接影響我們的 CRO 活動，而您的測試工具也可能會影響這些 SEO 結果……

因此，讓我們分解這些頁面體驗指標中的每一個、您當前的結果、每個指標的含義以及如何滿足他們的要求，以及一些要記住的事情，這樣您的測試不會對您的分數產生負面影響。

如何衡量您當前的核心 Web Vitals 和頁面體驗結果

從技術上講，您可以為此使用 Google Search Console，但我覺得數據可能有點模糊或有限。 （結果被列為“差”、“需要改進”或“好”。）

相反，請前往 Google 的 PageSpeed Insights 工具並在那裡查看您的網站。

Insights 工具非常易於使用。 只需輸入您要檢查的頁面的 URL，讓它運行，然後查看移動設備和桌面設備的結果。

您的目標是在移動端和桌面端獲得 90 分或以上的分數。

顯然，這個頁面需要工作，因為移動用戶可以完全與這個頁面交互需要 14.7 秒！

現在，這個頁面需要這麼長時間才能在移動設備上加載是有原因的。 它大約有 11,000 個字，上面有 30 張左右的圖片和 3 個視頻。

通過 GIPHY

這是一個大頁面！

在本文中，我將繼續改進這個銷售頁面，因為我們處理每個 Core Web Vitals 報告推薦，以便您可以看到其頁面速度和得分的差異。

然後，一旦我更新了站點和頁面以滿足頁面體驗和核心 Web 生命力，我將展示在此頁面上設置 A/B 測試可能會如何影響我的結果。

• 任何紅色的東西都需要盡快處理。
• 黃色的任何東西都可以改進。
• 目前綠色的任何東西都符合要求。

有趣的是，Convert Experiences 應用程序僅在後台將我的頁面減慢了 107 毫秒，而 Vimeo 應用程序導致了 1,567 毫秒的延遲。

這不是他們的應用程序的錯，而是因為我需要解決我的頁面和網站的一系列問題，這些問題導致它無法正常運行。

不過，在我改進這些問題之前，我們需要了解它們的含義以及該工具是如何產生這種結果的……

PageSpeed Insights 工具是如何得出這些結果的？

PageSpeed Insights 工具使用 Google 的 Lighthouse 開發測試工具來了解您的頁面的執行情況。

Lighthouse 根據您的頁面性能應用特定的權重指標來得出此分數。

這些權重基於最重要的用戶體驗因素，並且通常會隨著 Google 添加新功能來跟踪用戶體驗而發生變化。 （同樣，這就是為什麼這似乎是今天要關注的重要事情）。

如果我們將這些權重的最新版本與 Lighthouse 的最新版本進行比較，我們可以看到，與之前的版本相比，Cumulative Layout Shift 和 Total Blocking Time 的重要性被賦予了更大的權重。

這是否意味著其他元素突然變得不那麼重要了？

一點也不。 事實上，隨著更多網站更新並滿足標準頁面體驗要求，它們的權重可能會降低。

似乎現在的重點已經轉移到阻止頁面在頁面加載時更改佈局並減少頁面響應用戶輸入所需的時間。

這些都是我們作為測試人員需要考慮的重要事情，因為我們的測試可能會導致頁面加載速度變慢，或者當我們測試新的佈局設計時佈局可能會發生變化。

Lighthouse 工具採用這些權重，然後使用稱為實驗室和現場數據的東西將它們應用於您的當前頁面，以衡量您頁面的性能。

什麼是實驗室和現場數據？

Lab Data 基本上是對特定條件的模擬，以創建控制環境。 閱讀本文的大多數用戶將使用它來測試和改進他們的頁面。

而現場數據是基於該特定頁面上的真實用戶體驗，但它有點缺陷。 您需要該頁面的大量實時流量才能獲得結果。 不僅如此，這些流量還必須來自 Chrome 用戶，他們也選擇了 (CrUX) Chrome 用戶體驗報告，並非每個人都使用或選擇加入。

現場數據的用戶得分基於該頁面上用戶體驗的第 75 個百分位。

為什麼這很重要？ 因為每個用戶的體驗可能會因他們的設備和互聯網速度而異。

如果您的 26% 的觀眾在連接速度較慢的 iPhone 5 上瀏覽，那麼您的分數可能會下降到 74%，這表明您的頁面“需要改進”。

最後，現場數據基於 28 天滾動匯總，因此報告基於以前的結果。 今天的更改將不會在下一個月的結果中反映出來。

如您所見，現場數據與我們所有人都無關。 好消息是，來自 Insights 工具的實驗室數據已經足夠好，它為我們提供了足夠的信息來了解我們的更改和更新如何影響模擬環境，因此我們可以大致了解我們的網站在野外的表現如何。

所以現在我們知道了我們在性能最差/最重要的頁面上的基線結果，我們可以了解所有這些指標的含義以及如何改進它們。

谷歌的頁面體驗指標是什麼，三大核心Web Vitals指標，我們如何改進它們？

有4 個基本頁面體驗指標和另外3 個在稱為核心 Web Vitals 的特定子集中（最新 Google 更新的焦點）。

這些基本指標中的每一個都很容易實現。 您所需要的只是一個響應式站點，沒有狡猾的代碼，不在彈出窗口中覆蓋該站點，並且通過 HTTPS 運行。

這些只是基本元素。 Lighthouse 在使用實驗室數據衡量您的頁面體驗性能時，還使用了 6 個頁面體驗指標。

現在雖然有 6 個 Lab 指標需要關注，但它們都是相互關聯的。 這意味著一個人的進步通常會看到其他人的進步。

為了幫助簡化這一切，谷歌將這些分解為 3 個核心 Web Vitals：

• 最大的內容塗料
• 第一輸入延遲，和
• 累積版面偏移

這些是我們需要改進的地方，也是我們的測試可能影響我們排名的地方。

在了解您的測試如何影響這些分數之前，讓我們了解一下下面的每一個核心網絡生命以及您需要做些什麼來改進它們。

1.最大的內容塗料（LCP）

最大內容繪製基於屏幕上最大可見元素的加載速度。 這可能是英雄鏡頭、背景圖片，甚至是標題文本。

該分數旨在復制您的受眾開始看到頁面上的主要內容並了解頁面內容所需的時間。

目前，LCP 佔 CWV 分數的 25%。

您的讀者能夠理解您的頁面對於修復很重要，但不僅如此。 您會看到，導致 LCP 緩慢的大多數問題通常是導致頁面變慢並導致其他 CWV 問題的根本原因。 這意味著如果您修復了這些 LCP 元素，那麼您已經完成了大部分工作。

您的目標應該是讓您的 LCP 在 2.5 秒內加載。

降低 LCP 分數/速度的主要問題是：

• 服務器響應時間慢
• 渲染阻塞 JavaScript 和 CSS，導致元素延遲
• 緩慢的資源加載時間
• 客戶端渲染慢
• 差/錯誤地設置圖像優化。

如何提高您的 LCP 分數

您可以實施幾件事來提高您的 LCP 分數。

在我進行任何推薦的調整之前，您可以在這裡查看我的示例銷售頁面 LCP 分數。

目前，我的 LCP 元素在頁面上加載需要 3.4 秒，即使它只是文本的標題，而我的頁面在變為交互之前需要 14.7 秒才能加載。

如果我們向下滾動瀏覽 PageSpeed Insights 工具並查看機會，我可以做很多事情來提高整體頁面速度並阻止一些減慢 LCP 速度的事情。

讓我們來看看所有這些。

一個。 預加載 LCP 元件

您需要做的第一件事是檢查當前頁面的實際 LCP 元素是什麼，因為它可能因頁面而異。

在 PageSpeed 工具的移動視圖中，向下滾動頁面到診斷部分，然後單擊“最大內容繪製”元素，看看會出現什麼。

在這個特定頁面上，我的 LCP 元素是我的標題。

我可以通過整理頁面上的其他內容（例如壓縮和緩存）來提高文本的加載速度，但是如果我的 LCP 元素是圖像怎麼辦？

在這種情況下，我想在頁面上預加載圖像，以便它在頁面甚至開始呈現之前就開始加載。

這樣，圖像會立即開始加載，並且不會因其他代碼或請求而減慢速度。

這是一件大事。

標準做法是延遲加載頁面上的所有圖像，以幫助提高頁面速度。 但是，當您對 LCP 圖像執行此操作時，它實際上會使其加載速度變慢，從而降低您的 LCP 分數！

（如果您也在 A/B 測試 LCP 元素，這將是一個大問題！）

那麼我們該如何解決呢？

我們想編寫一些代碼來指定這個特定的 LCP 元素應該預加載到一個特定的頁面上。

您要添加的腳本是 rel=”preload” 腳本，它看起來像這樣：

在這個例子中，我告訴這個特定頁面預加載 TRAFFIC-SMALL-HEADER 圖像（這是該頁面的 LCP 圖像元素）。 我還指定了多個維度選項，以便它可以為移動設備和桌面加載響應式圖像。

僅此更改將有助於解決影響 LCP 分數的任何加載緩慢的圖像。

一些 WordPress 或 Shopify 主題將允許您將自定義代碼添加到該特定頁面的標題中，而一些插件將允許這樣做。 否則，您還可以編輯頁面的 header.php 文件並直接添加代碼。

我在這裡介紹了一些基礎知識，但我們將要介紹的大多數修復可能會因您的站點和使用的內容而異。 （如果您沒有使用 WordPress 或沒有開發人員，請讓他們在此處查看 Google 的用於優化 LCP 的開發建議）。

由於我的網站是基於 WordPress 構建的，因此我將使用 WPRocket 插件，因為它將幫助我在一個地方解決 LCP 的大部分問題。

灣。 使用高性能/專用主機

一個超級簡單的修復實現。 當您的用戶加載您的網頁時，它會向您的網絡主機發送請求以獲取頁面信息和存儲的文件等。

一些網絡託管服務在共享託管平台上工作。 這意味著它們在多個站點之間共享基礎架構。 因此，這意味著您共享主機上的其他站點的流量可能會降低您自己站點的性能。

遷移到僅 100% 為您的站點提供的專用託管服務不僅更快，而且更安全，並且可以幫助解決頁面加載問題和服務器響應時間。

在這裡您可以看到我的站點的初始服務器響應時間為 2.67 秒。

升級到專用主機後，它完全消除了服務器響應延遲，為我節省了 2.67 秒的加載時間，還提高了速度指數和交互時間。

C。 啟用緩存並增加緩存長度（如果需要）

緩存允許您通過為用戶存儲站點內容的保存副本來節省服務器請求，以便在重複訪問時快速加載。

這樣，如果他們回來並想再次查看內容，加載速度會非常快。

d。 推遲非關鍵 JS + 刪除未使用的 JS

當頁面加載時，它會輪流一次加載一個內容（異步），或者減慢速度並嘗試一次加載多個內容（同步）。 如果您有一個快速的服務器，或者如果您正在快速加載的第 3 方應用程序（例如 Convert Experiences 應用程序），這還不錯。

但是，我們可以通過推遲一些元素（告訴它們在更重要的事情之後加載）或刪除不需要在每個頁面上加載的元素來幫助提高我們的分數和頁面速度。

這通常是 LCP 加載問題的主要原因，因為這些元素會嘗試在 LCP 元素之前加載。 （它們也可以影響第一個輸入延遲）。

您可以在 WPRocket 中指定要延遲或刪除的 JS、應用程序或插件。 （只需確保將轉換腳本設置為優先加載而不是延遲）。

這樣一來，任何非必要的 JS 都會被刪除，其他 JS 會被延遲使用，並且 Convert 腳本可以盡快運行。

邊注：

您還可以使用此部分來優先加載任何高於折疊元素的元素，例如滑塊或輪播。 只需將代碼添加到排除部分，它就會正常加載。

e. 考慮代碼縮小

您還可以通過縮小網站上的 JS 和 CSS 代碼來加快頁面加載時間。 縮小用於刪除不必要或冗餘的數據，而不影響瀏覽器處理資源的方式，例如代碼註釋、空格和格式、刪除未使用的代碼、使用較短的變量和函數名稱等。

許多插件將允許您執行此操作。

只需確保在申請後檢查您的頁面，因為它有時會導致問題。 （特別是在組合代碼時，這就是我在這裡沒有使用它的原因。理論上它應該可以正常工作，但我過去遇到過問題。）

F。 針對延遲加載和響應性優化圖像（只是不是 LCP 圖像）

可能會降低頁面性能的因素是圖像大小和您擁有的圖像量。

如果您有一個圖片較多的頁面，您可以通過延遲加載圖片來提高加載速度，以便頁面下方的圖片僅在查看器向下滾動時才開始顯示。

（不過請記住預加載 LCP 映像！）

您還可以通過指定特定的圖像尺寸來進一步幫助頁面加載。 （有時，您可能會意外上傳一個巨大的圖像，然後將頁面壓縮到正確的大小時會減慢頁面速度。）

G。 使用圖像壓縮和響應式大小

您可以通過減小文件大小來加快圖像加載速度，然後提供響應大小以適合用戶使用的設備。

較小的文件大小意味著它們需要更少的資源來加載用戶的設備，同時從他們的角度來看仍然保持高質量。

WPRocket 還集成了一個名為 Imagify 的插件來壓縮和提供響應式圖像（通過為不同的屏幕尺寸添加多個 scrset 選項）。

H。 盡快建立第 3 方連接

如果您的網站上有可以減慢頁面加載速度的內容或腳本，您可以將其設置為盡快開始預加載特定元素，以便它們加載更快。

還記得我的視頻之前是如何減慢我的頁面的嗎？

通過設置第 3 方 DNS 預取請求，我可以加快所有這些視頻的加載速度。

一世。 使用 CDN 減少加載時間

CDN 或內容交付網絡通過將站點的緩存版本保存在離用戶位置更近的服務器上，從而進一步加快站點加載速度。

您可以免費使用 Cloudflare 之類的工具來做到這一點。

j. 使用 Gzip 或 Brotli 壓縮來優化文件大小

您還可以使用 Gzip 或 Brotli 等壓縮插件進一步加速您的網站，但有些 CDN 會自動執行此操作，因此請先仔細檢查您的網站是否已安裝。 （Cloudflare 已內置此功能。）

那麼進行所有這些更改的影響是什麼？

我提高了網站加載速度，將其在移動設備上從 13.5 秒降低到 3.3 秒。 我的 LCP 速度現在是 2.1 秒。

這節省了 10.2 秒！

還不錯吧？

還有一些問題需要修復，但隨著我們處理其他 2 個 Core Web Vitals 的工作，它們應該會有所改進。

2. 首次輸入延遲 (FID)

首次輸入延遲是衡量當用戶嘗試執行某個操作（例如按下按鈕或單擊鏈接）時頁面響應所需的時間。

FID不良的最常見原因是：

• 第一方腳本執行導致交互就緒延遲。
• 數據獲取影響交互準備。
• 第三方腳本執行延遲交互延遲。

首次輸入延遲的權重為 CWV 分數的 30%，您的目標是將響應時間降至 100 毫秒或更短。

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

我們無法在沒有實時用戶的情況下測量 FID，因此，我們嘗試改善總阻塞時間 (TBT)，因為它們都是連接的。

那麼讓我們回顧一下我們的頁面結果......

當我第一次測量我的頁面時，我的 TBT 是 1.5 秒（或 1,560 毫秒）。

由於我改進了 LCP 元素，它下降到 0.2 秒（210 毫秒），而完全交互則需要 3.5 秒。

這是因為我們已經解決了一些減慢總阻塞時間的問題，只需修復一些 LCP 問題，例如代碼縮小和延遲或刪除 JS。

它已經接近所需的速度範圍，但讓我們向您展示一些您可以做的其他事情，以防您的分數還沒有達到。

一個。 預加載內容和鏈接

這是 WProcket 內部的一個很酷的功能。 通過預加載 LCP 圖像，我們告訴頁面盡快開始加載 LCP 圖像。

通過預加載鏈接和站點地圖，當用戶將鼠標懸停在按鈕或鏈接上時，我們會告訴網站開始在後台預加載內容。

這意味著這些資產甚至在用戶請求它們之前就開始加載，從而加快了 FID 並降低了他們點擊進入的其他頁面的總阻​​塞時間。

這裡的好處是其他頁面上的 FID 更快，所以讓我們看看更多方法來改進它們加載的第一頁。

我們可以做的改善 FID 的主要事情是從我們的站點中刪除代碼膨脹。

繼續並在 GTMetrix 中加載您的頁面。

哇，這個分數看起來很神奇，對吧！？

好吧，那是因為這是您的桌面樂譜，而不是您的手機樂譜。 （除非您付費定制設備和位置，否則 GTMetrix 將始終在桌面上顯示來自 Chrome 用戶的頁面加載模擬。）

這很好，因為我們要查看的是瀑布部分，以查看頁面加載延遲的區域。

米色的條是我們需要改進的地方，因為在這些地方，另一個代碼被阻止加載。

我可以在瀑布圖中看到一些舊插件和字體正在減慢頁面加載速度，因此我可以返回並預加載這些自定義字體。

在瀑布中打開它們，然後將字體 URL 複製並粘貼到 WProcket。 （我應該早點添加它們，但忘了哇！）

因此，讓我們看一下消除進一步阻塞和代碼膨脹的幾種方法。

灣。 刪除插件膨脹

如果您的網站已經有一段時間了，那麼很容易開始收集一堆插件並添加不再需要的多餘代碼。

您可以通過刪除未使用的插件或執行相同任務的重複插件來加速您的網站。

你也可以：

• 更新插件以查看它們是否運行得更快。
• 或者尋找可以用更少的代碼做同樣事情的替代插件。

C。 刪除主題代碼膨脹

某些主題內置了多餘的代碼，以提供您可能不需要的設計或樣式選項，從而導致頁面加載時間更長。

您可以用更輕的主題替換您當前的主題，以滿足您的需求，並看到頁面速度和加載時間的巨大飛躍。

就個人而言，我使用 Neve 免費主題，因為它乾淨輕巧，總安裝大小僅為 75kb，但您可以使用任何您想要的主題。 （只需搜索“快速加載”或“移動優先”主題。）

d。 消除頁面膨脹

另一個可能導致頁面膨脹和 CLS 問題的主要問題是頁面構建器，主要是因為它們使用過多的代碼來表示某些功能。

通過刪除 Page Builder 插件、簡化頁面代碼、使用 builder 重新構建它或製作自定義 HTML 頁面，您可以看到低得多的 DOM 分數。

那麼更改後我的分數是多少？

我還沒有刪除我的頁面構建器，但分數仍然下降到只有 130 毫秒 Total Blocking Time 並且頁面在 1.9 秒內加載。

想進一步提高頁面速度嗎？

您可以使用另一個很棒的插件，名為 Asset Cleanup（這是我們團隊在 Convert 中使用的插件）。

它允許您指定在站點的每個頁面上加載哪些插件或資產，幫助您從特定頁面中刪除未使用的插件，以免它們不必要地增加加載時間。

例如，您的站點上可能有一個聯繫表單插件，但它的代碼正在加載到不需要它的頁面上。

使用 Asset Cleanup，您可以進入該頁面，然後向下滾動並告訴插件不要在該特定頁面上加載。

3. 累積版式偏移（CLS）

您是否曾嘗試單擊網站上的某些內容，然後它會移動並顯示廣告或橫幅？

令人沮喪，對吧？

作為優化者，這對我們來說尤其重要，因為像這樣糟糕的用戶體驗可能會導致用戶界面損壞或只是觀眾不知道該怎麼做。

（一些不道德的人實際上會將其構建為黑暗設計以獲得特定點擊等。尤其是銷售廣告空間的網站......）

CLS 測量頁面上移動了多少元素（也就是它的視覺穩定性），然後對您的網站進行評分。 它的目標是阻止這些網站創造這種糟糕的用戶體驗，它目前的權重是你 CMV 分數的 15%。

您的目標是獲得 0.1 或更低的 CLS 分數。

不過，影響佈局變化的不僅僅是廣告。 事實上，導致 CLS 評分不佳的最常見原因是：

• 沒有尺寸的圖像
• 沒有尺寸的廣告、嵌入和 iframe
• 動態注入的內容，例如側邊欄或標題中推送內容的廣告
• Web 字體通過從通用字體更改為自定義字體並影響佈局間距而導致 FOIT/FOUT
• 在更新 DOM 之前等待網絡響應的操作。

好消息是，我們已經通過修復 LCP 和 FID 的問題解決了很多問題。

• 我們設置了圖片、廣告和 iframe 視頻尺寸。
• 我們已預加載任何自定義字體，因此它們不應導致佈局變化。
• 而且，如果您刪除了頁面構建器，則應該降低頁面的整體 DOM 元素，使其更快並減少請求！

如果您向下滾動 PageSpeed Insights 工具並單擊“避免大的佈局變化”，您可以查看頁面的哪些元素當前導致 CLS 問題。

在我的示例中，它只是將標題更改為移動設備的響應式佈局，並且不會對 CLS 產生太大影響。

您的站點可能有所不同，因此請查看導致問題的原因並加以解決。

既然我們已經介紹了 Core Web Vitals 的每個領域以及如何改進它們，讓我們看看您的測試如何影響您的分數。

Core Web Vitals 如何影響 UX 和 A/B 測試（以及如何在使用轉換腳本時通過 Core Web Vitals 評估）

只要您堅持我們迄今為止所涵蓋的最佳實踐，您就不應該遇到太多問題，但讓我們分解它們。

如何在 A/B 測試時不對最大的內容繪製分數產生負面影響

請記住，LCP 元素是在初始頁面加載時在取景器或屏幕上看到的，因此您甚至可能沒有測試任何 LCP 元素，但以防萬一：

如果您正在測試 LCP 元素，例如新背景、主圖或標題，該怎麼辦？

您在這裡可能遇到的問題不是轉換體驗工具，而是 LCP 改進的不良做法。

Like we mentioned earlier, most people make the mistake of lazy loading all images, including the LCP image, which affects the LCP score.

Convert Experiences uses both 'synchronous load' and 'body hide' methods to run tests. Simply put, the tool recognizes the element to be tested and then hides it as soon as it starts to load so the user never sees it, before changing it in under 50 milliseconds.

If you've lazy-loaded that LCP element though, the Convert Experiences app is going to have to wait for that element to load before it can do its job.

You can fix this by preloading the specific LCP elements on your control and test pages like we suggested above. This will get them to start loading immediately on page load, allow them to be recognized and hidden by the Convert app, and be replaced asap before the user notices.

Not only will this reduce flicker, but it will also give a good LCP score as the main LCP element (even when tested) will load fast.

And if the LCP element is not what you're testing? You should be pre-loading it anyway to improve that LCP score.

How to Improve First Input Delay when A/B Testing

The Convert code is incredibly fast, but your FID score still relies on all the other elements of your page.

Make sure to hit all the main requirements for speed that we talked about before so that there is no delay in the Convert code running. (Otherwise, the element you are testing will be hidden until it loads and then changes.)

• You can remove code bloat from other JS and defer them from running.
• You can also 'exclude' the Convert script from being deferred so that it loads up before any other JS so that it can make those test changes asap, while not hurting FID.

If you don't prioritize the Convert code and instead defer it by accident, it may not affect your FID score that much, but it might cause your test element to delay loading, while the script waits to run.

How To Decrease Cumulative Layout Shift Issues When A/B Testing

The potential issues with Cumulative Layout Shift and testing come down to how you run a layout test.

Ideally, you don't want to test massive layout changes with just the Convert Experiences editor. Instead, you want to test similar elements for variations ie swapping out a hero image for another image or swapping text for variations, etc. This means that the page layout stays the same, but a key element is swapped out for a variation.

But what if you want to test a minor layout shift, such as swapping the hero image and text location?

I recommend using Convert Experiences for small layout shifts to set up the test and then see how much it affects your CLS score before you push it live.

A real-world example:

Let's say that I set up that same flipped layout test as above. First, I would build the test inside the Convert Experiences app.

Then I can test this page variant in the page speed tool to get an idea of how it affects CLS.

Make sure you have the variant page open, and then click on the pen icon next to the variant in the Convert Experiences app, then select 'Open Force Variation URL':

This will load a pop up.

Make sure you have the variation page highlighted and then click to copy the URL.

You can input that URL into the PageSpeed Insights tool and measure the CLS and other CWV vitals for that variant.

Full disclosure:

In this particular example, I have not fixed any of the code bloat issues on this other page yet, but here you can see the original control page results based on just the LCP improvements.

速度和 TBT 都很棒，但是 CLS 超出了我們在控制頁面上的目標，因為我在我的網站上使用的頁面構建器仍然會導致問題。

但是，出於興趣，讓我們將控制頁面上的 CLS 分數與變體的結果進行比較：

如您所見，變體頁面上的 CLS 可以很好地使用，因為分數仍在指導範圍內。

（一旦我使用頁面構建器對代碼膨脹問題進行排序，速度問題就會得到解決，但轉換體驗應用程序和佈局測試運行速度非常快。）

所以小的佈局更改可以工作，只要確保在推送它們之前先測試它們。

但是，如果您想測試較大的佈局變化，例如完全重新設計或刪除或添加頁面元素，該怎麼辦？

通過 GIPHY

在這種情況下，我將遵循相同的最佳實踐來測試動態重新設計或大型佈局更改，即運行拆分 URL 測試。

與其使用 Convert WYSIWYG 編輯器來調整和刪除所有多餘的文本元素，不如在預先完全編輯和構建變體頁面的情況下運行拆分 URL 測試會更有效。 （無論 CLS 是什麼，這都是最佳實踐）。

通過這種方式，您可以測試變體頁面與控件並獲得兩者的快速加載時間，而不會因那些主要的佈局變化而影響您的 CLS 分數。

結論 + 要點

所以你有它。 我們的 Google Page Experience 完整指南、3 Core Web Vitals 更新、您的測試如何影響這些 Vitals 以及如何提高您的分數。

想要進一步調整嗎？

根據您的特定用例需求，您甚至可以編輯 Convert Experiences 應用程序以異步運行、停止身體隱藏功能，或者甚至使用異步並同時刪除身體隱藏功能。 （您可能希望這樣做以幫助更快地加載並停止等待工具完成加載的其他資產）。

大多數用戶永遠不需要這樣做，特別是如果您遵循我們迄今為止制定的最佳實踐。 （如果您仍在苦苦掙扎，如果您是 Convert Experiences 用戶，您可以隨時聯繫我們的支持團隊。）

記住：

• Convert Experiences 應用程序非常快，但如果您遵循 Core Web Vitals 和 A/B 測試的最佳實踐，它可以更好地工作。
• 谷歌很少提供有關特定排名信號的信息，因此頁面體驗和核心網絡生命力很重要，並且在未來可能會繼續變得更加重要。 （自早期版本以來，他們已經提高了站點速度閾值。）
• 根據 Google 的說法，Core Web Vitals 在所有其他條件相同的情況下是決勝局，因此在高端競爭時值得這樣做。 如果內容或報價的質量相同，並且競爭頁面的頁面排名相似，那麼用戶體驗將決定搜索頁面排名。
• Core Web Vitals 關注頁面上的實際用戶體驗，因此這對 CRO 很重要。 值得應用最佳實踐，因為這會影響頁面加載速度、跳出率、點擊率、轉化率等，尤其是在移動設備上。
• Core Web Vitals 甚至可能開始影響付費流量登陸頁面體驗以及您在廣告拍賣中的表現/投放廣告的成本。 改善這一點可能會影響廣告成本和投放。
• 您需要具備滿足頁面體驗要求的基本元素。 快速加載、CDN、緩存、HTTPS，在您查看其他要改進的元素之前。
• 代碼膨脹和加載順序會影響首次輸入延遲和最大內容繪製。 您需要知道如何設置、限制、預加載元素或延遲 JSS 和 CSS 以有效地加載您的頁面。
• 在測試首屏內容（在任何設備的查看區域中）時，請注意 LCP 元素以及預加載它以減少 LCP 問題的必要性——尤其是如果這是您的測試重點。
• Convert Experiences 應用程序運行速度如此之快，不會對 Core Web Vitals 產生負面影響，假設您正在運行 A/B 測試，而大的佈局更改不會發生變化。 （將元素替換為相似元素、將文本替換為文本、將圖像替換為圖像、按鈕變體等）。 否則，這將影響 CLS。 （您始終可以在上線之前測試任何佈局更改變化。）
• 當執行較大的佈局更改時，建議進行拆分 URL 測試（就像動態測試一樣），因為這會影響 CLS。 只需確保將獲勝的變體更新為原始 URL，並 301 重定向變體可能獲得的任何鏈接（罕見情況）。