遅いヒーロー画像とCore Web Vitalsを改善する

遅いヒーロー画像を修正する方法：概要

ヒーロー画像はウェブページ上部にある大きな画像です。ヒーロー画像を最適化しないと、Largest Contentful Paintが長くなります。 私が最適化を依頼されるサイトの10個中9個は、ヒーロー画像に問題を抱えています。 この記事では、ヒーロー画像を高速化するさまざまな手法を紹介します。

最終レビュー： Arjen Karel （2026年2月）

ヒーロー画像とは

「ヒーローヘッダー」とも呼ばれるヒーロー画像は、多くの場合ウェブページの上部に配置されるテキスト付きの大きな画像です。通常は全幅に広がってページ上部の目立つ場所に配置されるため、ユーザーが企業やサービスを最初に目にする部分となります。

おさらい：ヒーロー画像、Core Web Vitals、Largest Contentful Paint： 
ヒーロー画像はそのサイズ（通常、ページの全幅とviewportの高さのかなりの部分を占めます）のため、ほぼすべてのケースでLargest Contentful Paintの要素になります。
Largest Contentful Paintは重要なCore Web Vitalsの指標です。Largest Contentful Paintの要素は、ブラウザのviewport内に描画される最大の要素です。2025 Web Almanacによると、モバイルページの76%でLCPの要素は画像です。現在、LCPの基準を満たしているモバイルオリジンはわずか62%です。ヒーロー画像を修正すれば、ほとんどのサイトでLCPを修正できます。
最適化されていない画像は多くの帯域幅を消費し、読み込みに時間がかかるため、ヒーロー画像はしばしばLargest Contentful Paintの指標を悪化させます。

ヒーロー画像とLargest Contentful Paintの最適化

ヒーロー画像とLargest Contentful Paintを最適化する手法は数多くあります。ここではそれらを説明します。多くの手法は組み合わせて使うことで、さらに良い結果が得られます。

1. ヒーロー画像をプリロードするか、103 Early Hintsを送信する

要素をブラウザでできるだけ早く利用可能にしたい場合、その要素をプリロードできます。プリロードにはリソースヒントを使用します。リソースヒントは要素の優先度をブラウザに伝え、そのリソースのごく初期のダウンロードをトリガーします。2025 Web Almanacによると、LCPの画像をプリロードしているページはわずか2.1%です。これは大きな機会損失です。

<link
  rel="preload"
  as="image"
  href="wolf.jpg"
  fetchpriority="high"
  imagesrcset="hero_400px.jpg 400w, hero.jpg 800w, hero_1600px.jpg 1600w"
  imagesizes="50vw">

103 Early Hintsを使用すると、サーバーは最終的なHTMLレスポンスの前にリソースヒントを送信できます。サーバーがページを生成している間に、ブラウザはヒーロー画像のプリロードを開始できます。Chrome、Edge、FirefoxはすべてEarly Hintsによるプリロードをサポートしています。Safariはpreconnectをサポートしていますが、Early Hintsによるプリロードはまだサポートしていません。設定の詳細は、103 Early Hintsの完全なガイドを読んでください。

CoreDashで監視しているサイト全体で、LCPの画像をプリロードしているページのLCP「良好」率は81%です。プリロードしていない場合の64%と比較して高くなっています。すべてのプリロードオプションの完全な手順については、LCPの画像をプリロードする方法を参照してください。

2. ヒーロー画像にfetchpriority="high"を使用する

fetchpriority属性は、どのリソースが最も重要かをブラウザに伝えます。ヒーロー画像にfetchpriority="high"を設定すると、他の画像やスクリプト、フォントといった競合するリソースよりもダウンロードの優先度が高くなります。

<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">

2025 Web Almanacによると、LCPの画像にfetchpriority="high"を設定しているページはわずか17%です。つまり、83%のサイトが簡単に得られるパフォーマンス向上を見逃しています。

上記のプリロードリンクにfetchpriority="high"を追加することもできます。fetchpriority="high"は1ページにつき1つの画像にのみ使用してください。複数の高優先度の画像があると互いに競合し、効果が相殺されます。ブラウザがリソースを優先順位付けする仕組みについては、リソースの優先順位付けに関するCore Web Vitalsガイドを読んでください。

3. ヒーロー画像を圧縮し、次世代フォーマットを使用する

画像を圧縮するとファイルサイズが小さくなります。ファイルサイズが小さければ消費する帯域幅が減り、ブラウザでより早く利用できるようになります。画像の圧縮は、画像編集ソフト、CMS（ヒント：開発者がWordPressの圧縮レベルを設定できます）、またはオンラインの画像圧縮ツールで行えます。

遅いヒーロー画像の多くは、PNGやJPEGといった「間違った」画像コンテナで配信されているため、必要以上に遅くなっています。JPEGやPNGよりもはるかに高速な代替手段としてWebPやAVIFがあります。2025 Web Almanacによると、LCPの画像の57%は依然としてJPEG、26%はPNGで配信されており、WebPを使用しているのはわずか11%、AVIFを使用しているのは1%未満です。

