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