内部改善ロードマップ Vol.17【第1部】動画埋め込みの最適化ガイド｜YouTubeを“サムネ＋クリック読込”で軽量化し、CLS/INPを守る設計

Webページを“重くしてしまう代表”といえば、やっぱり YouTubeなどの動画埋め込み ですよね。
便利なんだけど、読み込みのたびに 外部スクリプトがズラッと動き、ページ表示がガタつく …そんな経験、ありませんか？

そこで本記事では、動画の埋め込みを 「サムネ画像＋クリックして初めて読み込む」 という方式に切り替えて、
ページ全体の 速度×安定性（CLS）×操作感（INP） を守る設計をまとめます。

「コードを書く」というより、
“そもそもどう置くか？” “どこまで削減できるか？”
という 設計の型 を先に固めることが今回の目的！

動画の本数が多いサイトや、スマホでガクガクするページを改善したい方は、ぜひこの“軽量化の基本パターン”を押さえておきましょう。
今日からできることばかりなので、初級〜中級の方にも向いています！

📘 本記事で分かること（要点）

• 埋める前に判断するフロー（リンクや静止サムネで代替できる？）

• プレビュー画像（サムネ）＋クリック読込 が最強な理由

• YouTubeが重くなる“仕組み”をコードなしで理解

• aspect-ratio とプレースホルダで動画枠を安定させる方法

• 動画の本数の最適化（1ページの目安と配置ルール）

• 音声・字幕・要約など、動画の“補助情報”を本文側に持たせる設計のコツ

• CLS/INPを悪化させない“置き方・順番・枠の作り方”

まず“埋める前提”を疑う（判断フロー）

動画を軽くする最初の一歩は、「本当に埋める？」を一度立ち止まって考えること です。

意外かもしれませんが、ページが重くなる大半の原因は、
「再生されない動画をたくさん埋めている」
ことにあります。

読む人の多くは、動画の中身そのものより、
“この動画を見れば何が分かるの？” という 概要のほうを先に知りたい んですよね。

なので、動画埋め込みの最適化は “技術” より前に、
「そもそも動画を埋める必要があるのか？」
という情報設計の話から始まります。

ここでは、まず 3つのステップで判断するフロー を紹介します。
これだけで、ページの負荷はグッと下がるはずです。

リンクで足りる？ — 公式ページ／外部プラットフォームへ新規タブで誘導

動画を埋める前に、まずは 「リンクで済ませられるか？」 を検討してみましょう。

• 公式PV

• メーカーのチュートリアル

• SNS動画（X/TikTok/Instagram）
  など、閲覧先の体験を外部で完結してOK なものは、無理に埋め込む必要はありません。

「動画はこちら（新規タブ）」だけで、読者が迷わず行動できるなら、ページの速度はノーコストで守れます。

静的に代替できる？ — スクリーンショット＋要点まとめ

「動画を埋めるまでもないけど、内容は伝えたい…」
そんなときは “静的カード” で代替 できます。

• 画面のスクリーンショット

• 動画の重要な1シーン

• 要点（箇条書きでOK）

これを組み合わせると、動画を見なくても 内容の8割を伝えることが可能。

さらに、クリックしたら外部で視聴できる導線を置けば、
動画を読み込まない＝ページは軽いまま
という構成が完成します。

“情報だけほしい層” と “動画で見たい層” のどちらにも優しいやり方です。

どうしても埋める場合 — 1ページ1〜3枠を上限に、重要1枠は本文内・それ以外は章末へ

「静的では伝わらない…これはさすがに動画を埋めたい！」
というケースももちろんあります。

そんなときは、次の3つを守ると負荷を最小化できます。

1. 1ページに1〜3枠まで（目安）

2. 最重要の1本だけ本文中に置く

3. それ以外は 章末に“まとまって”置く

埋め込みは “途中に挟む” と スクロール中にガタつきやすく CLS が悪化 します。
章末にまとめれば、読者が「観るときだけ下へ移動」する構造になり、
初期表示（LCP）と操作性（INP）にも優しくなる んです。

“置く位置” の考え方だけで、動画の重さはかなりコントロールできますよ。

動画は「サムネ＋クリック読込」を標準に

動画を軽くするうえで、いちばん効果が大きいのがこの 「サムネ＋クリック読込」方式。
ページを開いた瞬間に iframe や外部スクリプトを読み込まず、
読者が“見ると決めた瞬間”にだけ読み込む という考え方です。

