YouTube ウェブチームがパフォーマンスの向上、Core Web Vitals の合格率の向上、主要なビジネス指標の向上のために行った変更に関するケーススタディ。
Chrome チームは「より優れたウェブの構築」についてよく語りますが、これは何を意味するのでしょうか。ウェブ エクスペリエンスは高速でアクセス可能であること、ユーザーが最も必要とするときにデバイス機能を使用できる必要があります。dogfood は Google の文化の一部であるため、Chrome チームは YouTube と提携し、その過程で学んだ教訓を新しいシリーズ「より優れたウェブの構築」で共有しています。このシリーズの最初のパートでは、YouTube が高速なウェブ エクスペリエンスを構築した方法について詳しく説明します。
YouTube では、パフォーマンスとは、動画やその他のコンテンツ（おすすめやコメントなど）がウェブページに読み込まれる速度を指します。パフォーマンスは、検索、プレーヤーの操作、高評価、共有などのユーザー操作に対する YouTube の応答速度でも測定されます。
ブラジル、インド、インドネシアなどの成長著しい新興市場は、YouTube モバイルウェブにとって重要な市場です。これらの地域の多くのユーザーは、デバイスの速度が遅く、ネットワーク帯域幅が限られているため、高速でシームレスなエクスペリエンスを確保することが重要な目標となります。
YouTube は、すべてのユーザーに包括的なエクスペリエンスを提供するために、遅延読み込みとコードのモダナイゼーションを通じて、ウェブに関する主な指標などのパフォーマンス指標の改善に取り組みました。
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 を改善するため、ポスター画像を配信するまでの時間の最適化も開始しました。ポスター画像のバリエーションをいくつか試して、ユーザーテストで最高スコアが得られたものを 1 つ選びました。この作業の結果、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 ミリ秒かかりました。新しいコントロールが追加されるにつれて、分散制御のパターンが原因で循環依存とメモリリークが発生し、動画再生ページのパフォーマンスに悪影響を及ぼすことが多くなりました。
分散制御による問題を解決するため、チームはプレーヤー 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 日あたりのアクティブ ユーザー数などのビジネス指標も向上しました。これらの取り組みの成功に基づき、今後も最適化のさらなる方法を模索していく予定です。
この作業にご協力いただいた 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 チームの皆様に感謝いたします。