Webサイトの動画が重い・遅い時の解決策｜Core Web Vitals（LCP）を劇的に改善する次世代動画配信

なぜ動画を載せるとサイトが重くなりSEO評価（LCP）が落ちるのか？

動画本体とプレーヤーが、本文や画像の読み込みと競合する

動画を載せたページでは、映像データだけでなく、posterと呼ばれる再生前の画像も読み込まれます。外部サービスの埋め込みなら、iframeの内部でプレーヤー用のJavaScriptやCSSなども取得します。再生前でも通信やスクリプト処理が発生するため、本文の表示や主要画像の読み込みと競合することがあります。

自社サーバーのMP4を置くだけなら、ネイティブのvideo要素を使い、外部プレーヤーのスクリプトを省く構成にできます。ただし、大きなMP4を最初から取得すれば、その利点を相殺します。反対に、外部配信に変えて動画本体の転送を自社サーバーから切り離しても、プレーヤーをすべて即時に読み込めば初期負荷は残ります。原因は「どのサービスか」だけではなく「何を、いつ読み込んだか」にあります。web.devの動画最適化ガイドも、動画ファイルと外部埋め込みの両方に注意を促しています。

LCPは動画全体のダウンロード完了を測る指標ではない

LCP（Largest Contentful Paint）は、最初の画面内にある最も大きな画像やテキストなど、主要コンテンツの表示タイミングを測ります。動画の場合は、poster画像の表示または最初のフレームの表示のうち、早い方がLCP候補になります。posterがなければ動画はLCPと無関係、という理解は正しくありません。実際に何がLCP要素になったかは、ページごとに確認が必要です。

GoogleのLCP解説では、良好な目安を2.5秒以下とし、モバイルとデスクトップを分けたページ読み込みの75パーセンタイルでの評価を推奨しています。ただし、LCPはSEO評価そのものではありません。Core Web Vitalsの読み込み性能を表す指標です。GoogleはCWVをランキングシステムで利用しますが、良好なスコアでも検索上位は保証されないと明記しています。動画を置いたことだけで順位が下がる、と断定することもできません。

画面上部は優先表示し、画面外だけを遅延させる

最初の画面にある主役の動画、特にLCP候補には、安易にloading="lazy"を付けないでください。posterの取得まで遅れると、主要コンテンツの表示を後ろにずらす可能性があります。WordPressの高速化プラグインが画像やiframeを一括で遅延させている場合も、ヒーロー部分を除外できるか確認します。

一方、スクロールしないと見えない補足動画には遅延読み込みが適しています。iframeのloading="lazy"は、画面に近づいてから埋め込みを読み込む仕組みです。さらに初期通信を抑えたい場合は、画像と再生ボタンだけを表示し、クリック時にプレーヤーへ置き換えるfacade方式を検討します。lazyは「画面に近づくまで」、facadeは「視聴する意思を示すまで」と、待つ条件が異なります。操作できるボタンと動画の説明を用意し、キーボードでも再生できる実装にします。外部埋め込みの公式ベストプラクティスでは、こうした手法を主に画面外や補助的なコンテンツに使う方針が示されています。

FCP・LCP・再生開始時間を別々に測る

FCP（First Contentful Paint）は最初にコンテンツが描画されたタイミング、LCPは主要コンテンツが表示されたタイミングです。FCPが速くても、主役の動画posterだけが遅ければLCPは改善しません。また、posterが早く表示されてLCPが良好でも、再生ボタンを押した後の待ち時間や途中の停止が長いケースがあります。ページ表示と動画視聴は分けて評価します。

まずPageSpeed InsightsとChrome DevToolsのPerformance・Networkで、LCP要素、動画関連リクエストの開始時刻、転送量を確認します。同じ端末条件と回線条件で変更前後を複数回測り、動画なしの検証ページとの違いも見ます。ログイン状態、Cookie同意、キャッシュ状態をそろえると原因を切り分けやすくなります。

