Hi，大家好我是 ssh，今天和大家分享一篇文章，講述了 Chrome 團隊和 Youtube 共同配合，優化了油管這個不存在的視頻網站的性能。

• 首屏速度更快了
• 播放器組件大幅度優化
• 通過 Core Web Vitals 指標的頁面比例更高

從這篇分享 Building a Better Web - Part 1: A faster YouTube on web[1]中，你能學習到世界上頂尖的團隊是如何相互配合，優化世界各地用戶的性能體驗。

Chrome 團隊經常談到“建設更棒的 Web”，這啥意思呢？Web 體驗應該快速[2]、可訪問[3]，并在用戶最需要的時候具備網絡可靠性[4]。

吃自己的狗食（Eating Your Own Dog Food）[5]是谷歌文化的一部分，所以 Chrome 團隊與 YouTube 合作，在“建設更棒的 Web”的新系列中分享了在這個過程中學到的經驗教訓。這個系列的第一部分將深入探討 YouTube 如何建立更迅捷的 Web 體驗。

圖片

PageSpeed Insights顯示YouTube移動網頁的Chrome用戶體驗報告數據通過了核心Web體驗度量標準。

YouTube 移動觀看頁順利超過Core Web Vitals[6]設立的閾值。

建設更快的 Web

對于 YouTube 來說，性能和網頁上視頻和其他內容(如推薦和評論)的加載速度有關。性能也由 YouTube 響應用戶交互(如搜索、播放器控制、點贊和分享)的速度決定。

巴西、印度和印度尼西亞等發展中市場對 YouTube 移動網頁很重要。由于這些地區的許多用戶設備和網速都比較拉跨，確保快速流暢的體驗就很關鍵了。

為了向所有用戶提供良好的體驗，YouTube 著手通過懶加載和代碼現代化來改進Core Web Vitals[7]等性能指標。

改進 Core Web Vitals

為了判斷需要改進哪些領域，YouTube 團隊使用Chrome 用戶體驗報告(CrUX)[8]來查看移動端實際的用戶在視頻觀看頁面和搜索結果頁面的體驗，得知了他們的 Core Web Vitals 有很大的改進空間，在某些情況下，最大內容渲染時間(LCP)[9]指標達到 4-6 秒。這遠高于他們 2.5 秒的目標。

圖片

顯示YouTube觀看頁面通過率以及YouTube源FCP和LCP圖表

為了確定改進的細節，他們用Lighthouse[10]來審查 YouTube 觀看頁面，果然得到了一個較低的 Lighthouse(實驗室[11])分數，首次內容渲染時間（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 代碼移動到視頻播放相關的 JS 腳本之上，可以提高性能。實驗室測試（Labs test）表明，這可以將 FCP 和 LCP 從 4.4 秒改善到 1.1 秒。
2. 第二個發現是 LCP 只考慮[12]<video>元素的海報圖，而不考慮視頻流本身的幀。YouTube 一直在優化視頻開始播放的最快時間，為了改進 LCP，團隊開始優化他們可以交付海報圖的速度。他們嘗試了幾種海報圖的變體，并選擇了在用戶測試中得分最高的一種。作為這項工作的結果，FCP 和 LCP 都取得了顯著改進，實際場景中的 LCP 從 4.6 秒提高到 2.0 秒。

圖片

控制組、實驗A(縮略圖)和實驗B(黑色縮略圖)的移動網頁觀看頁面LCP實驗

在實驗測試中，我們觀察到這個更改落地后，FCP 和 LCP 從 4.4 秒提升到 1.1 秒。

• 實驗 A：用實際的視頻暫停截圖作為海報圖，用戶表現不佳，導致用戶活躍下降。
• 實驗 B：使用實心黑色縮略圖作為海報，結果很好，用戶發現從實心黑色過渡到視頻的第一幀，體驗是很平穩的。

圖片

2021年7月，黑色縮略圖的方案部署成功，如上面的RUM分析所示，FCP和LCP有顯著改進。

2021 年 7 月，黑色縮略圖的方案部署成功，如上面的 RUM 分析所示，FCP 和 LCP 有顯著改進。