多くのCMSには、画像を次世代フォーマットに変換するプラグインがあります。画像変換をウェブサイトに統合するのが難しい場合は、画像変換をサポートするCDNが解決策になるかもしれません。画像最適化の手法の完全な概要については、Core Web Vitalsのための画像最適化を参照してください。

4. 背景画像を使用せず、通常のレスポンシブ画像を使用する

ヒーロー画像は通常の画像であるべきで、背景画像にすべきではありません。ヒーロー画像の一般的な実装方法は、ヒーローコンテナに背景画像を追加し、そのコンテナのbackground-sizeをcoverに設定することです。これにより、ヒーロー画像が常に画面に収まるようになります。

背景画像はCore Web Vitalsに悪影響を与えます。これを覚えておいてください。背景画像がパフォーマンスに悪い理由について詳しく読んでください。背景画像を完全に避けられない場合は、少なくともスクロールせずに見える範囲より下にある背景画像を遅延読み込みできます。

• 背景画像は低い優先度で読み込まれる
• 背景画像はレスポンシブではない（意図的に複雑な実装をしない限り）
• 背景画像は、多くのlazy loadingライブラリでCore Web Vitalsの問題を引き起こす可能性がある

私のやり方は、絶対配置で通常の画像を追加し、その画像のobject-fitプロパティをcoverに設定することです。背景画像を通常の画像に変更すれば、レスポンシブ画像を使用できるようになります。Elementorを使用している場合は、Elementorのヒーロー画像の修正方法を確認してください。

レスポンシブ画像とは、デバイス（モバイル、デスクトップ、タブレット）ごとに異なるバージョンの同じヒーロー画像を送信できることを意味します。デスクトップデバイスには1920x1280の巨大なヒーロー画像を送信し、モバイルデバイスには400x266ピクセルの小さなヒーロー画像だけを送信すれば済みます。これでデータ量が25分の1になります。

• ヒーロー画像がより高い優先度で読み込まれるようになる
• ヒーロー画像にレスポンシブ画像を使用できるようになる

style.css

<style>
#herocontainer{
    position:relative;
    padding:4rem 0
}
#heroimg{
    object-fit: cover;
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
}
</style>

index.html

<div id="herocontainer">
<h1>Welcome to my site</h1>
<picture>
    <source
        type="image/webp"
        media="(max-width:540px)"
        srcset="herosm.webp">
    </source>
    <img fetchpriority="high" loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

5. メインドメインからヒーロー画像を配信し、CDNを検討する

Largest Contentful Paintの画像が別ドメイン（例：'static.mydomain.com'）から配信されているのを頻繁に見かけます。これらのサブドメインは多くの場合CDNを指しています。CDNの使用自体は推奨しますが（後述）、このような設定は避けるべきです。サブドメイン上の画像は、新しいサーバーへの新しい接続を必要とします。新しい接続はコストが高く、貴重な時間を消費します。メインドメイン（例：www.mydomain.com）から画像を配信すれば、すでに確立されたサーバー接続を通じて画像をはるかに速く取得できます。

メインドメインに設定すると、CDNは大幅な速度向上をもたらす可能性があります。特にサイトが世界中からアクセスされる場合です。CDNは世界中の戦略的な場所にサーバーを配置しており、静的リソース（画像など）をキャッシュしてローカルでの応答時間を高速化します。つまり、データが世界中を移動する必要はなく、ローカルのエッジサーバーから配信できます。完全な設定ガイドについては、Core Web VitalsのためのCloudflare設定方法を参照してください。

6. ヒーロー画像のlazy loadingを避ける

ヒーロー画像にlazy loadingが適用されていないことを確認してください。ヒーロー画像は常にeagerで読み込む必要があります。

多くのサイト、特にWordPressサイトでは、WP RocketやWP Core Web VitalsといったWordPressのページ表示速度改善プラグインを使用しています。これらのプラグインは通常、遅いサイトを高速化する素晴らしい仕事をしますが、間違った設定までは修正できません :-)

これらのプラグインは、lazy loadingの候補として適していそうな画像をlazy loadingします。ヒーロー画像がeager画像でない場合、それらのプラグインはおそらくヒーロー画像もlazy loadingしてしまいます。

これは良くてもLCPの指標にわずかな遅延を引き起こします。最悪の場合、特にJavaScriptベースのlazy loadingが有効になっていると、より大きな遅延を引き起こします。2025 Web Almanacによると、約17%のページがLCPの画像をlazy loadingしています。つまり、17%のサイトが自らLCPを悪化させているのです。Lighthouseでこの警告が出ている場合は、lazy loadingされたLCP画像の警告を修正する方法を参照してください。

画像をeagerで読み込むのは簡単です。画像にloading="eager"を追加するだけです。eagerは実はブラウザのデフォルトであることに注意してください。loading属性を完全に省略しても同じ効果があります。本当の目的は、ヒーロー画像にloading="lazy"が付いていないことを確実にすることです。意図を示すシグナルとしてeagerを明示的に追加することは、CMSやプラグインが自動でlazy loadingを適用するようなサイトでは依然として有用です。

