經過數個月的努力，我們改善 Mail.ru 首頁的網站體驗核心指標，使累計版面配置位移 (CLS) 的第 75 個百分位數增加了 60%，不僅平均工作階段時間增加 2.7%，核心專區的轉換率也提升了 10% 以上。
踏出第一步
Mail.ru 是俄語網際網路上首屈一指的電子郵件服務之一，流量在俄羅斯前 5 名。Mail.ru 是許多使用者的重要資源。它每個月的造訪次數高達一億，而且是一個入口網站，可供人們存取電子郵件、新聞、社交媒體、效能網路搜尋等。
Mail.ru 希望為訪客提供優質的使用者體驗，因此開始改善網站體驗核心指標。在討論最佳化策略之前，首先應該先瞭解 Mail.ru 首頁的幾項技術細節。
雖然這項專案長期使用 Google 內部的範本引擎 Fest 發展，但我們在 2019 年開始遷移至 Svelte 3。
Svelte 以不使用虛擬 DOM 的方式實作例項，降低資源耗用量。Svelte 的做法會從正式版套件中移除未使用的函式，因為實作的程式碼不會在未使用函式的情況下產生。系統會在編譯期間移除未使用的程式碼，進而產生較小的套件。這有助於縮短頁面啟動期間的總封鎖時間 (TBT)。
追蹤成效指標
在最佳化網站體驗核心指標前，建議您先評估相關實際成效。在導入網站體驗核心指標之前，我們已在內部效能資訊主頁追蹤首次內容繪製 (FCP) 等其他指標。
指標收集指令碼經過修改，會收集網站體驗核心指標，並將其傳送至效能資訊主頁，以便呈現圖表。為遵循 Google 的建議，我們的指令碼使用 PerformanceObserver API 取得指標，這是 Mail.ru 通用前端「平台」的一部分。
資訊主頁顯示了使用者下列指標 (代表 2021 年 3 月 15 日至 21 日當週的值)：
| 指標群組名稱 | Core Web Vitals | 其他網站體驗指標 | |||||
|---|---|---|---|---|---|---|---|
| 指標名稱 | LCP | FID | CLS | FCP | 待定 | 文字轉語音 | |
| 符合網站體驗核心指標門檻的使用者比重 | good | 52% | 92% | 33% | 35% | 42% | 43% |
| 需求改善 | 19% | 5% | 23% | 38% | 16% | 25% | |
| 差 | 29% | 3% | 44% | 27% | 42% | 32% | |
改善網站體驗核心指標
雖然改善網站體驗核心指標有許多指引，但每項專案都面臨獨特的挑戰。在 Mail.ru 首頁中找到下列商機：
- 為廣告橫幅導入預留位置，以減少 CLS。
- 使用伺服器端轉譯 (SSR) 減少最大內容繪製 (LCP)。
- 程式碼分割來減少 LCP 和首次輸入延遲時間 (FID)。
改善 CLS 的骷髏
CLS 是 Mail.ru 首頁表現最差的欄位指標之一。之後在 Chrome 開發人員工具的「Performance」(效能) 面板中剖析這個頁面的資料，問題就是出在廣告的原因。為了改善版面配置的穩定性，我們的團隊決定在廣告載入前，使用預留位置預留空間。
導入預留位置時，第一步是判斷要替換預留位置的內容尺寸。幸好，電腦版 Mail.ru 電腦版首頁已經嚴格記錄廣告的大小。與設計團隊討論後，我們使用 SVG 動畫的 UI 骨架做為預留位置，以便減少感知內容的載入時間。
SSR 回歸
為協助從 Fest 轉移至 Svelte，我們改為逐步拓展現有專案，而非從頭開始。截至 2021 年 3 月，我們已將大部分的前端遷移至 Svelte。經過分類及修正後端效能問題後，最後將 SSR 導入了正式版應用程式。
導入 SSR 後，團隊發現最初沒注意到 CLS 迴歸的原因：新聞區段在轉譯網頁的第一個內容時並未插入。伺服器提供的網頁標記初始繪製作業與用戶端新聞版面插入之間發生延遲。這項行為導致廣告骨架改變，導致 CLS 惡化。
雖然 Chrome 開發人員工具顯示了版面配置位移事件，但一開始我們找不到原因。雖然 SSR 本身並不是問題，但有助於我們日後找出解決方案。修正負責繪製延遲的程式碼，改善新聞元件的版面配置穩定性。
SSR 也可能對 CLS 造成的另一個影響，是元件在飲水前後的移動移動，可能會造成進一步的版面配置位移。我們尤其在行動版 YouTube 中遇到這種情況，必須特別注意飲水式元件標記。為解決這個問題，只要可能的話，把 JavaScript 的顯示邏輯都從 JavaScript 轉移到 CSS。
程式碼分割和未使用的 polyfill
為了改善感知的頁面載入速度，您必須設法減少 LCP 和 FID 值。其中一個方法是使用程式碼分割。除了 Mail.ru 首頁本身之外，我們的團隊也在開發用來入口網站導覽的小工具。目前這部影片已嵌入我們公司的許多專案。
基於歷史因素，這個小工具是以同步載入指令碼的形式在網頁最開頭插入。此指令碼中的 polyfill 比重會隨著時間成長。為了減少載入這些 polyfill 造成的負面效能影響，我們針對新版和舊版瀏覽器實作了程式碼分割功能。
我們決定不使用為新版或舊版瀏覽器載入 JavaScript 套件的 module/nomodule 模式，因為 <script> 元素的 type="module" 屬性無法指定符合我們需求的新版瀏覽器。為解決這個問題，Mail.ru 會使用內部工具識別後端上的新瀏覽器版本，並據此調整這些瀏覽器。
只要能在後端成功辨識出瀏覽器，我們就會針對新版和舊版瀏覽器導入程式碼分割功能。結果造成新版瀏覽器同步載入 JavaScript 小工具的大小減少了 43.3%。其他入口網站指令碼也已採用這種做法。
除了縮減大小及對網站體驗核心指標有正面影響外，程式碼分割功能也能夠改善開發人員體驗。只有 3.5% 的使用者使用舊版瀏覽器，而且分享的趨勢不穩定，因此導入程式碼分割功能之後，我們的開發人員就能使用最新的瀏覽器 API，而不必將舊版瀏覽器所需的 polyfill 膨脹加進所有使用者。
結果
經過最佳化調整後，我們在現場資料中觀察到 2021 年 5 月 24 至 30 日當週的平均值：
| 指標群組名稱 | Core Web Vitals | 其他網站體驗指標 | |||||
|---|---|---|---|---|---|---|---|
| 指標名稱 | LCP | FID | CLS | FCP | 待定 | 文字轉語音 | |
| 符合網站體驗核心指標門檻的使用者比重 | good | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| 需求改善 | 18% | 4% | 3% | 34% | 17% | 24% | |
| 差 | 24% | 3% | 4% | 23% | 34% | 25% | |
下方圖表依照「平台」顯示網頁成效指標值的變化，請注意圖表中的兩個重要日期：
- 2021 年 3 月 23 日：發布後，最後一個頁面部分遷移至 Svelte。
- 2021 年 4 月 19 日：針對傳回的 SSR 和版面配置修改的疊代版本，並修改為正確的 CLS 迴歸。
從 5 月 1 日到 5 月 10 日之間的值下降，是因為俄羅斯的 5 月假日。
使用「平台」取得的結果與 Chrome 使用者體驗報告 (CrUX) 中指標值的成長情況一致。
比較初始改善項目前一週的使用者工作階段持續時間，以及推出後一週的比較結果顯示成長了 2.7%。此外，網頁大部分區段的轉換率也顯著增加。具體而言，Mail.ru 電子郵件應用程式的轉換量增加了 11.6%，新聞版面的轉換率增加了 13.5%。
181%
良好 CLS 門檻的佔比升幅
2.7%
平均工作階段持續時間較長
13.5%
新聞版面轉換率增幅
最意想不到的結果，行銷橫幅廣告的點閱率 (CTR) 提高了 17.4% (採用 SSR 和預先載入代碼後，顯示時間大幅縮短了)。
分析網頁上其他部分後，我們發現絕大多數部分的成效都有顯著提升。即使像天氣和 COVID-19 這類不太重要的網頁一樣，轉換率也分別提高了 9.6% 和 9.5%。
結論
要改善表現並不容易，因為相關工作可能會延長。您應定期監控指標的變化趨勢，確保所有新產品功能都不會在 Core Web Vitals 中造成迴歸問題。為此，我們會監控網站體驗核心指標的效能預算變化。
最重要的是，我們強調「網站體驗核心指標」對產品團隊成員的重要性，從經理和設計人員、測試人員和品質確保一應俱全。每位團隊成員都應該瞭解成效指標，並獲得改進。此外，我們也會定期將成效最佳化目標納入業務流程中。唯有所有團隊成員共同努力，才能成功提供優質的使用者體驗。