動画を軽く埋め込む方法は、ページを開いた瞬間にプレーヤーを読み込ませず、再生ボタンが押されてから読み込む「ファサード方式」に切り替えることです。第三者による実測では、YouTubeの標準埋め込み1本あたり約1,243KBだった転送量が、ファサード方式では約27KBまで下がっています。標準の埋め込みコードは、訪問者が再生しなくてもプレーヤー一式を先に読み込むためです。この記事では、貼り替えるだけで効く最小の一手から、本命のファサード方式、自社サーバーに置いた動画の軽量化まで、コピペできるコード付きで順番に解説します。

結論：動画は「置く」のではなく「押されたら読み込む」

先に結論を書きます。動画埋め込みの重さは、画質やファイルサイズではなく「ページを開いた時点でプレーヤーを読み込んでいるかどうか」でほぼ決まります。対策の優先順位は次のとおりです。

1. ファサード方式に切り替える（サムネイル画像＋再生ボタンだけを置く）— 効果が最も大きい
2. iframeにloading="lazy"を付ける — 1属性で済むが、効果は限定的
3. ファーストビューに動画を置かない — 設計側の判断で解決する
4. 自社サーバーの動画はpreload="none"＋posterにする

制作の現場では、1と3を先に決めてしまいます。表示速度の相談を受けたページの多くは、そもそもファーストビューに動画が置かれていて、しかも大半の訪問者が再生していません。読み込みを削るより「読み込まない設計にする」ほうが、効果も再現性も高いからです。

YouTubeの標準埋め込みが重くなる理由

YouTubeの共有メニューから取得できる埋め込みコードは、再生していなくてもプレーヤーのJavaScript・CSS・フォント・サムネイル・計測用リクエストをまとめて読み込みます。動画本体（ストリーム）は再生するまで流れませんが、「プレーヤーを表示する準備」だけで相当な量の通信とスクリプト実行が発生します。

iframe 1本が呼び出すもの

標準の埋め込みコードは、次のような構造になっています。

<iframe width="560" height="315"
  src="https://www.youtube.com/embed/VIDEO_ID"
  title="YouTube video player" frameborder="0"
  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
  allowfullscreen></iframe>

この1行が指す先で、プレーヤーのバンドルスクリプトが読み込まれ、さらにそこから別ドメインへの追加リクエストが連鎖します。1ページに動画を3本並べれば、その分だけ丸ごと3セット走ります。動画一覧ページや事例紹介ページが極端に重くなるのは、この掛け算が理由です。

数字で見た1本あたりのコスト

公開されている計測値を並べると、規模感がつかめます。Googleのドキュメントでは、ファサードが3KBであるのに対し、操作時に読み込まれるプレーヤーは540KBと記載されています。web.devも「YouTube埋め込みを遅延させると初期読み込みを約500KB節約できる」としています。第三者がWebPageTestで計測した内訳では、標準埋め込み1本の転送量は約1,243KB、うちJavaScriptが約958KBを占めていました。

再生していない状態でこれだけの通信が発生します。なお、Lighthouseにあった「サードパーティのファサードで遅延読み込みする」という監査項目は、Lighthouse 13で廃止されました。監査に出なくなっただけで、負荷そのものが軽くなったわけではない点に注意してください。

体感速度に効くのは通信量よりJavaScript

見落とされがちですが、埋め込みで効いてくるのは転送量よりもJavaScriptの実行時間です。スクリプトの解析と実行の間、ブラウザのメインスレッドは占有されます。その結果、画面は表示されているのにタップやクリックに反応しない、いわゆる「固まっている」状態が生まれます。スマートフォンのように処理能力が限られた端末ほど、この差がはっきり出ます。

Core Web Vitalsへの影響

Core Web Vitalsのうち、YouTubeのiframe埋め込みが効いてくるのは主にINP（操作への応答性）です。前述の計測では、標準埋め込みのTBT（メインスレッドが塞がれていた合計時間）が約2.25秒でした。TBTはINPと連動する指標なので、ここが大きいほど「押しても反応しない」体感につながります。

