サイトの速度を落とさずにYouTube動画を埋め込む方法
1つのYouTube iframeが、気づかないうちにCore Web Vitalsを台無しにすることがあります。loading="lazy"を適用しても、その埋め込みは数百キロバイトのJavaScriptを読み込み、複数のネットワーク接続を確立し、メインスレッドの処理時間を奪います。これらはすべて、訪問者が再生ボタンをクリックする前に発生します。メディアを多用するページを公開していて、LCPやINPのスコアが悪化している場合、標準的な埋め込み方法が原因である可能性が高いでしょう。
本記事では、YouTube iframeがなぜ依然としてコストが高いのか、そしてファサードパターン(軽量なプレースホルダーを使用したクリック再生型の動画埋め込み)が、ユーザー体験を犠牲にすることなくこの問題をどのように解決するかを説明します。
重要なポイント
- 標準的なYouTube iframeは数百キロバイトのJavaScriptを読み込み、複数のネットワーク接続を確立するため、ユーザーが動画を再生しない場合でもLCPとINPのスコアに悪影響を与える
- ネイティブの
loading="lazy"は、パフォーマンスコストを排除するのではなく、単に遅延させるだけ - ファサードパターンは、iframeを軽量なプレースホルダー(サムネイル+再生ボタン)に置き換え、ユーザーがクリックした時のみ実際のプレーヤーを読み込む
- トラッキングを減らすために
youtube-nocookie.comを使用し、IFrame APIを使用する際はセキュリティのためにoriginパラメータを指定する - アクセシビリティを考慮する:再生ボタンがキーボードでアクセス可能で、スクリーンリーダー用に適切にラベル付けされていることを確認する
YouTube iframeが依然としてパフォーマンスに悪影響を与える理由
標準的なYouTube iframeをページに配置すると、ブラウザは即座にYouTubeのプレーヤースクリプト、トラッキングコード、および関連リソースの取得を開始します。これは、動画が表示されているかどうか、またはユーザーが視聴する意図があるかどうかに関係なく発生します。
パフォーマンスコストは、2つの重要な指標に現れます:
LCP(Largest Contentful Paint): YouTube iframeは、LCP要素になることが多く、または他のコンテンツのレンダリングを遅延させます。プレーヤーのJavaScriptは、クリティカルレンダリングウィンドウ中に帯域幅と解析時間を奪い合います。
INP(Interaction to Next Paint): YouTubeのスクリプトは、ページ上の他の場所でのユーザーインタラクションへの応答を遅延させる可能性のあるメインスレッドの処理を追加します。動画がファーストビューの下に配置されていても、そのJavaScriptは実行され、応答性に影響を与えます。
LCPやINPがどのように測定されるかについて復習が必要な場合は、GoogleがCore Web Vitalsの一部として文書化しています:https://web.dev/articles/inp & https://web.dev/articles/lcp
loading="lazy"が不十分な理由
iframe上のネイティブ遅延読み込みは、iframeがビューポートに近づくまでネットワークリクエストを遅延させます。しかし、一度トリガーされると、依然として全コストを支払うことになります。すべてのスクリプトが読み込まれ、接続が確立され、メインスレッドの処理が実行されます。ファーストビューにある動画の場合、遅延読み込みは全く効果がありません。ファーストビューの下にある動画の場合、問題を排除するのではなく、単に先延ばしにするだけです。
遅延読み込みiframeアプローチは、原因ではなく症状を治療します。本当の問題は、ユーザーが視聴する意図を示す前に、YouTubeの重いプレーヤーインフラストラクチャを読み込むことです。
ファサードパターン:意図に基づいて読み込む
YouTubeファサードパターンは、iframeを軽量なプレースホルダー(通常はサムネイル画像と再生ボタン)に置き換えます。実際のiframeは、ユーザーがクリックして視聴する真の意図を示した時のみ読み込まれます。
このクリック再生型動画埋め込みアプローチは、劇的な改善をもたらします:
- 初期ページ読み込み: 数百キロバイトのJavaScriptの代わりに、1枚の画像のみを読み込む(適切なサイズ設定で通常20KB未満)
- メインスレッド: インタラクションまでYouTube JavaScriptの実行はゼロ
- ネットワーク接続: YouTubeのサーバーへの先制的な接続なし
このパターンが機能するのは、ほとんどの訪問者が埋め込み動画を視聴しないためです。実際に再生したいユーザーのために完全な機能を保持しながら、一般的なケースを最適化しています。
実装の要点
ファサード実装には3つのコンポーネントが必要です:
- サムネイル画像: YouTubeのサムネイルURL(
https://i.ytimg.com/vi/VIDEO_ID/hqdefault.jpg)を使用するか、独自のインフラストラクチャから最適化されたバージョンを提供 - 再生ボタンオーバーレイ: インタラクティブ性を示すシンプルなCSSスタイルのボタン
- クリックハンドラー: ユーザーのインタラクション時にプレースホルダーを実際のiframeに置き換えるJavaScript
iframe sourceには、youtube.comの代わりにyoutube-nocookie.comを使用してください。このプライバシー重視のYouTube埋め込みは、トラッキングとCookieの動作を減らしますが、すべてのデータ収集を排除するわけではありません。
iframe URLを構築する際は、文書化された埋め込みパラメータに従ってください。一般的に有用なオプションには、autoplay=1(ユーザーが開始した読み込み後すぐに再生を開始)があります。rel=0は関連動画を完全に無効化せず、同じチャンネルの提案を優先するだけになったことに注意してください。
YouTubeは公式ドキュメントで現在のパラメータリストを維持しています:https://developers.google.com/youtube/player_parameters
Discover how at OpenReplay.com.
セキュリティとプライバシーの考慮事項
プログラム制御のためにYouTubeのIFrame APIを使用する場合は、ドメインに一致するoriginパラメータを指定してください。これにより、他のサイトが埋め込みプレーヤーを制御することを防ぎます。
allow属性でiframeの権限を制限してください。妥当なベースライン:
<iframe
src="https://www.youtube-nocookie.com/embed/VIDEO_ID?autoplay=1&origin=https://yourdomain.com"
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
allowfullscreen>
</iframe>
プレーヤーが必要としない権限を付与しないでください。sandbox属性はiframeの機能をさらに制限できますが、フルスクリーン、自動再生、またはIFrame APIなどの機能を壊すことが多いため、十分にテストしてください。
youtube-nocookie.comはトラッキングを減らしますが、埋め込みを完全にプライベートにするわけではないことに注意してください。iframeが読み込まれると、YouTubeは依然として一部のデータを収集します。厳格なプライバシー要件の場合、ファサードパターンの遅延読み込みは追加の保護層を提供します。ユーザーが明示的に視聴を選択するまで、YouTubeにデータが流れることはありません。
考慮すべきトレードオフ
ファサードパターンにはコストがかかります。iframeがその時点で読み込まれる必要があるため、ユーザーは再生ボタンをクリックしてから動画再生が開始されるまでに短い遅延を経験します。リソースヒントを使用してこれを軽減できます。ユーザーの意図が示された後(例えばホバーやフォーカスイベント時)にのみYouTubeのドメインにpreconnectを追加します:
<link rel="preconnect" href="https://www.youtube-nocookie.com">
<link rel="preconnect" href="https://i.ytimg.com">
アクセシビリティには注意が必要です。再生ボタンがキーボードでアクセス可能で、スクリーンリーダー用に適切にラベル付けされていることを確認してください。プレースホルダーは、静的な画像ではなく、インタラクティブな動画要素であることを伝える必要があります。
まとめ
YouTube埋め込みのパフォーマンス問題が持続するのは、デフォルトのアプローチがほとんどのユーザーが恩恵を受けないコストを前払いするためです。ファサードパターンはこの方程式を反転させます:最初は何も支払わず、実際に誰かが視聴したい時のみ完全なプレーヤーを読み込みます。
Core Web Vitalsが重要なメディアを多用するページの場合、クリック再生ファサードの実装は、最も影響力の高い変更の1つです。LCPが改善され、INPは応答性を維持し、動画を望むユーザーは依然としてそれを取得できます。ただし、1回の追加クリックが必要になります。
よくある質問
はい、ファサードパターンはプレイリストで機能します。iframe URLを構築する際は、動画IDと共にlistパラメータを使用してください。プレースホルダーサムネイルは最初の動画を表示でき、再生をクリックすると完全なプレイリストプレーヤーが読み込まれます。ユーザーのインタラクションまですべてのYouTubeリソースを遅延させるため、同じパフォーマンス上の利点が適用されます。
各埋め込みに個別にファサードパターンを適用してください。各動画は独自のプレースホルダーとクリックハンドラーを持ちます。ユーザーが実際にクリックした動画のiframeリソースのみを読み込むため、このアプローチは適切にスケールします。多数の動画があるページの場合、不要な接続オーバーヘッドを避けるために、ホバー時のみpreconnectヒントを追加することを検討してください。
YouTube分析は、iframeが読み込まれて再生が開始された後にのみ、視聴とエンゲージメントを追跡します。ファサードはユーザーのクリックまでiframeの読み込みを遅延させるため、分析は正確なままです。埋め込み動画を実際に視聴するユーザーについて、完全な視聴回数、視聴時間データ、エンゲージメント指標を引き続き取得できます。
はい、プレースホルダーサムネイルとして任意の画像を提供できます。ファイルサイズと形式をより適切に制御するために、独自のサーバーまたはCDNで最適化された画像をホストしてください。視覚的な品質を維持しながら読み込み時間を最小限に抑えるために、適切な寸法のWebPやAVIFなどの最新の形式を使用してください。
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.