打造更優質的網路環境:更快速的 YouTube

個案研究:YouTube 網頁團隊為了改善成效、提高網站體驗核心指標傳遞率及提升主要業務指標所做的調整。

Addy Osmani
Addy Osmani
Sriram Krishnan
Sriram Krishnan

Chrome 團隊經常提到「打造更優質的網路」,但這究竟是什麼意思?網頁體驗應快速無障礙,並在使用者最需要時使用裝置功能Dogfood 測試是 Google 文化的一部分,因此 Chrome 團隊與 YouTube 攜手合作,透過名為「打造更優質的網路」這個全新系列分享您從中學到的經驗。本系列的第一部分將深入探討 YouTube 如何打造更快速的網路體驗。

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

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

巴西、印度、印尼等發展中市場是 YouTube 行動版網站的重要關鍵。由於這些地區的許多使用者使用較慢的裝置,且網路頻寬有限,因此確保快速且順暢的使用體驗是重要的目標。

為了向所有使用者提供多元包容的體驗,YouTube 的目標是透過延遲載入和程式碼現代化來改善網站體驗核心指標等成效指標。

改善 Core Web Vitals

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

FCP 和 LCP 圖表,顯示 YouTube 觀賞頁面通過率和 YouTube 來源。

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

YouTube 行動版的 Lighthouse 報表。
Chrome 將 FCP 的目標值設為 1.8 秒、LCP 為 2.5 秒做為黃金標準。FCP 和 LCP 都清楚顯示為黃色和紅色,分別為 3.5 秒和 8.5 秒。

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

  1. 他們首先發現,只要將影片播放器的 HTML 移至讓影片播放器具互動性的指令碼上方,就能提高成效。實驗室測試顯示,這項調整可將 FCP 和 LCP 從 4.4 秒縮短至 1.1 秒。

  2. 第二個發現是,LCP 只會考量 <video> 元素海報圖片,而不會考量影片串流本身的影格。過去,YouTube 一直是盡可能縮短影片開始播放的時間,因此為了改善 LCP,團隊也開始最佳化海報圖片的傳送速度。他們嘗試使用幾種不同的海報圖片,並挑選在使用者測試中獲得最高分數的圖片。成果的成果,FCP 和 LCP 皆有顯著改善,現場 LCP 也從 4.6 秒縮短為 2.0 秒。

行動版網站觀賞網頁 LCP 實驗,顯示控制組、實驗組 A (圖片縮圖) 和實驗 B (黑色縮圖)
在研究室中,我們發現這項變更推出後,FCP 和 LCP 從 4.4 秒縮短為 1.1 秒。實驗 A:在影片一開始處於暫停狀態的網頁中,使用實際影片縮圖的效果不錯,但在觀賞頁面等自動播放影片的網頁中,使用實際影片縮圖的效果在使用者研究中不佳。也導致活躍使用者人數下滑。實驗 B:在使用者研究中,使用純黑色海報圖片的效果最佳。使用者發現影片一開始的黑色畫面會從純黑色畫面轉換到第一個畫面,但會降低自動播放影片畫質。
黑色縮圖已在 2021 年 7 月正式部署給所有行動網頁使用者,如上方 RUM 分析所示,這項做法顯著改善了 FCP 和 LCP。
2021 年 7 月,我們為所有行動網路使用者部署了黑色縮圖,顯示 FCP 和 LCP 的改進情形如上述 RUM 分析所示。

雖然這些最佳化措施確實改善了 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 團隊,感謝他們對這項工作的貢獻。