公開後は、実際の訪問者の体験を集めるRUM（Real User Monitoring）でも確認します。PageSpeed Insightsの実ユーザーデータは過去28日間のCrUX集計で、変更直後にすべてが入れ替わるものではありません。データ不足でサイト全体の値に切り替わっていないかも見てください。必要ならweb-vitalsなどによる自前のRUMを補います。ただし、外部iframe内部のLCPは親ページのJavaScriptから完全には観測できないため、自前RUMとCrUXに差が出ることがあります。

動画埋め込み方式別の表示速度・帯域コスト比較

初期表示を軽くする仕組みと、再生中の配信を効率化する仕組みは別です。HLSは映像をセグメントに分けて配信する方式で、複数の画質を用意すれば、プレーヤーが回線などに応じて切り替えるABR（アダプティブビットレート）配信を利用できます。CDNは配信拠点を分散する仕組みです。どちらも有用ですが、埋め込みプレーヤーの初期負荷を自動的にゼロにはしません。

「外部埋め込みだから遅い」「Gumletなら必ず速い」とは言えない

最初から読み込む動画が1本のページと、複数のプレーヤーを並べるページでは負荷が違います。同じ動画サービスでも、画面外のプレーヤーを即時に読み込むか、クリックまで待つかで初期通信は変わります。サービスの入れ替えだけを比較するのではなく、同じ配置、同じ動画内容、同じ再生条件で比べてください。

YouTubeとVimeoも、アップロードされた動画をそのまま無調整で配るだけのサービスではありません。YouTubeの公式ヘルプは回線や画面サイズなどによる自動画質調整を説明し、Vimeoの公式ヘルプも適応配信を案内しています。GumletだけがABRを使えるという比較は適切ではありません。

帯域は「保存サイズ」ではなく「実際に配ったデータ量」で考える

動画の保存容量と、視聴者へ配る転送量は別です。再生回数だけでなく、視聴時間、選ばれたビットレート、先読み、途中離脱や繰り返し視聴によって配信量が変わります。HLSだから一定量まで必ず安くなるわけでも、CDNキャッシュに当たれば視聴者向けの転送量がゼロになるわけでもありません。

初期読み込みを遅らせれば、動画を見ない訪問者への不要な通信を減らせます。ABRは回線や再生条件に合った配信を行います。ただし、高画質で長く視聴されれば帯域は増えます。Gumletの帯域・保存容量の超過仕様も含め、実際の利用量と契約枠を確認してください。生成した複数解像度は保存容量にも影響します。

Vimeoの超過時の対応はVimeo帯域超過の解説、配信元を変更する作業はVimeoからGumletへの移行ガイドで詳しく扱っています。ここでは契約トラブルや移行手順ではなく、表示速度と転送設計に絞って判断します。

Gumletで画質を落とさず動画を自動軽量化・高速配信する3ステップ

ステップ1：変換前の基準を残し、ABRの処理設定を決める

最初に、現行ページのFCP・LCP、動画関連の転送量、再生開始までの待ち時間を記録します。元動画も手元に残してください。変換前の基準がなければ、画質を維持できたか、不要な転送が減ったかを判断できません。

次にGumletのワークスペースで処理設定を確認し、動画をアップロードします。公式クイックスタートでは、Browse Videoやドラッグ＆ドロップでのアップロードを案内しています。WordPressのメディアライブラリに置いたMP4を参照し続けるだけでは、Gumletの動画変換や配信に自動で置き換わりません。対象動画をGumletで処理し、その動画の埋め込みまたは配信URLを使う必要があります。

公式のProcessing Settingsによると、ABR出力ではHLSとDASHを生成でき、出力解像度を選べます。元動画とプロファイルが許す範囲で複数の解像度が作られ、ビットレートは自動的に選ばれます。すべて最高解像度に固定するのではなく、動画内の文字の細かさ、表示する大きさ、想定端末に合う出力を確認しましょう。

