打造更優質的網路環境：更快速的 YouTube
bookmark_border 透過集合功能整理內容你可以依據偏好儲存及分類內容。

本案例研究說明 YouTube 網站團隊為改善成效、提高 Core Web Vitals 通過率，以及提升重要業務指標而做出的異動。

Addy Osmani

Sriram Krishnan

Chrome 團隊經常提到「打造更優質的網路」，但這究竟是什麼意思？網頁體驗應具備快速、無障礙的特性，並在使用者最需要時使用裝置功能。Dogfooding 是 Google 文化的一部分，因此 Chrome 團隊與 YouTube 合作，在名為「打造更優質的網路」的新系列影片中分享一路走來所學到的經驗。本系列的第一部分將深入探討 YouTube 如何打造更快速的網路體驗。

PageSpeed Insights 顯示 Chrome 使用者體驗報告資料。 — YouTube 行動版網頁的觀賞頁面通過網站使用體驗核心指標門檻。

在 YouTube 中，效能是指影片和其他內容 (例如推薦內容和留言) 在網頁上載入的速度。我們也會評估 YouTube 回應使用者互動行為的速度，例如搜尋、播放器控制、按讚和分享。

巴西、印度和印尼等新興市場的使用者人數持續成長，對 YouTube 行動版網頁來說十分重要。由於這些地區的許多使用者使用較慢的裝置，且網路頻寬有限，因此確保快速且順暢的使用體驗是重要的目標。

為提供全方位體驗給所有使用者，YouTube 著手透過延遲載入和程式碼現代化，改善網站體驗核心指標等效能指標。

改善 Core Web Vitals

為找出可改善之處，YouTube 團隊使用 Chrome 使用者體驗報告 (CrUX)，瞭解實際使用者在實地使用行動裝置觀看影片和搜尋結果頁面的體驗。他們發現網站體驗核心指標有許多進步空間，因為最大內容繪製 (LCP) 指標在某些情況下會耗時 4 到 6 秒。這遠高於 2.5 秒的目標。

第一影格完成時間和 LCP 圖表，顯示 YouTube 觀賞頁面的通過率，以及 YouTube 來源。

為了找出可改善的部分，他們使用 Lighthouse 檢查 YouTube 觀賞頁面，結果顯示 Lighthouse (lab) 得分偏低，首次顯示內容所需時間 (FCP) 為 3.5 秒，最大內容繪製 (LCP) 為 8.5 秒。

YouTube 行動版的 Lighthouse 報表。 — Chrome 將 FCP 的目標設為 1.8 秒，LCL 的目標設為 2.5 秒，做為黃金標準。FCP 和 LCP 分別在 3.5 秒和 8.5 秒時，明顯呈現黃色和紅色。

為了改善 FCP 和 LCP，YouTube 團隊進行了多項實驗，並發現了兩個重大發現。

他們首先發現，只要將影片播放器的 HTML 移至讓影片播放器具互動性的指令碼上方，就能提升成效。實驗室測試顯示，這項調整可將 FCP 和 LCP 從 4.4 秒縮短至 1.1 秒。
第二個發現是，LCP 只會考量 <video> 元素海報圖片，而不會考量影片串流本身的影格。YouTube 一向會盡快讓影片開始播放，因此為了改善 LCP，團隊也開始最佳化海報圖片的載入速度。他們嘗試使用幾種不同的海報圖片，並挑選在使用者測試中獲得最高分數的圖片。這項工作帶來的成果是，FCP 和 LCP 都大幅改善，其中實地 LCP 從 4.6 秒縮短到 2.0 秒。

行動版網站的 Watch 網頁 LCP 實驗，顯示對照組、實驗 A (圖片縮圖) 和實驗 B (黑色縮圖) — 在實驗室中，我們發現在實施這項變更後，FCP 和 LCP 的時間從 4.4 秒縮短至 1.1 秒。實驗 A：在影片一開始處於暫停狀態的網頁中，使用實際影片縮圖的效果不錯，但在觀賞頁面等自動播放影片的網頁中，使用實際影片縮圖的效果在使用者研究中不佳。也導致活躍使用者人數下滑。實驗 B：在使用者研究中，使用純黑色海報圖片的效果最佳。使用者認為，從純黑色轉換至影片第一個畫面的過場效果，可為自動播放影片帶來較不突兀的體驗。