在將這些優化引入所有平臺的同時，YouTube 還利用了新的`fetchpriority`屬性[13]，我們將它與<link rel=preload>一起使用，以優先發現和加載海報圖：

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

雖然這些優化確實改進了 LCP，但團隊覺得 LCP 指標的當前定義并沒有完全捕獲用戶視角中的“主要內容”何時加載——這是 LCP 的目標。

為了解決這些問題，YouTube 團隊的成員與 Chrome 團隊的成員合作，探索改進 LCP 指標的方式，以解決他們的用例。在考慮了幾個選項的可行性和影響后，兩支團隊得出的建議[14]是將視頻元素的第一幀的繪制時間視為 LCP 候選項。

一旦這個變化在 Chrome 中落地，YouTube 團隊就能開心的繼續優化 LCP 了。這個指標更加接近用戶真實的體驗。

模塊化與懶加載

YouTube 頁面包含許多直接加載的模塊。為了優化 50 多個組件的渲染方式，團隊建立了一個組件到 JS 模塊的 map，這個 map 將告訴客戶端加載哪些模塊。通過將組件標記為懶加載，JS 模塊會晚一些加載，從而減少頁面的初始加載時間和未使用 Javascript 的數量。

然而，在實現懶加載后，團隊注意到懶加載的組件及其依賴項會在次優級時間批量加載。

為了解決這個問題，團隊確定了視圖中所需的最小組件集，并將它們打包在一個 Web 請求中。結果是頁面速度得到改善，JavaScript 解析時間減少，最終得到了更好的初始渲染時間。

跨組件狀態管理

YouTube 由于其播放器控件而遇到性能問題，特別是在較舊的設備上。代碼分析顯示，播放器(允許用戶控制播放速度、進度等功能)隨著時間的推移變得過度組件化了。

YouTube播放器和控件可視化

YouTube 視頻播放器允許用戶控制播放速度、跟蹤進度、跳過部分等。當用戶點擊特定控件時，狀態變化必須傳達給其他控件，例如，用戶點擊進度條必須與播放頭部、字幕等控件共享。

實驗性能測試運行中，每次觸摸移動進度條事件會額外觸發兩次樣式重繪，花費 21.17 毫秒。隨著時間推移添加新控件，去中心化控制的模式通常會導致循環依賴和內存泄漏，對觀看頁面性能產生負面影響。

性能時間軸上顯示這個事件花了21.17毫秒

Chrome 開發者工具以 4 倍 CPU 減速運行性能。

為了解決去中心化控制帶來的問題，團隊更新了播放器 UI 來同步所有更新，實際上是把播放器重構成一個頂層組件，它會向子組件傳遞數據。這確保任何狀態更改只有一次 UI 更新(渲染)周期，消除了鏈式更新。新的播放器進度條觸摸移動事件，在其 JavaScript 執行期間不會帶來樣式重繪，現在只需要花費舊播放器 1/4 的時間。

圖片

性能時間軸上顯示減少的事件時間。

這種代碼現代化還帶來了其他性能改進，如老式設備上的觀看加載時間改善、更少的棄播率、更少的 Bug 數量。

總結

通過 YouTube 對性能的投入，觀看頁面加載得更快了，現在 YouTube 移動網站中的 76% 的 URL 可以在實際場景中通過 Core Web Vitals 的閾值。在桌面端，觀看頁面的實驗室 LCP 從約 4.6 秒減少到 1.6 秒。特別是 YouTube 視頻播放器的交互和渲染性能，與以前相比 JavaScript 執行時間減少了高達 75%。

成功:

YouTube 移動網頁的 76% URL 現在可以通過 Core Web Vitals，觀看時間等業務指標也得到了改進。

過去一年 YouTube 網頁性能的改進也提高了業務指標，包括觀看時間和日活躍用戶。基于這些工作的成功，我們計劃在未來繼續探索更多優化方法。

在該系列的第二部分“建設一個可訪問的 Web”中，你將了解 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 團隊對這項工作的貢獻。