より快適なウェブを実現する: 高速な YouTube

YouTube ウェブチームがパフォーマンスの向上、Core Web Vitals の合格率の向上、主要なビジネス指標の向上のために行った変更に関するケーススタディ。

Sriram Krishnan
Sriram Krishnan

Chrome チームはよく「より良いウェブを構築する」と話しますが、これはどういう意味ですか?ウェブ エクスペリエンスは、高速アクセスしやすいものである必要があります。また、ユーザーが最も必要とするときにデバイスの機能を使用する必要があります。ドッグフーディングは Google の文化の一部であるため、Chrome チームは YouTube と提携して、新しいシリーズ「Building a better web」で、これまでに学んだ教訓を共有しています。このシリーズの最初のパートでは、YouTube が高速なウェブ エクスペリエンスを構築した方法について詳しく説明します。

Chrome ユーザー エクスペリエンス レポートのデータが表示された PageSpeed Insights。
モバイルウェブ版 YouTube の動画再生ページが Core Web Vitals のしきい値を満たしている。

YouTube では、パフォーマンスとは、動画やその他のコンテンツ(おすすめやコメントなど)がウェブページに読み込まれる速度を指します。パフォーマンスは、検索、プレーヤーの操作、高評価、共有などのユーザー操作に対する YouTube の応答速度でも測定されます。

ブラジル、インド、インドネシアなどの成長著しい新興市場は、YouTube モバイルウェブにとって重要な市場です。これらの地域の多くのユーザーは、デバイスの速度が遅く、ネットワーク帯域幅が限られているため、高速でシームレスなエクスペリエンスを確保することが重要な目標となります。

YouTube は、すべてのユーザーに包括的なエクスペリエンスを提供するために、遅延読み込みとコードのモダナイゼーションを通じて、Core Web Vitals などのパフォーマンス指標の改善に取り組みました。

Core Web Vitals を改善する

改善の余地を特定するため、YouTube チームは Chrome ユーザー エクスペリエンス レポート(CrUX)を使用して、現場で実際のユーザーがモバイルで動画再生ページと検索結果ページをどのように使用しているかを確認しました。Largest Contentful Paint(LCP)指標が 4 ~ 6 秒になる場合もあり、Core Web Vitals 指標には改善の余地があることに気づきました。これは、2.5 秒の目標よりも大幅に高くなっています。

YouTube 動画再生ページのパス率と YouTube のオリジンを示す FCP と LCP のグラフ。

改善の余地を特定するため、Lighthouse を使用して YouTube の動画再生ページを監査したところ、Lighthouse(lab)スコアが低く、First Contentful Paint(FCP)が 3.5 秒、LCP が 8.5 秒であることがわかりました。

YouTube モバイル向け Lighthouse レポート。
Chrome では、FCP の目標を 1.8 秒、LCP の目標を 2.5 秒と設定しています。FCP と LCP は、それぞれ 3.5 秒と 8.5 秒で黄色と赤色に明確に表示されています。

YouTube チームは FCP と LCP を最適化するために、いくつかのテストを行い、2 つの大きな発見を得ました。

  1. 最初にわかったのは、動画プレーヤーの HTML を、動画プレーヤーをインタラクティブにするスクリプトの上に移動することで、パフォーマンスを改善できることでした。ラボでのテストでは、これにより FCP と LCP の両方を 4.4 秒から 1.1 秒に改善できることが示されました。

  2. 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 月にすべてのモバイルウェブ ユーザー向けに本番環境にデプロイされました。上記の RUM 分析に見られるように、FCP と LCP が大幅に改善されました。

こうした最適化によって LCP は改善されましたが、LCP 指標の現在の定義では、ページの「メイン コンテンツ」が読み込まれたタイミング(LCP の目標)がユーザーの視点から十分に捉えられていないと判断されました。

こうした懸念に対処するため、YouTube チームのメンバーは Chrome チームのメンバーと連携し、ユースケースに対応するために LCP 指標を改善する方法を検討しました。いくつかのオプションの実現可能性と影響を検討した結果、チームは動画要素の最初のフレームのペイント時間を LCP の候補として検討する提案に至りました。