これは単なるテクニックではなく、
速度（初期表示）・安定性（CLS）・操作性（INP）・プライバシー の全部に効く “基本設計” なんです。

「動画を置く＝重い」は昔の話で、今は
“読み込ませない工夫” を先にするだけで圧倒的に軽くなる！

この章では、動画を埋め込むときに必ず押さえたい3つの型を紹介します。

プレビュー画像 — 低容量の静止サムネを先出し

まずは プレビュー画像（静止サムネ）を先に表示 します。
これだけで、ページは動画を読み込んでいないので 初動がめちゃくちゃ軽くなる！

• YouTubeサムネ（高画質は重いので注意）

• 1シーンのスクショ

• テキスト入りの簡易サムネ（5〜20KB でOK）

さらに、サムネのサイズを 固定の aspect-ratio で確保 しておくと、読み込み前後で高さが変わらず、
レイアウトシフト（CLS）がゼロ にできます。

“まずはサムネ、動画本体はまだ出さない”
という割り切りが、軽量化の最初の鍵です。

クリックで読込 — 再生ボタン押下でiframe生成（初期JSは最小に）

次に、サムネ上の 再生ボタンを押した瞬間に iframe を生成する 仕組みです。
つまり、
「見ないなら一切読み込まない」
という考え方。

ページ表示中は iframe も外部スクリプトも存在しないので、

• 外部JSの負荷ゼロ

• 通信もゼロ

• CPU使用率も最小
  という理想の状態を保てます。

読者がボタンを押したら、そのタイミングで初めて

• YouTube iframe

• 必要最低限の allow 属性

• sandbox の考え方

を読み込ませるイメージです。

ポイントは 初期JSをほとんど置かない こと。
「クリックされたら iframe を差し込むだけ」くらいの、シンプルな構造に寄せるのがおすすめです。

音声・字幕・要約 — 自動再生なし、本文で補助情報を追加（アクセシビリティ/SEO）

“動画を見ない人” にもきちんと伝わるよう、
本文側に補助情報を置く ことも重要です。

• 音声の内容を 2〜3行の要約 で先に伝える

• 主要チャプターを タイムスタンプ的に並べる

• 自動再生はしない（音がいきなり出ると離脱率が上がる）

• 重要な指示や数字は本文にも書く（SEO的にも◎）

これで、
「動画を見る前に何が分かるか？」
がはっきりし、読者が“見る／見ない”を決めやすくなります。

特にスマホ閲覧ではこの補助があるだけで、動画の価値がぐっと上がります。

地図は「静的プレビュー＋開く」か「縮小版を末尾に」

地図の埋め込みは、動画に次いで ページを重くする代表格 です。
理由はシンプルで、地図は背後で

• 外部API

• インタラクション用のJS

• 測位やスクロールイベント
  など、多数の処理を持っているから。

そのため “ただ1つ地図を置いただけ” で、
ページ全体が ガタつく（CLS）、
初回タップが重くなる（INP）という現象が起こりがち。

解決策は動画と同じで、
「まず埋めない」「静的で代替」「どうしても埋めるなら小さく・末尾に」
という3ステップで考えることです。

静的画像＋“地図を開く” — サムネ画像→外部アプリへ

最もおすすめなのが、
“地図の静的サムネ”＋“Google Maps で開く”ボタン の組み合わせです。

• 店舗の場所を示す静的画像

• その下に「地図を開く」（新規タブ or アプリ起動）

これだけで 情報は十分伝わるうえに、読み込み負荷はゼロ。
スマホでは特に、アプリで開くほうが操作しやすいため、UX的にも優秀です。

“外部地図アプリの方が使いやすい” という前提を活かした設計ですね。

どうしても埋める場合 — 小さめ枠×末尾、操作導線は大きく

「ページ内でそのまま地図を動かしたい！」
というニーズがある場合は、次のルールが有効です。

1. 表示サイズは小さめに（スマホ幅基準で縦140〜180px程度）

2. 本文の途中に置かず、章末にまとめる

3. 拡大したい人向けに“地図を開く”ボタンを大きめに配置

地図は“途中に挟む”と スクロール中の描画負荷が増えてINPが悪化 するため、
ページ後半にまとめるほうが安定します。

複数地点 — 一覧表＋外部リンクで代替（無限ズーム埋め込みを避ける）