一方LCP（主要コンテンツの表示速度）に効いてくるのは、自社サーバーに置いたvideo要素のほうです。web.devによれば、posterに指定した画像も、自動再生した動画の最初のフレームも、LCP要素の候補になり得ます。ファサード方式で置くサムネイル画像も、親ページ上のimg要素なので同じくLCP候補です。つまりYouTube埋め込みはINP側、自社動画とサムネイルはLCP側と、影響する指標が分かれます。

【方法1】loading=”lazy” を付ける（最小の一手）

最も手軽なのは、iframeにloading="lazy"属性を追加する方法です。画面外にある動画の読み込みをブラウザが後回しにしてくれます。既存のコードを1か所書き換えるだけなので、まずここから試してください。

ステップ1：属性を追加する

<iframe width="560" height="315" loading="lazy"
  src="https://www.youtube-nocookie.com/embed/VIDEO_ID"
  title="サービス紹介動画"
  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
  allowfullscreen></iframe>

ついでに2点直しています。ドメインをyoutube-nocookie.comに変えると、Googleが「プライバシー強化モード」と呼ぶ挙動になり、埋め込み動画の視聴情報が視聴者のYouTube上の閲覧体験や広告のカスタマイズに反映されなくなります。名前に反してCookieがゼロになるわけではなく、速度も変わりません。あくまでプライバシー面の設定です。もう1つ、title属性は初期値の「YouTube video player」のままにせず、その動画の内容を書いてください。スクリーンリーダーが読み上げる文言であり、アクセシビリティ診断でも指摘される箇所です。

ステップ2：効くケースと効かないケースを見分ける

loading="lazy"が効くのは「画面外にある動画」だけです。ファーストビューに置いた動画は、遅延させる余地がないため何も変わりません。ページ下部のFAQ動画や、記事後半の解説動画には有効です。逆にヒーローエリアの背景動画やトップの紹介動画は、この方法では改善しません。

ステップ3：「lazyを付ければ速くなる」は正しくないと知っておく

ここが最も誤解されている点です。loading="lazy"は読み込みを「後ろにずらす」だけで、なくすわけではありません。訪問者がスクロールして動画の手前まで来れば、そこでプレーヤー一式が読み込まれ、JavaScriptも全量実行されます。

前述のWebPageTest計測でも、その傾向がはっきり出ています。

loading="lazy"を付けたほうがTBTもページ重量もわずかに増えています。1回の計測なので数字そのものを絶対視する必要はありませんが、少なくとも「属性を1つ足せば軽くなる」という話ではないことは読み取れます。loading="lazy"は、埋め込みが何本もあるページで初期の通信を減らす目的には有効です。しかし体感の重さを解決したいなら、次のファサード方式に進んでください。

【方法2】ファサード方式に切り替える（本命）

ファサード（facade＝見せかけ）とは、本物のプレーヤーに似せた静的な代替表示のことです。最初はサムネイル画像と再生ボタンだけを表示しておき、クリックされた瞬間に本物のiframeへ差し替えます。再生しない訪問者にはプレーヤーを一切読み込ませないため、削減幅が桁違いに大きくなります。前掲の計測では転送量が約1,243KBから約27KBへ、TBTは2.254秒から0秒になっています。Googleも「サードパーティのファサード」として推奨している考え方です。

仕組みは「画像1枚とクリックイベント」だけ

難しいことはしていません。表示しているのは軽量なサムネイル画像1枚と、その上に重ねた再生ボタンです。クリックされたらJavaScriptでiframeを生成して置き換え、autoplay=1を付けてそのまま再生に入ります。訪問者から見ると、通常の埋め込みとほとんど同じ操作感になります。

自前で書く最小コード（HTML）

<div class="yt-facade" data-id="VIDEO_ID">
  <img src="https://i.ytimg.com/vi/VIDEO_ID/hqdefault.jpg"
       alt="サービス紹介動画のサムネイル" width="480" height="360" loading="lazy">
  <button type="button" class="yt-facade__btn" aria-label="動画を再生"></button>
</div>

自前で書く最小コード（CSS）