<img src="hero.webp"  fetchpriority="high" width="800" height="400">

7. ヒーロー画像によるレイアウトシフトを避ける

ヒーローバナーやヒーロー画像でよく見られるもう一つの問題は、それらが大きなレイアウトシフトを引き起こすことです。これらのレイアウトシフトはさまざまな理由で発生します。

• ヒーロー要素がJavaScriptで作成されている。一部のヒーロープラグインやElementorのようなページビルダーは、ヒーローコンテンツのレンダリングをJavaScriptに依存していることで知られています。JavaScriptを使うこと自体は問題ありませんが、JavaScriptなしでもヒーロー要素が同じようにレンダリングされることを確認してください。
• ヒーロー要素内のフォントがレイアウトシフトを引き起こす。ヒーロー要素には通常、コールトゥアクションやキャッチフレーズを含む大きなテキストが含まれます。これらの大きなフォントがレイアウトシフトを引き起こさないように確認してください。
• 画像のサイズが指定されていない。ヒーロー画像がcover画像（背景画像または絶対配置された画像）でない場合、画像のサイズ（widthとheight）が指定されていないと確実に大きなレイアウトシフトを引き起こします。

レイアウトシフトを修正してもLargest Contentful Paintは改善しませんが、ページのCore Web Vitalsは改善します。レイアウトシフトの修正方法について詳しくは、Cumulative Layout Shiftの修正方法に関する詳細なガイドを読んでください。

8. 2段階読み込みを使用してヒーローのCore Web Vitalsを改善する

2段階読み込みは、私たちがすべての画像に適用している高速化手法です。まず、大きな高品質画像よりもはるかに早くダウンロードされると予想される、極めて低品質な画像を配信します。低品質な画像が画面に描画されると、ブラウザはバックグラウンドで高品質な画像の取得を開始します。高品質な画像のダウンロードが完了すると、低品質な画像は高品質な画像に置き換えられます。

2段階読み込みには3つの方法があります。最初の2つは検討すべき方法です。最後の1つはやるべきではない方法です。

1. 完全な2段階読み込み

完全な2段階読み込みでは、最初の低品質な画像は元の高品質な画像と全く同じサイズ（widthとheight）になります。

この2段階読み込みの結果、Largest Contentful Paintの要素は、はるかに高速な低品質画像になります（その後、遅延して置き換えられます）。画像の置き換えは非常に高速に行われるため、一般の訪問者はおそらく気付きません。この手法の結果として、LCPがはるかに早く描画され、ページがより早く「準備完了」に見えるようになり、UXの大幅な向上とCore Web Vitalsの改善に貢献します。

2. 小さなインラインプレースホルダー

小さなプレースホルダーは非常に優れた手法ですが、1つ欠点があります。Core Web Vitalsを改善しないことです。それでもUXを向上させるため、優れた手法であることに変わりはありません。

基本的な考え方は2段階読み込み手法と同じですが、同じサイズの低品質画像1枚の代わりに、より小さく縮小された画像をデータURIを通じてインラインで配置します。Largest Contentful Paintの画像となる最終的なヒーロー画像は、引き続きバックグラウンドでダウンロードされます。このトリックはLargest Contentful Paintを改善しませんが、2段階読み込み手法よりもさらに早くページを準備完了に見せることができます。

3. 透明なプレースホルダー

一般的な2段階読み込みの手法であり、ブラウザを騙して早期のLargest Contentful Paint指標を送信させる方法として、透明なSVG要素を使用するものがあります。これらの要素は小さく、小さなインラインプレースホルダーと同様にインラインで配置できます。

インラインSVG要素を使用してそれを置き換えるのは、実際にはlazy loadingの手法です。この手法の利点はクロスブラウザで動作することです。

もちろん、lazy loadingはviewport外の要素にのみ適用すべきです。この場合、透明なSVG要素は実際のヒーロー画像を遅延させるだけで、訪問者にとって付加価値はありません。描画の指標は良くなるかもしれませんが、ページのUXは実際には悪化します。

だからこそ、UXを悪化させるようなトリックを使わず、ヒーロー画像は常にeagerで読み込むべきなのです。

まとめ

プリロード、fetchpriority、レスポンシブ画像、そしてeager読み込みを組み合わせた最適化されたヒーロー画像は以下のようになります。

<!-- <head>内 -->
<link rel="preload" as="image" href="hero-800.webp" fetchpriority="high"
  imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  imagesizes="100vw">

<!-- <body>内 -->
<img src="hero-800.webp"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="100vw"
  width="1600" height="900"
  alt="説明的な代替テキスト">

変更を加えた後は、Real User Monitoringで改善を確認してください。Lighthouseはlab snapshotを提供しますが、Googleは過去28日間に収集された実際のユーザーのfield dataに基づいてランク付けします。