設定を変更しても、すでに処理済みの動画は自動で再エンコードされません。新しいアップロードには更新後の設定が適用されますが、既存動画にはReprocess Videoによる再処理が必要です。また、元動画の色空間情報が欠けている場合は出力の色に差が生じることがあるため、色味も見比べます。

ステップ2：処理後の動画を埋め込み、表示位置に合った読み込みにする

処理後は動画詳細のEmbed & Shareから、その動画のコードを取得します。WordPressなら、公式Gumlet VideoプラグインのGutenbergブロックやショートコードも利用できます。公式の埋め込みガイドは、WordPressがiframeの追加属性を削除して一部機能に影響する場合があると説明しています。保存後の公開ページで、意図した属性とプレーヤーが残っているか確認してください。

最初の画面にある動画は、画像やiframeを一括でlazyにする設定から除外します。画面外の補足動画はlazy、視聴されるまでプレーヤーを取得する必要がないものはfacadeを検討します。動画の表示枠にはwidth・heightやaspect-ratioで比率を確保し、読み込み時に本文が押し下げられるCLSも防ぎます。

<div style="aspect-ratio:16/9;">
  <iframe
    src="https://play.gumlet.io/embed/{{asset_id}}"
    title="商品の使い方を説明する動画"
    width="960" height="540"
    loading="lazy"
    style="width:100%;height:100%;border:0;"
    allow="autoplay; encrypted-media; picture-in-picture; fullscreen">
  </iframe>
</div>

iframeにpreload="none"を付けても、内部のvideo要素の取得を直接制御することはできません。iframeの遅延読み込みと、内部プレーヤーの再生設定は別に扱います。自動再生は必要な動画だけで有効にしてください。Gumletのプレーヤー設定ではAutoplayは既定で無効、有効時はミュートになると案内されています。ただし、ミュートなら通信量がなくなるわけではなく、端末やブラウザーのポリシーによって自動再生できないこともあります。

Gumletは公式製品ページでmulti-CDN配信を案内しています。ただし、その記載だけで全プラン共通の構成や自動切り替えの条件まで保証されるわけではありません。利用する契約の対象機能を確認し、実際の配信地域で検証してください。CDNは動画配信を効率化する仕組みであり、WordPressの遅いHTML応答や重いテーマをまとめて解消するものではありません。

埋め込みの基本は動画埋め込みガイドを参照してください。公開範囲やドメイン制限の設定は、速度対策とは分けて動画のドメイン制限・セキュリティの解説で確認できます。

ステップ3：poster・知覚画質・実ユーザーの速度を確認する

LCPを担う動画では、まず何が最初に表示されるかを確認します。ネイティブvideoなら、表示サイズに合ったposterを指定し、手動再生の動画はpreload="none"を候補にします。poster自体がLCP要素なら、その画像を優先取得する方法があります。Googleの動画遅延読み込みガイドでは、posterへのlink rel="preload"とfetchpriority="high"を紹介しています。

<!-- head内：実際にLCP候補となるposterだけを優先取得 -->
<link rel="preload" as="image"
  href="/media/your-video-poster.webp" fetchpriority="high">

<!-- 本文内：手動再生。LCP候補なのでlazyにしない -->
<video controls playsinline preload="none"
  poster="/media/your-video-poster.webp"
  width="1280" height="720"
  style="max-width:100%;height:auto;">
  <source src="/media/your-video.mp4" type="video/mp4">
  お使いのブラウザーでは動画を再生できません。
</video>

posterの優先取得をすべての動画に設定すると、本当に重要な画像と帯域を奪い合います。preloadはブラウザーへのヒントであり、必ずそのとおりに動く保証もありません。preload="metadata"でもメタデータの位置などによって取得量が増えることがあります。また、autoplayを有効にすると再生用のダウンロードが必要になるため、preload="none"だけで通信を止められるとは考えないでください。