.yt-facade { position: relative; aspect-ratio: 16 / 9; cursor: pointer; background:#000; }
.yt-facade img { width: 100%; height: 100%; object-fit: cover; display: block; }
.yt-facade iframe { width: 100%; height: 100%; border: 0; }
.yt-facade__btn {
  position: absolute; inset: 0; margin: auto; width: 68px; height: 48px;
  border: 0; border-radius: 12px; background: rgba(0,0,0,.7); cursor: pointer;
}
.yt-facade__btn::before {
  content: ""; position: absolute; inset: 0; margin: auto;
  width: 0; height: 0; border-style: solid;
  border-width: 11px 0 11px 19px; border-color: transparent transparent transparent #fff;
}
.yt-facade:hover .yt-facade__btn { background: #f00; }

自前で書く最小コード（JavaScript）

document.querySelectorAll('.yt-facade').forEach(function (el) {
  el.addEventListener('click', function () {
    var id = el.dataset.id;
    var iframe = document.createElement('iframe');
    iframe.src = 'https://www.youtube-nocookie.com/embed/' + id +
                 '?autoplay=1&rel=0&playsinline=1';
    iframe.title = 'サービス紹介動画';
    iframe.allow = 'accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture';
    iframe.allowFullscreen = true;
    el.replaceChildren(iframe);
  }, { once: true });
});

ポイントは{ once: true }です。差し替えは一度きりなので、イベントリスナーを自動で解除しておきます。replaceChildrenでサムネイルとボタンをまとめて置き換えているため、後始末のコードも不要です。

サムネイル画像の解像度を選ぶ

YouTubeのサムネイルは、動画IDから直接URLを組み立てられます。用途に応じて使い分けてください。

maxresdefault.jpgは元動画が高解像度でないと生成されず、404になることがあります。制作ではhqdefault.jpgを基本にし、大きく見せたい場合だけmaxresdefault.jpgを使って表示確認をする、という運用にしています。黒帯が気になるなら、CSSのobject-fit: coverで切り抜けば解決します。

【方法3】lite-youtube-embed を使う

自前で書きたくない場合は、Googleのエンジニアが公開しているlite-youtube-embedを使う方法があります。ファサード方式をカスタム要素として実装したもので、CSSとJSを読み込んでタグを書き換えるだけで導入できます。ライセンスはApache License 2.0、接続先は既定でyoutube-nocookie.comです。

ステップ1：ファイルを読み込む

<link rel="stylesheet" href="/assets/lite-yt-embed.css">
<script src="/assets/lite-yt-embed.js" defer></script>

CDNから読み込むこともできますが、外部ドメインへの接続が1つ増えます。ファイルは小さいので、自サーバーに置いて配信するほうが結果的に速くなります。

ステップ2：iframeをカスタムタグに置き換える

<lite-youtube videoid="VIDEO_ID" playlabel="サービス紹介動画を再生"></lite-youtube>

これだけです。playlabelは再生ボタンの読み上げ用テキストなので、動画ごとに内容を書いてください。

ステップ3：パラメータを渡す

<lite-youtube videoid="VIDEO_ID"
  params="start=30&rel=0&playsinline=1"
  playlabel="製品デモを再生"></lite-youtube>

params属性に書いた内容が、生成されるiframeのURLにそのまま渡ります。開始位置の指定や関連動画の抑制はここで行います。

導入前に知っておく2つの制約

1つ目は、スマートフォンでタップが2回必要になる場合があることです。1回目でプレーヤーが読み込まれ、2回目で再生が始まるという挙動になり、離脱の原因になり得ます。方法2の自前実装ならautoplay=1を渡して1タップで再生に入れるので、モバイル比率が高いサイトではそちらを検討してください。

2つ目は、よく引用される「約224倍速い」という数値の扱いです。この数字は公式ドキュメントとリポジトリのREADMEに記載がありますが、計測条件や方法論は公開されていません。社内やクライアントへの説明で根拠として使うなら、条件が明示された実測値（転送量 約1,243KB → 約27KB、TBT 2.254秒 → 0秒）を示すほうが誠実です。

【方法4】WordPressサイトで軽量化する

WordPressの場合、URLを貼るだけで埋め込まれる「oEmbed」の仕様上、標準ではiframeがそのまま出力されます。環境に応じて次の3パターンから選んでください。

パターンA：カスタムHTMLブロックで直接書く

記事数が少ないなら、これが最も確実です。ブロックエディターで「カスタムHTML」ブロックを選び、方法2のファサード用HTMLを貼り付けます。CSSとJSはテーマのstyle.cssとfooter.php（または子テーマのファイル）に1回だけ書いておけば、以後は使い回せます。プラグインを増やさずに済むのが利点です。

パターンB：oEmbedの出力をフィルターで書き換える

既存記事が大量にある場合は、出力側で一括変換します。embed_oembed_htmlフィルターでiframeを受け取り、loading="lazy"を追加するか、ファサード用のHTMLに置き換えます。次はloading="lazy"を足すだけの最小例です。

add_filter( 'embed_oembed_html', function ( $html, $url ) {
    if ( strpos( $url, 'youtu' ) === false ) {
        return $html;
    }
    if ( strpos( $html, 'loading=' ) !== false ) {
        return $html;
    }
    return str_replace( '<iframe ', '<iframe loading="lazy" ', $html );
}, 10, 2 );

子テーマのfunctions.phpに追記します。既にloading属性がある場合は二重付与を避けるため、そのまま返しています。

パターンC：プラグインに任せる

キャッシュ系・高速化系のプラグインには、YouTube埋め込みをサムネイルに置き換える機能が含まれているものがあります。設定画面のチェックひとつで済むぶん手軽ですが、テーマ側の遅延読み込みと機能が重複して、サムネイルが表示されない・再生ボタンが二重になるといった不具合が起きやすい組み合わせでもあります。導入したら必ず実機で再生まで確認してください。

自社サーバーに置いた動画（video要素）を軽くする

YouTubeを使わず、MP4を自社サーバーに置いてvideo要素で再生するケースもあります。この場合はプレーヤーのスクリプトが不要な代わりに、動画ファイルそのものの転送量が課題になります。

preload=”none” と poster を必ず指定する

<video src="/movie/intro.mp4" poster="/movie/intro-poster.jpg"
       preload="none" controls playsinline width="1280" height="720"></video>

preloadを指定しないと、ブラウザの判断で動画の先読みが始まることがあります。noneにしておけば、再生されるまでファイルを取りに行きません。代わりにposterで静止画を出しておけば、見た目は動画があるように見えます。widthとheightを書いておくのも重要で、これがないと読み込み後にレイアウトがずれます。

preload属性が取る値

既定値はブラウザによって異なるため、指定しないという選択肢はありません。もう1つ重要なのが優先順位で、autoplayを指定している場合はpreloadの指定より自動再生が優先されます。背景動画にpreload="none"を書いても効かないのはこのためです。

2026年に追加された video要素の loading=”lazy”

これまでloading="lazy"はimgとiframeだけの属性でしたが、2026年にvideo要素とaudio要素にも導入されました。Chromeでは148で既定有効になっています。FirefoxとSafariは執筆時点で未対応のため、使う場合は次のように判定して分岐させてください。

if ('loading' in HTMLMediaElement.prototype) {
  // video の loading="lazy" が使える環境
}

指定すると、動画本体だけでなくposter画像の取得も、preloadの実行も、autoplayの開始も、要素がビューポートに近づくまで遅延されます。未対応ブラウザでは単に無視されるだけなので、preload="none"とposterを併用しておけば実害はありません。現時点では「効いたら得をする」程度の位置づけで足しておくのが現実的です。

背景動画は音声トラックを消す

<video src="/movie/hero.mp4" poster="/movie/hero.jpg"
       autoplay muted loop playsinline></video>

ヒーローエリアの背景動画にはautoplay muted loop playsinlineの4点セットが必要です。mutedがないとスマートフォンで自動再生がブロックされ、playsinlineがないとiOSで全画面表示に切り替わってしまいます。あわせて、書き出し時に音声トラックそのものを削除してください。どうせmutedで再生するのに、音声データだけ転送しているサイトは珍しくありません。

書き出し設定の目安

背景動画やループ動画は、画質を落とすより「短く・小さく」するほうが効果的です。制作では次を目安にしています。長さ8〜15秒、解像度は1280×720（スマホ用に720×1280を別途用意）、音声なし、ファイルサイズ2MB以下。これを超えるなら、動画ではなくGIFやCSSアニメーション、あるいは静止画で代替できないかを先に検討します。

WebMを併記して軽い方を配る

<video poster="/movie/hero.jpg" autoplay muted loop playsinline>
  <source src="/movie/hero.webm" type="video/webm">
  <source src="/movie/hero.mp4" type="video/mp4">
</video>

ブラウザはsourceを上から順に評価し、再生できる最初の形式を使います。同じ画質ならWebMのほうが小さくなることが多いので、WebMを先に書き、MP4を保険として後ろに置きます。

埋め込みパラメータとIFrame Player APIの使いどころ

埋め込みURLの末尾に付けるパラメータで、再生の挙動をある程度コントロールできます。よく使うものを整理しました。

mute と modestbranding には注意

解説記事でよく見る&autoplay=1&mute=1という書き方ですが、muteはGoogleのプレーヤーパラメータ公式一覧に掲載されていません。慣用的に使われている非公式のパラメータです。実際に動く場面は多いものの、仕様として保証されたものではないため、確実にミュート自動再生をしたいならIFrame Player APIのplayer.mute()を使うのが正しい手順です。

もう1つ、ロゴを控えめにするmodestbrandingは2023年8月15日に廃止されています。古い記事のコードをコピーすると今も残っていることがありますが、指定しても効果はありません。

APIを使うべきか、使わなくていいか

YouTubeにはIFrame Player APIが用意されていて、独自の再生ボタンを作る、再生完了を検知してフォームを出す、スクロール位置に応じて停止するといった制御ができます。ただしAPIを使うにはiframe_apiのスクリプトをページ側で読み込む必要があり、軽量化とは逆方向に働きます。

実装手順は動画をファーストビューに自動再生ループで置く方法で詳しく解説しています。判断の基準はシンプルです。動画を「見せるだけ」ならAPIは不要で、ファサード方式が最適です。動画の再生完了をコンバージョンとして計測したい、視聴率に応じて出し分けたいといった要件があるときだけAPIを使います。その場合も、ファサードがクリックされた後でAPIスクリプトを読み込めば、初期表示は軽いままにできます。

手法の比較と使い分け

迷ったら「動画が主役かどうか」で分けてください。動画そのものを見に来るページなら標準の埋め込みで構いません。サービス紹介の補足として置いているだけなら、ファサード方式にすべきです。実際のサイトでは後者が圧倒的に多く、しかも再生率は想像よりずっと低いのが実情です。

表示されない・再生できないときのチェックリスト

サムネイルが真っ黒・画像が出ない

まずmaxresdefault.jpgを指定していないか確認してください。高解像度のサムネイルが存在しない動画では404になります。hqdefault.jpgに変えれば解消します。次に、動画IDが正しいかを確認します。URLの?v=以降がIDで、共有URLのyoutu.be/直後の文字列も同じです。&以降のパラメータまで含めてしまうミスが多い箇所です。

クリックしても再生が始まらない

ブラウザの開発者ツールでコンソールを開き、JavaScriptのエラーが出ていないか確認します。ファサードのスクリプトが<head>で同期読み込みされていると、要素がまだ存在せずイベントが登録されません。deferを付けるか、</body>直前に置いてください。差し替え後のiframeにallow属性のautoplayが抜けている場合も、プレーヤーは出るのに再生が始まらない状態になります。

iOSで全画面になってしまう

playsinlineの指定漏れです。video要素なら属性として、YouTube埋め込みならURLパラメータとしてplaysinline=1を付けます。背景動画で全画面に切り替わるとレイアウトが崩れるため、必ず実機で確認してください。

自動再生されない

音が出る状態での自動再生は、主要ブラウザで原則ブロックされます。video要素ならmuted属性を必ずセットにしてください。YouTube埋め込みの場合は、前述のとおりmute=1が公式パラメータではないため、IFrame Player APIのplayer.mute()で明示的に消音してから再生するのが確実です。省電力モードや通信量節約設定が有効な端末では、それでも再生されないことがあります。自動再生に依存した見せ方は避け、静止画のposterだけでも意味が通るように設計するのが安全です。

変更しても速度が改善しない

キャッシュプラグインやCDNのキャッシュが残っている可能性があります。キャッシュを削除してから、シークレットウィンドウで再計測してください。それでも変わらない場合は、PageSpeed Insightsの診断で「サードパーティコードの影響」を確認します。動画以外のチャットツールや広告タグのほうが重い、というケースも実際にあります。

よくある質問（FAQ）

ファサード方式にするとSEOで不利になりますか？

不利にはなりません。動画そのものを検索結果に出したい場合は、ページにVideoObjectの構造化データを記述してください。埋め込み方法とは独立して認識されます。むしろ表示速度が改善するぶん、ページ体験の評価には有利に働きます。

YouTubeの再生回数はカウントされますか？

されます。ファサード方式でも、クリック後に読み込まれるのは通常のYouTubeプレーヤーです。再生された時点で通常どおり計測されます。逆に、再生されていない表示だけの状態は元々カウント対象ではないため、方式を変えても数字の意味は変わりません。

youtube-nocookie.com にすればCookie同意は不要ですか？

不要にはなりません。Googleの説明は「視聴情報がYouTube上の閲覧体験に影響しない」「広告がカスタマイズされない」というもので、Cookieを一切送らないとは書かれていません。ページの表示速度も変わりません。Cookie同意が必要な要件のサイトでは、同意が得られるまでiframeを生成しない実装が別途必要です。ファサード方式は「同意後にだけ読み込む」構造と相性が良く、この点でも扱いやすい手法です。

動画は何本まで1ページに置けますか？

標準の埋め込みコードなら1〜2本が限度です。3本を超えると体感で明確に重くなります。ファサード方式にすれば、読み込むのはサムネイル画像だけになるため、10本以上並べても実用的な速度を保てます。動画一覧ページを作るなら、最初からファサード前提で設計してください。

Vimeoや他のサービスでも同じ方法が使えますか？

使えます。ファサード方式は「クリックされるまでiframeを作らない」という考え方なので、埋め込みURLとサムネイル画像の取得方法さえ分かれば、どのサービスでも成立します。サムネイルURLの取り方だけがサービスごとに異なるため、そこは各サービスの仕様を確認してください。

ファーストビューに動画を置きたいのですが、どうすればいいですか？

その場合はYouTube埋め込みではなく、短い自社動画をvideo要素で置いてください。8〜15秒・音声なし・2MB以下に収め、posterに高品質な静止画を指定します。静止画が先に表示されるため、動画の読み込みが遅れても見た目が破綻しません。

プラグインとコードのどちらを選ぶべきですか？

更新を自分で管理できるならコード、運用担当者が非エンジニアならプラグインを勧めています。ただしプラグインは他の高速化機能と競合しやすいため、導入後は必ずスマートフォンの実機で再生まで確認してください。設定画面の表示だけを見て「できたつもり」になるのが、この領域で最も多い失敗です。

まとめ

動画を軽く埋め込む方法の要点をまとめます。標準のYouTube埋め込みは、再生されなくてもプレーヤー一式（実測で約1,243KB、うちJavaScriptが約958KB）を読み込むため重くなります。loading="lazy"の追加は画面外の動画で初期通信を減らしますが、スクロールされれば同じ量が読み込まれるため、体感の重さは解決しません。本命はファサード方式で、サムネイル画像と再生ボタンだけを置き、クリックされてからiframeを生成します。自前で書いてもコードは短く、lite-youtube-embedを使えばタグの置き換えだけで済みます。

自社サーバーの動画ならpreload="none"とposterをセットで指定し、背景動画は音声トラックを削除して2MB以下に抑えます。どの手法を選んでも、最後は必ずスマートフォンの実機で再生まで確認してください。表示速度の数値だけを追って、肝心の動画が再生できなくなっていた、という事故が一番もったいない結果です。