パフォーマンスを改善し、Core Web Vitals の合格率を高め、主要なビジネス指標を向上させるために、YouTube ウェブチームが行った変更の事例紹介。
Chrome チームは「より優れたウェブの構築」とよく言っていますが、これはどういう意味でしょうか？ウェブ エクスペリエンスは高速で、アクセスしやすく、ユーザーが最も必要としている瞬間にデバイス機能を使用できる必要があります。dogfood は Google の文化の一部です。そこで Chrome チームは YouTube と提携し、その過程で得た教訓を「より良いウェブの構築」という新しいシリーズで共有しました。シリーズの第 1 部では、YouTube がどのようにして高速なウェブ体験を構築したかを掘り下げます。
より高速なウェブの構築
YouTube では、パフォーマンスとは、動画や他のコンテンツ（おすすめやコメントなど）がウェブページに読み込まれる速度に関係しています。また、検索、プレーヤーの操作、高評価、共有などのユーザー操作に YouTube が応答する速度によっても測定されます。
ブラジル、インド、インドネシアなど、成長中の市場は YouTube モバイルウェブにとって重要です。これらのリージョンでは多くのユーザーのデバイスが遅く、ネットワーク帯域幅が限られているため、高速でシームレスなエクスペリエンスを実現することが重要な目標です。
すべてのユーザーにインクルーシブなエクスペリエンスを提供するため、YouTube は遅延読み込みとコードのモダナイゼーションを通じて、Core Web Vitals などのパフォーマンス指標の改善に着手しました。
Core Web Vitals の改善
改善の余地がある領域を特定するため、YouTube チームは Chrome ユーザー エクスペリエンス レポート（CrUX）を使用して、モバイルの動画再生ページと検索結果ページが現場で実際にユーザーにどのように利用されているかを調べました。Core Web Vitals の指標には多くの改善の余地があることに気づきました。Largest Contentful Paint（LCP）指標は 4 ～ 6 秒で記録されるケースがありました。これは、目標の 2.5 秒よりも大幅に長くなりました。
改善の余地がある領域を特定するため、Lighthouse を使用して YouTube の動画再生ページを監査したところ、First Contentful Paint（FCP）は 3.5 秒、LCP は 8.5 秒と低い Lighthouse（ラボ）スコアが得られました。
FCP と LCP を最適化するために、YouTube チームはいくつかの実験を行い、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 モジュールにマッピングしました。コンポーネントを Lazy としてマークすると、JS モジュールが後で読み込まれるようになり、ページの初回読み込み時間と、クライアントに送信される未使用の JavaScript の量が削減されます。
しかし、遅延読み込みの実装後、遅延読み込みのコンポーネントとその依存関係が最適でないタイミングで読み込まれるウォーターフォール効果に気づきました。
この問題を解決するために、チームはビューに必要な最小限のコンポーネント セットを決定し、1 つのネットワーク リクエストにバッチ処理しました。その結果、ページ速度が向上し、JavaScript の解析時間が短縮され、ひいては初期レンダリング時間も短縮されました。
コンポーネント間の状態管理
特に古いデバイスで、YouTube のプレーヤー コントロールが原因でパフォーマンスの問題が発生していました。コード分析により、再生速度や進行状況などの機能をユーザーが制御できるプレーヤーが、時間の経過とともに過度にコンポーネント化されていることがわかりました。
進行状況バーのタップ移動イベントごとにスタイルの追加再計算が 2 回トリガーされ、ラボでのパフォーマンス テスト実行中に 21.17 ミリ秒かかりました。時間の経過とともに新しいコントロールが追加されるにつれて、分散コントロールのパターンは循環依存関係とメモリリークを引き起こし、動画再生ページのパフォーマンスに悪影響を及ぼしていました。
制御の分散による問題を解決するために、チームはすべての更新を同期するようにプレーヤー UI を更新しました。つまり、基本的には、子にデータを渡す 1 つのトップレベル コンポーネントにプレーヤーをリファクタリングしました。これにより、状態変化に対して UI 更新（レンダリング）サイクルが 1 つだけになり、更新の連鎖が不要になりました。新しいプレーヤーの進行状況バーのタッチ移動イベントでは、JavaScript の実行中にスタイルの再計算は行われず、古いプレーヤーの 25% の時間のみが必要になりました。
また、このコードのモダナイゼーションにより、古いデバイスでのスマートウォッチの読み込み時間の改善、放棄された再生の減少、致命的でないエラーの減少など、さらなるパフォーマンスの向上も実現しました。
おわりに
YouTube がパフォーマンスに投資した結果、動画再生ページの読み込み速度が大幅に向上し、現在、YouTube のモバイルサイトの URL の 76% が Core Web Vitals の指標のしきい値を満たしています。パソコンでは、動画再生ページのラボ LCP が約 4.6 秒から 1.6 秒に短縮されました。サイトの操作とレンダリングのパフォーマンス、特に YouTube 動画プレーヤーでは、JavaScript の実行時間が以前と比べて最大 75% 短縮されています。
この 1 年間で YouTube ウェブのパフォーマンスが向上したことで、総再生時間や 1 日のアクティブ ユーザー数などのビジネス指標も改善されました。こうした取り組みの成果を踏まえ、今後もさらなる最適化の方法を探っていきたいと考えています。
このシリーズのパート 2「アクセシビリティの高いウェブの構築」では、スクリーン リーダーのユーザーがウェブサイトをより利用しやすくするために、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 チームの両方に深く感謝します。