打造更優質的網路環境 - 第 1 部分:提升 YouTube 網站速度

個案研究:YouTube 網站團隊為改善成效、提升網站體驗核心指標通過率,以及提升關鍵業務指標所做的調整。

Addy Osmani
Addy Osmani
Sriram Krishnan
Sriram Krishnan

Chrome 團隊常談到「打造更棒的網路環境」,但這是什麼意思?讓使用者在最需要的時候,能夠快速存取及使用裝置功能Dogfood 測試是 Google 文化的一部分,因此 Chrome 團隊與 YouTube 攜手合作,在名為「打造更優質的網路環境」的新系列中,分享在過程中學到的經驗。本系列文章第一部分將深入探討 YouTube 如何打造更快的網路服務。

PageSpeed Insights 會根據網站體驗核心指標,顯示 YouTube 行動版網站的 Chrome 使用者體驗報告資料。
YouTube 行動版網站觀賞頁面符合網站體驗核心指標的門檻。

打造更快的網路環境

YouTube 的「效能」是關於影片和其他內容 (例如推薦影片和留言) 在網頁上的載入速度。效能的評估依據為 YouTube 回應使用者互動 (例如搜尋、播放器控制、喜歡和分享) 的速度。

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

為了讓所有使用者都能享有多元包容的體驗,YouTube 致力於透過延遲載入和程式碼現代化來提升效能指標,例如網站體驗核心指標

改善網站體驗核心指標

YouTube 團隊利用 Chrome 使用者體驗報告 (CrUX),瞭解使用者在行動裝置上觀看影片及搜尋結果網頁時,如何實際體驗哪些部分需要改善。他們發現,網站體驗核心指標指標有很多改善空間,在某些情況下,最大內容繪製 (LCP) 指標會在 4 至 6 秒內進行時鐘。這比他們的 2.5 秒目標還高

FCP 和 LCP 的圖表顯示 YouTube 觀賞頁面略過率及 YouTube 來源。

為找出需要改善的部分,他們決定使用 Lighthouse 稽核 YouTube 觀賞頁面,結果發現低 Lighthouse (研究室) 分數、首次顯示內容所需時間 (FCP) 為 3.5 秒,LCP 則為 8.5 秒。

YouTube 行動版 Lighthouse 報告。
Chrome 將 FCP 和 LCP 分別設定為 1.8 秒和 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 實驗 B (黑色縮圖)
在研究室中,我們發現這項異動落後後,FCP 和 LCP 已從 4.4 秒提高至 1.1 秒。實驗 A:在影片暫停後的網頁上,使用實際影片縮圖的效果不錯,但在使用者研究中成效不佳的觀賞頁面等自動播放影片頁面。此外,活躍使用者人數也減少。實驗 B:使用純黑色的海報圖片,在使用者研究中呈現最佳效果。使用者發現從純黑色到影片第一個影格的轉場,對自動播放影片體驗造成較不舒服的體驗。
黑色縮圖已部署於 2021 年 7 月,供所有行動網路使用者使用,其中顯示 FCP 和 LCP 顯著改善,如上述 RUM 分析所示。
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 行動版網站網址現在達到了網站體驗核心指標門檻的門檻,因此觀賞頁面的載入速度更快了。在電腦上,觀賞頁面的研究室 LCP 已從約 4.6 秒縮減為 1.6 秒。網站的互動和顯示效能 (尤其是 YouTube 影片播放器) 發現 JavaScript 執行時間比以往少 75%。

過去一年來 YouTube 網頁成效提升,也連帶改善了業務指標,包括觀看時間和每日活躍使用人數。基於上述種種努力的成果,我們計劃在未來繼續探索更多方式,讓廣告活動更加完善。

在「打造無障礙網路」系列的第二部影片中,您將瞭解 YouTube 如何讓螢幕閱讀器使用者更容易存取他們的網站。

特別感謝 Gilberto Cocchi、Lauren Usui、Benji Bear、Bo Aye、Bogdan Balas、Kenny Tran、Matthew Smith、Phil Harnish、Lena Sahoni、Jeremy Wagner、Philip Walton、Harleen Batra,以及 YouTube 和 Chrome 團隊。