黑色縮圖已在 2021 年 7 月正式部署給所有行動網頁使用者，如上方 RUM 分析所示，這項做法顯著改善了 FCP 和 LCP。 — 2021 年 7 月，我們為所有行動網站使用者在正式環境中部署黑色縮圖，如上方 RUM 分析所示，FCP 和 LCP 明顯改善。

注意： 除了在所有平台上實施這些最佳化調整，YouTube 也善用新的 fetchpriority 屬性，並與 <link rel=preload> 搭配使用，以便優先發現並提早載入海報圖片：

<link as="image" rel="preload" href="poster.jpg" fetchpriority="high">

雖然這些最佳化調整確實改善了 LCP，但團隊認為，從使用者角度來看，目前的 LCP 指標定義並未完全捕捉到網頁「主要內容」載入的時間，而這正是 LCP 的目標。

為解決這些疑慮，YouTube 團隊成員與 Chrome 團隊成員合作，探索改善 LCP 指標以因應使用情境的方法。在考量幾個選項的可行性和影響後，團隊決定提出提案，將影片元素第一個影格的顯示時間列為 LCP 候選項目。

這項變更在 Chrome 上線後，YouTube 團隊將繼續致力於改善 LCP。更新後的指標將可讓這些最佳化調整對實際使用者體驗產生更直接的影響。

使用延遲載入的模組化

YouTube 網頁包含許多預先載入的模組。為最佳化 50 多個元件的算繪方式，團隊建構了元件至 JS 模組對應，可告知用戶端要載入哪些模組。將元件標示為延遲載入後，JS 模組會稍後載入，進而縮短網頁的初始載入時間，並減少傳送至用戶端的未使用 Javascript 數量。

不過，在實作延遲載入功能後，團隊發現延遲載入元件及其相依項目的瀑布效果，會在非最佳時間載入。

為瞭解決這個問題，團隊決定在檢視畫面中需要的元件最少組合，並在單一網路要求中批次處理這些元件。結果是網頁速度提升、JavaScript 剖析時間縮短，最終初始轉譯時間也縮短。

跨元件狀態管理

YouTube 的播放器控制項會導致效能問題，尤其是在舊型裝置上。程式碼分析顯示，允許使用者控制播放速度和進度等功能的播放器，隨著時間推移而變得過度元件化。

可視化 YouTube 播放器和控制項 — 使用者可透過 YouTube 影片播放器控制播放速度、追蹤進度、略過部分內容等。使用者輕觸特定控制項時，狀態變更必須傳達至其他控制項，例如使用者輕觸進度列時，必須將該狀態傳達至播放頭、字幕等控制項。

每個進度列觸控移動事件都會觸發兩次額外的樣式重新計算作業，並在實驗室的效能測試中耗費 21.17 毫秒。隨著新控制項的加入，分散式控制模式經常會導致循環依附和記憶體流失，進而影響觀看頁面成效。

效能時間軸上顯示的 21.17 毫秒事件。 — Chrome 開發人員工具，CPU 效能執行速度減慢 4 倍。

為修正因去中心化控制所造成的問題，團隊更新了播放器 UI，以便同步處理所有更新，基本上將播放器重構為一個可將資料傳遞至子項的頂層元件。這可確保任何狀態變更只會產生一個 UI 更新 (算繪) 週期，並消除鏈結更新。新的播放器進度列觸控移動事件在 JavaScript 執行期間不會重新計算樣式，現在只需要舊播放器的 25% 時間。

在效能時間軸上顯示的事件時間縮短。

這項程式碼現代化作業也帶來其他效能改善，例如改善舊裝置的觀看載入時間、減少中斷的播放次數，以及減少非致命錯誤的數量。

成效和最佳化

在 YouTube 持續投入改善效能後，觀看頁面的載入速度大幅提升，目前有 76% 的 YouTube 行動網站網址已達到 Core Web Vitals 指標門檻。在電腦上，觀看頁面的實驗室 LCP 從約 4.6 秒縮短至 1.6 秒。網站的互動和算繪效能 (尤其是 YouTube 影片播放器) 的 JavaScript 執行時間，最多可縮短 75%。

過去一年，YouTube 網頁版的效能提升也改善了業務指標，包括觀看時間和每日活躍使用者。基於這些努力的成功，我們日後將持續探索更多最佳化方式。

特別感謝 Gilberto Cocchi、Lauren Usui、Benji Bear、Bo Aye、Bogdan Balas、Kenny Tran、Matthew Smith、Phil Harnish、Leena Sahoni、Jeremy Wagner、Philip Walton、Harleen Batra 和 YouTube 與 Chrome 團隊，感謝他們對這項工作的貢獻。