複数の店舗・スポットを紹介するページで、
“すべてを1つの地図に埋め込む” のはほぼNGです。

理由はシンプルで、
ズーム・スクロール・ピン描画が重すぎる から。

代わりにおすすめなのは、

• 店舗名＋住所＋「地図を開く」リンク を一覧化

• 必要な地点だけ個別に外部へ飛ばす

という シンプルなテーブル形式。

これだけで読み込み負荷は激減し、CLS/INPも安定します。

SNS/予約/チャット等のウィジェット

動画や地図より厄介なのが、SNSや予約ウィジェット、チャットボットといった“外部サービスの一式”を読み込むタイプの埋め込みです。

理由はとてもシンプルで、これらは 外部スクリプト（JS）を大量に抱えている から。
読み込み開始と同時に

• 解析タグ

• トラッキング用スクリプト

• UIレンダリング用ライブラリ

• 外部通信
  など、目に見えない処理が一気に走り、ページの INP（操作の滑らかさ） を悪化させやすいんです。

でも大丈夫。
“初期表示では絶対に読み込まない” を基本にすれば、SNSや予約ウィジェットも 軽く・安全に 扱えます。

自動読み込みを避ける — ボタン→展開（読者主導）に切り替える

SNSタイムライン（X/Twitter・Instagram・TikTok）や予約ウィジェットは、
「ページを開いた瞬間に読み込む」 のが重さの原因です。

そこでおすすめなのが、
“静的カード” ＋ “もっと見る（タップで展開）”
という構成。

• SNSの最新投稿1〜2件を 画像化

• 「投稿を読む」「予約フォームを開く」ボタンを設置

• クリックされたらじめて外部JSを読み込む

という流れにすると、初期読み込みの負荷がほぼゼロになります。

ユーザーが“見たくなったら開く” 仕組みなので、UXにも優しいんです。

冗長スクリプトの棚卸し — 同系統の多重読みを回避

（約180字）

SNSや予約ウィジェットを複数置くと、同じ種類の外部スクリプトを何度も読み込む ケースがよくあります。

• X/Twitter の widget.js が何度も呼ばれる

• 予約ツールの SDK が各ページで二重ロード

• チャットボットのスクリプトが全ページに出現

こうなるとページは一気に重くなり、INP と CPU負荷が悪化。

対応策はとても簡単で、
“本当に必要な1本だけ” に限定する こと。
不要なスクリプトは削除して、必要なものも クリック後に初めて生成 するのが理想です。

“あるから置く” のではなく、“使う人だけが読み込む” に切り替えましょう。

フォールバック — 失敗時でも行動できる静的案内を残す

外部ウィジェットは、サービス側の障害で急に読み込めなくなることもあります。
そのため必ず フォールバック（代替導線） を用意しておきましょう。

• SNS → 投稿画像＋公式アカウントへのリンク

• 予約 → 予約ページURL・電話番号

• チャット → 問い合わせフォームリンク

これらがあるだけで、ウィジェットが壊れても 読者は困らないし、離脱も防げる んです。

“外部が落ちてもページは落ちない”。
これがまともな埋め込み設計の基本です。

枠の安定＝CLSゼロのための“先に場所を確保”

動画でも地図でもSNSでも共通するのが、
「読み込まれる前に枠の高さを決めておくこと」。
これをやっていないと、読み込み中に要素が“ガクッ”と動き、
CLS（レイアウトシフト）が悪化 します。

どれだけ軽量化しても、最初の表示がガタつけば
“なんかこのサイト不安定だな…”
と感じられてしまうので、とても大事なポイントなんです。

しかも、枠を安定させる方法はとてもシンプル。
aspect-ratio／固定寸法／プレースホルダ の3つを理解すればOKです。
ここではその基本の型をまとめます。

aspect-ratio／固定寸法 — 幅に応じた高さを先取りする

動画・地図・SNSカードなど、縦横比が決まっている要素では
aspect-ratio が便利です。

• 16:9（動画）

• 1:1（スクエア系SNS）

• 4:3（地図の縮小版）

など、比率を先に宣言しておくだけで、高さが確保されるため、読み込み後のレイアウトズレが消えます。

もし比率が曖昧な場合は、スマホ基準の 固定高さ（例：160〜200px） を取っておくのも有効です。

プレースホルダ — 読み込み前に薄い枠orぼかしを表示（高さ不変）