この変更が Chrome に反映されたら、YouTube チームは LCP の最適化に取り組んでまいります。指標の更新により、こうした最適化が実際のユーザー エクスペリエンスに直接的に影響するようになります。

遅延読み込みによるモジュール化

YouTube ページには、プリロードされたモジュールが多数含まれていました。50 を超えるコンポーネントのレンダリング方法を最適化するために、チームは、読み込むモジュールをクライアントに指示するコンポーネントと JS モジュールのマップを作成しました。コンポーネントを遅延読み込みとしてマークすると、JS モジュールは後で読み込まれるため、ページの初回読み込み時間と、クライアントに送信される未使用の JavaScript の量を削減できます。

しかし、遅延読み込みを実装した後、遅延読み込みされたコンポーネントとその依存関係が最適でないタイミングで読み込まれるウォーターフォール効果に気付きました。

この問題を解決するため、チームはビューに必要な最小限のコンポーネント セットを決定し、それらを 1 つのネットワーク リクエストでバッチ処理しました。その結果、ページの速度が向上し、JavaScript の解析時間が短縮され、最終的には初期レンダリング時間が短縮されました。

コンポーネント間の状態管理

YouTube では、特に古いデバイスで、プレーヤーのコントロールが原因でパフォーマンスの問題が発生していました。コード分析の結果、ユーザーが再生速度や進行状況などの機能を制御できるプレーヤーが、時間の経過とともに過剰にコンポーネント化されていることが判明しました。

YouTube プレーヤーとコントロールの可視化
YouTube 動画プレーヤーでは、再生速度の調整、進行状況の確認、セクションのスキップなどが可能です。ユーザーが特定のコントロールをタップしたときに、状態の変化を他のコントロールに伝える必要があります。たとえば、進行状況バーをタップしたときに、再生ヘッドや字幕などのコントロールと共有する必要があります。

各進行状況バーのタップ移動イベントは、2 回の追加のスタイル再計算をトリガーし、ラボでのパフォーマンス テストの実行中に 21.17 ミリ秒かかりました。新しいコントロールが追加されるにつれて、分散制御のパターンが原因で循環依存とメモリリークが発生し、動画再生ページのパフォーマンスに悪影響を及ぼすことが多くなりました。

パフォーマンス タイムラインに表示される 21.17 ミリ秒のイベント。
CPU が 4 倍に遅くなったパフォーマンス実行時の Chrome DevTools。

分散制御による問題を解決するため、チームはプレーヤー UI を更新してすべての更新を同期し、基本的にプレーヤーを 1 つのトップレベル コンポーネントにリファクタリングして、データを子に渡すようにしました。これにより、状態変化に対して 1 つの UI 更新(レンダリング)サイクルのみが確実に行われ、連鎖的な更新が排除されました。新しいプレーヤーの進行状況バーのタップ移動イベントでは、JavaScript の実行中にスタイルの再計算が行われないため、旧プレーヤーの 25% の時間しか必要ありません。

パフォーマンス タイムラインに表示されるイベントの時間の短縮。

このコードのモダナイゼーションにより、古いデバイスでの視聴の読み込み時間の短縮、再生の放棄の減少、致命的でないエラー数の減少など、パフォーマンスも向上しました。

結果と最適化

YouTube がパフォーマンスに投資した結果、動画再生ページの読み込み速度が大幅に向上し、YouTube のモバイル ウェブサイトの URL の 76% が、フィールドでの Core Web Vitals 指標のしきい値を満たすようになりました。PC では、動画再生ページのラボ LCP が約 4.6 秒から 1.6 秒に短縮されました。サイトのインタラクションとレンダリングのパフォーマンス(特に YouTube 動画プレーヤー)は、JavaScript の実行にかかる時間が最大 75% 短縮されました。

過去 1 年間に YouTube ウェブのパフォーマンスが向上したことで、総再生時間や 1 日あたりのアクティブ ユーザー数などのビジネス指標も改善されています。これらの取り組みの成功に基づき、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 チームの皆様に感謝いたします。