YouTube ウェブチームがパフォーマンスの向上、Core Web Vitals の合格率の向上、主要なビジネス指標の向上のために行った変更に関するケーススタディ。
Chrome チームはよく「より良いウェブを構築する」と話しますが、これはどういう意味ですか？ウェブ エクスペリエンスは、高速でアクセスしやすいものである必要があります。また、ユーザーが最も必要とするときにデバイスの機能を使用する必要があります。ドッグフーディングは Google の文化の一部であるため、Chrome チームは YouTube と提携して、新しいシリーズ「Building a better web」で、これまでに学んだ教訓を共有しています。このシリーズの最初のパートでは、YouTube が高速なウェブ エクスペリエンスを構築した方法について詳しく説明します。
YouTube では、パフォーマンスとは、動画やその他のコンテンツ（おすすめやコメントなど）がウェブページに読み込まれる速度を指します。パフォーマンスは、検索、プレーヤーの操作、高評価、共有などのユーザー操作に対する YouTube の応答速度でも測定されます。
ブラジル、インド、インドネシアなどの成長著しい新興市場は、YouTube モバイルウェブにとって重要な市場です。これらの地域の多くのユーザーは、デバイスの速度が遅く、ネットワーク帯域幅が限られているため、高速でシームレスなエクスペリエンスを確保することが重要な目標となります。
すべてのユーザーに包括的なエクスペリエンスを提供するため、YouTube は、遅延読み込みとコードのモダナイゼーションを通じて、Core Web Vitals などのパフォーマンス指標の改善に取り組みました。
Core Web Vitals を改善する
改善の余地を特定するため、YouTube チームは Chrome ユーザー エクスペリエンス レポート（CrUX）を使用して、現場で実際のユーザーがモバイルで動画再生ページと検索結果ページをどのように使用しているかを確認しました。Largest Contentful Paint（LCP）指標が 4 ～ 6 秒になる場合もあり、Core Web Vitals 指標には改善の余地があることに気づきました。これは、2.5 秒の目標よりも大幅に高い値でした。
改善の余地を特定するため、Lighthouse を使用して YouTube の動画再生ページを監査したところ、Lighthouse（lab）スコアが低く、First Contentful Paint（FCP）が 3.5 秒、LCP が 8.5 秒であることがわかりました。
YouTube チームは FCP と LCP を最適化するために、いくつかのテストを行い、2 つの大きな発見を得ました。
最初にわかったのは、動画プレーヤーの HTML を、動画プレーヤーをインタラクティブにするスクリプトの上に移動することで、パフォーマンスを改善できることでした。ラボでのテストでは、これにより FCP と LCP の両方を 4.4 秒から 1.1 秒に改善できることが示されました。
2 つ目の発見は、LCP が動画ストリーム自体のフレームではなく、
<video>要素のポスター画像のみを考慮することです。YouTube では従来、動画の再生開始までの時間を最短にするよう最適化してきましたが、LCP を改善するため、ポスター画像を配信するまでの時間を最短にするよう最適化も開始しました。ポスター画像をいくつか試し、ユーザー テストで最も高い評価を得た画像を選択しました。この取り組みの結果、FCP と LCP の両方で大幅な改善が見られました。フィールドでの LCP は 4.6 秒から 2.0 秒に短縮されました。
こうした最適化によって LCP は改善されましたが、LCP 指標の現在の定義では、ページの「メイン コンテンツ」が読み込まれたタイミング（LCP の目標）がユーザーの視点から十分に捉えられていないと判断されました。
これらの懸念に対処するため、YouTube チームのメンバーは Chrome チームのメンバーと連携し、ユースケースに対応するために LCP 指標を改善する方法を検討しました。いくつかのオプションの実現可能性と影響を検討した結果、チームは動画要素の最初のフレームのペイント時間を LCP の候補として検討する提案に至りました。
この変更が Chrome に反映されたら、YouTube チームは LCP の最適化に取り組んでまいります。指標の更新により、こうした最適化が実際のユーザー エクスペリエンスに直接的に影響するようになります。
遅延読み込みによるモジュール化
YouTube ページには、プリロードされたモジュールが多数含まれていました。50 を超えるコンポーネントのレンダリング方法を最適化するために、チームは、どのモジュールを読み込むかをクライアントに指示するコンポーネントと JS モジュールのマップを作成しました。コンポーネントを遅延読み込みとしてマークすると、JS モジュールは後で読み込まれるため、ページの初回読み込み時間と、クライアントに送信される未使用の JavaScript の量を削減できます。
しかし、遅延読み込みを実装した後、遅延読み込みされたコンポーネントとその依存関係が最適でないタイミングで読み込まれるウォーターフォール効果に気付きました。
この問題を解決するため、チームはビューに必要な最小限のコンポーネント セットを決定し、それらを 1 つのネットワーク リクエストでバッチ処理しました。その結果、ページ速度が向上し、JavaScript の解析時間が短縮され、最終的には初期レンダリング時間が短縮されました。
コンポーネント間の状態管理
YouTube では、プレーヤーのコントロールが原因でパフォーマンスの問題が発生していました（特に古いデバイスで発生していました）。コード分析の結果、ユーザーが再生速度や進行状況などの機能を制御できるプレーヤーが、時間の経過とともに過剰にコンポーネント化されていることが判明しました。
各進行状況バーのタップ移動イベントは、2 回の追加のスタイル再計算をトリガーし、ラボでパフォーマンス テストを実行したときに 21.17 ms かかりました。新しいコントロールが追加されるにつれて、分散制御のパターンが原因で循環依存とメモリリークが発生し、動画再生ページのパフォーマンスに悪影響を及ぼすことが多くなりました。
分散制御による問題を解決するため、チームはプレーヤー UI を更新してすべての更新を同期し、基本的にプレーヤーを 1 つのトップレベル コンポーネントにリファクタリングして、データを子に渡すようにしました。これにより、状態変化に対して 1 つの UI 更新（レンダリング）サイクルのみが確実に行われ、連鎖的な更新が排除されました。新しいプレーヤーの進行状況バーのタップ移動イベントでは、JavaScript の実行中にスタイルの再計算が行われないため、旧プレーヤーの 25% の時間しか必要ありません。
このコードのモダナイゼーションにより、古いデバイスでの視聴の読み込み時間の短縮、再生の放棄の減少、致命的でないエラー数の減少など、パフォーマンスがさらに向上しました。
結果と最適化
YouTube がパフォーマンスに投資した結果、動画再生ページの読み込み速度が大幅に向上し、YouTube のモバイル ウェブサイトの URL の 76% が、フィールドでの Core Web Vitals 指標のしきい値を満たすようになりました。パソコンでは、動画再生ページのラボ LCP が約 4.6 秒から 1.6 秒に短縮されました。サイトのインタラクションとレンダリングのパフォーマンス（特に YouTube 動画プレーヤー）は、JavaScript の実行にかかる時間が最大 75% 短縮されました。
過去 1 年間に YouTube ウェブのパフォーマンスが向上したことで、総再生時間や 1 日あたりのアクティブ ユーザー数などのビジネス指標も向上しました。これらの取り組みの成功に基づき、今後も最適化方法をさらに模索していく予定です。
この作業にご協力いただいた 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 チームの皆様に感謝いたします。