プレースホルダは、読み込む前に“仮の姿”を置いておく方法。

• 薄いグレーの枠

• ぼかし入りのサムネ

• シンプルなローディング風デザイン

など、どんな見た目でも構いませんが、大事なのは
“高さが変わらないこと”。

これがあるだけで、読み込み中のガタつきが完全に抑えられます。

上に置かない — ファーストビュー直上に可変ウィジェットはNG

どれだけ枠を安定させても、
ページ最上部やヒーロー画像のすぐ上に可変ウィジェットを置くのはNGです。

理由はシンプルで、
そこがズレると LCP（最大表示）とCLSの両方が悪化 するから。

動画・地図・SNS・予約ウィジェットは、
ファーストビューより下に置く のが基本ルールです。

用語ミニ辞典

（約150〜200字）

ここまでに登場した “埋め込み最適化のキーワード” を、サクッとおさらいしておきます。
細かい技術仕様を覚える必要はなく、「どんな考え方なのか？」 だけ掴めば十分です。

● クリックで読込（Click-to-Load）

動画やSNSなどを 最初は読み込まず、ボタンを押した瞬間だけ読み込む方式。
初期表示が軽くなり、外部JSの負荷がゼロにできる。

● プレースホルダ（Placeholder）

読み込み前に置く 仮画像・仮枠。
高さを確保し、CLS（レイアウトシフト）を防ぐ役割。

● aspect-ratio（アスペクト比）

縦横比を指定して 見た目の高さを先取り するCSSの仕組み。
動画・地図・SNSカードすべてに有効。

まとめ — 埋め込み最適化は“埋めないが勝ち”から始める

動画・地図・SNS・予約ウィジェット…。
どれも便利だけど、何も考えずに埋めると ページは一気に重くなり、CLS/INP も悪化 してしまいます。

今回紹介したように、

• サムネ＋クリック読込

• 静的プレビュー（画像）

• 枠の先取り（aspect-ratio／プレースホルダ）

といった “読み込ませない工夫” を先に入れるだけで、埋め込みの軽量化は驚くほど進みます。

まずは 「埋めない → 静的代替 → 埋めるなら最小」 の順で考えること。
これが失敗しない埋め込み最適化の基本です！

別記事への導線 — 次は実装・監視へ、さらに深い最適化へ

ここまで読んだら、次のステップは “実装と運用” です。
特に YouTube のクリック読込や SNS・予約ウィジェットの遅延読み込みは、同意モードやプライバシー設定 と密接に関わってきます。

続きは以下の記事で、より実務的な視点から深掘りしています👇

• Vol.17【後編】｜埋め込みの実装と監視：遅延・同意・計測で“軽さと信頼”を両立

• Vol.7／Vol.14 復習｜CLS・INPとモバイル操作性の基本原則

埋め込みの軽量化は “一度やって終わり” ではなく、週次・月次での改善サイクル が大事。
次の記事で、一緒に運用力まで底上げしていきましょう！

今回はここで終わりにしたいと思います！

最後までお読みいただきありがとうございました！

このブログでは「ChatGPT×副業」をテーマに、AIをフル活用したリアルな副業チャレンジを発信しています🎶

むずかしい話はナシで、「ちょっとやってみたいかも」と思えるような内容を目指しています😁

私は現在、ChatGPTを使ってTシャツのデザインを作って販売したり、

LINEスタンプのキャラ制作に挑戦したりしています👍

デザインの知識ゼロでも、AIの画像生成機能を使えばかなりいい感じになりますよ！

ブログの内容やSEO対策も、ぜんぶChatGPTに相談しながら書いています。

アイデアが出ないときも、相棒みたいに助けてくれます🎶

さらに、楽天ルームのレビュー文章もChatGPTと一緒に考えたり、

X（旧Twitter）の投稿や運用方法も提案してもらったりと、あらゆる場面でAIに頼っています。😅

「AIって便利そうだけど、自分にも使えるのかな？」

と思っている人には、ぜひ読んでほしいです。

このブログは、AI初心者でも副業が始められるように、

体験ベースでわかりやすく書いています。

私の成功も失敗もまるごとシェアしていくので、よかったら気軽に読んでいってくださいね。

Xでも日々の活動をゆるっと更新しているので、ぜひのぞいてみてください！

明日のあなたがより豊かになりますように😌

それでは、おやすみなさい😴