画面外のネイティブvideoは、preload="none"と遅延読み込みを組み合わせて確認します。videoのloading="lazy"は対応ブラウザーでposterなども遅らせますが、未対応ブラウザーは属性を無視します。必要に応じてIntersection Observerなどの補助を使い、対象端末での挙動を確かめてください。iframeのloading対応とvideoのloading対応を同じと考えないことも重要です。

画質確認では、同じ場面を同じ表示サイズで見比べます。細い文字、図表、暗い部分、激しい動きで不自然なつぶれや色の変化がないかを確認し、実際のスマートフォンでも再生します。ABRは回線が細いときに低い画質へ切り替えることがあるため、全視聴者が常に元動画と同等の解像度になる保証ではありません。必要な情報が読めるか、再生が途切れないかを合わせて評価します。

最後に変更前と同じ条件でFCP・LCPと初期転送量を測り直します。再生ボタンを押してからの待ち時間、再生中の停止も確認してください。HLSではマニフェストと実際に取得されたセグメントを調べ、元のMP4の保存サイズだけで削減効果を判断しないようにします。公開後はモバイルのRUMと帯域使用量を追い、表示速度・知覚画質・費用の三つが要件を満たしているかで採用を決めます。

よくある質問（FAQ）

まとめ：目的に合う設定と費用を検証してから導入する

WordPressの動画高速化は、動画容量だけでなく、初期読み込みの順序から見直すことが重要です。LCPを担うposterや先頭フレームは早く表示し、画面外の動画はlazyやfacadeで必要になるまで待たせます。再生中はHLS・ABRとCDNで配信を効率化しますが、それだけでページ全体が速くなるとは限りません。

Gumletでは、処理設定を確認して動画を変換し、配信URLや公式の埋め込みを利用したうえで、変更前後のFCP・LCP、再生待ち時間、転送量を比べてください。「画質を落とさず」を無劣化保証として扱わず、実際の表示サイズでの知覚画質を確認し、公開後のRUMと帯域使用量まで追うことが、無理のない高速化につながります。

出典・確認した公式情報

2026年11月5日確認。仕様・料金・プラン・画面名・対応環境は更新される場合があります。申込み前に公式情報と実際の契約条件を確認してください。

• web.dev — Largest Contentful Paint (LCP)：poster・first frame・75パーセンタイル・iframe計測制約
• web.dev — Video performance：動画と埋め込みの負荷、preload、autoplay、poster優先取得
• web.dev — Lazy loading video：LCP動画のlazy回避、video loadingの対応差、metadataの注意
• web.dev — Best practices for using third-party embeds：iframe lazy・facade・レイアウト予約
• Google Search Central — Core Web VitalsとGoogle検索の関係
• Google Search Central — Page experience：CWVは順位システムで利用されるが上位表示の保証ではない
• Google — About PageSpeed Insights：FCP・LCP、ラボと実測、過去28日間のCrUX集計
• web.dev — Getting started with measuring Web Vitals：RUMとラボの併用
• YouTube Help — Change the quality of your video：視聴条件に応じた自動画質調整
• Vimeo Help — Bandwidth on Vimeo：帯域の要因と適応配信
• Gumlet Docs — Quick Start Guide：アップロードとEmbed & Share
• Gumlet Docs — Processing Settings：ABR・HLS/DASH・自動ビットレート・既存動画再処理
• Gumlet Docs — Embed & Stream：公式iframe形式とWordPressの属性処理に関する注意
• Gumlet Docs — Player Customization：autoplay既定無効・有効時ミュート
• Gumlet Docs — WordPress Video Plugin：公式ブロックとショートコード
• Gumlet Docs — Overage Billing：配信帯域・保存容量と超過条件
• Gumlet — Video CDN：CDN・ABR・multi-CDNの公式製品説明：https://www.gumlet.com/video-cdn/（料金は上の公式CTAで確認）