改善 Telegraph Media Group 的累計版面配置位移

在短短幾個月內，這家頂尖英國新聞網站成功將 CLS 第 75 個百分位數從 0.25 美元提高 250%。

Chris Boakes

注意： Chris 是 The Telegraph 的主要軟體工程師。

視覺穩定性挑戰

版面配置位移可能會造成嚴重干擾。Telegraph Media Group (TMG) 視覺穩定性尤其重要，因為讀者主要使用我們的應用程式查看新聞。如果版面配置在閱讀文章時位移，讀者可能會失去所在位置。可能會令人不悅且分心。

就工程的觀點而言，確保網頁不會轉移且中斷閱讀器可能並不容易，尤其是當應用程式的區域以非同步方式載入，並且以動態方式加入網頁中時。

TMG 中有多個團隊在用戶端提供程式碼：

• 核心工程：導入第三方解決方案來支援內容推薦和留言等領域。
• 行銷。執行 A/B 測試，評估讀者與新功能或變更內容的互動情形。
• 廣告。管理廣告請求和廣告預先出價。
• 編輯相關規定。將程式碼嵌入文章 (例如 Tweet 或影片) 和自訂小工具 (例如 COVID-19 充電盒追蹤器)。

要確保各個團隊不會造成頁面版面配置的理解可說是件苦差事。使用「累計版面配置位移」指標來評估讀者採取的頻率，團隊便能更深入瞭解實際使用者體驗，以及要努力達成的明確目標。這導致我們的第 75 個百分位數的 CLS 增加了 0.25 到 0.1，持續傳遞的值區從 57% 提升為 72%。

250_%

第 75 個百分位數 CLS

15_%

CLS 分數高的使用者

踏出第一步

透過 CrUX 資訊主頁，我們就能得知網頁變動幅度超出預期。

2020 年 6 月至 2021 年 2 月之間的累計版面配置位移分數。

理想情況下，我們希望至少 75% 的讀者享有「良好」的體驗，因此我們開始找出造成版面配置不穩定的原因。

我們如何測量版面配置位移

我們搭配使用 Chrome 開發人員工具和 WebPageTest，以找出導致版面配置位移的原因。在開發人員工具中，我們使用「效能」分頁的「體驗」部分，醒目顯示調整版面配置的個別例項，以及這些項目對整體分數的影響。

使用 Chrome 開發人員工具的「體驗」部分，找出在標頭上方的廣告載入用戶端時，造成的版面配置位移。

如果選取「醒目顯示版面配置位移」，WebPageTest 可在時間軸檢視畫面中醒目顯示版面配置位移的位置。

WebPageTest 醒目顯示版面配置的位移位置。

審視最常造訪的範本後，我們歸納出一些可以改進的地方。

減少版面配置位移

我們著重在可減少版面配置位移的四個方面： - 廣告 - 圖片 - 標題 - 嵌入

廣告

廣告在初始繪製後透過 JavaScript 載入。其中載入的部分容器沒有保留任何保留高度。

廣告下方的「更多案例」區塊會在廣告載入後移動。

雖然我們不知道確切的高度，但仍然可以使用版位中載入的最常見廣告大小來預訂空間。

由於預訂廣告空間，下方的「更多故事」區塊會在廣告載入前後保持靜態。

我們在某些情況下誤判廣告的平均高度。對平板電腦閱讀器而言，運算單元會收合。

在平板電腦大小的裝置上，向讀者載入廣告版位後會收合。

我們重新審視了版位，並調整高度以使用最常見的大小。

確保我們為廣告版位預留的空間與廣告最常見的廣告高度相符。

圖片

網站上許多圖片都是延遲載入，並保留給圖片的空間。

在不干擾版面配置的情況下延遲載入圖片。

但是，文章頂端的內嵌圖片並沒有在容器上保留任何空間，也沒有與標記相關聯的寬度和高度屬性。這會導致版面配置在載入時移動。

文章主要圖片造成的版面配置位移。

只要在圖片中加入寬度和高度屬性，就能確保版面配置不會移動。

載入主要報導圖片，但不會導致版面配置位移。

標題

標頭位於標記的內容下方，且使用 CSS 置於頂端。原本的構想是先排出內容載入時間再瀏覽，不過這會造成網頁短暫移動。

網頁標頭無法正常載入。

將標頭移至標記頂端可讓網頁在不進行偏移的情況下轉譯。

版面配置不再因載入網頁的標頭而中斷。

嵌入內容

一些常用的嵌入有經過定義的顯示比例。例如 YouTube 影片在播放器載入期間，我們會從 YouTube 提取縮圖，並在影片載入時將其當做預留位置。

影片播放器版位在影片播放器載入時，載入低解析度縮圖。

評估成效

使用本文開頭所述的工具，我們能夠輕鬆評估地圖項目層級的影響。但我們想同時在範本層級和網站層級評估 CLS我們以合成方式利用 SpeedCurve 來驗證試產階段和實際工作環境的變更。

使用 SpeedCurve 合成追蹤 CLS 進度。

接著，在程式碼進入實際工作環境後，我們可以驗證 RUM 資料 (由 mPulse 提供) 中的結果。

在變更前後，使用 mPulse RUM 資料驗證全站 CLS 資料。

檢查 RUM 資料有助於我們確信所做變更能為讀者帶來正面影響。

我們最後觀察的數字是 Google 收集的 RUM 資料。由於短期內對網頁排名產生影響，這一點特別重要。 首先，我們使用 Chrome 使用者體驗報告 (可透過 CrUX 資訊主頁取得的每月來源層級資料)，以及查詢 BigQuery 來擷取歷來 p75 資料。如此一來，我們就能輕鬆看到 CrUX 評估的所有流量，第 75 個百分位數的 CLS 從 0.25 提高到 0.1，同時傳遞的值區從 57% 成長至 72%。

Crux 資訊主頁的結果。

BigQuery 執行作業，會顯示 2021 年至今的 p75 值。

此外，我們還能利用 Chrome UX Report API，建立分割成多個範本的內部資訊主頁。

使用 Chrome UX Report API 的內部資訊主頁，醒目顯示了我們的平均分數，以及使用該範本時效能最差的網頁。

避免 CLS 迴歸

想要改善效能，其中一個重點就是避免發生迴歸問題。我們為關鍵指標設定了一些基本的效能預算，並納入 CLS。

這個效能預算資訊主頁，會顯示部分高流量範本評估 CLS 的綜合檢查。預算目前設為 0.025。

如果測試超出預算，系統會將訊息傳送至 Slack 管道，以便我們調查原因。我們也設定了每週報表，這樣一來，即使範本仍有預算未用完，我們也知道有任何變更會對此造成負面影響。

我們也打算擴大預算來使用 RUM 資料和合成資料，同時透過 mPulse 設定靜態快訊和潛在的異常偵測，回報一般情況下的任何變更。

採用新功能時，我們必須考量到 CLS。我提到的許多變更都是在讀者發布後修正。日後設計任何新功能的解決方案將考量版面配置穩定性，避免一開始發生任何非預期的版面配置位移。

結論

我們到目前為止所做的改善都非常容易實作，成效也十分顯著。本文中概述的許多變更並未花太多時間發布，且套用到所有最常用的範本，這表示這些修改對我們的讀者都有廣泛的正面影響。

網站上還有一些需要改善的地方。我們正在探索如何以更多方式執行用戶端邏輯伺服器端，進一步改善 CLS。我們會持續追蹤及監控各項指標，持續改善指標，並盡可能為使用者提供最佳使用者體驗。