Core Web Vitalsのために画像を最適化してください。
画像がCore Web Vitalsに与える影響と、その最適化方法について学びます。
画像がCore Web Vitalsに与える影響
2025 Web Almanacによると、デスクトップの85%、モバイルの76%のページで、画像がLargest Contentful Paintの要素となっています。つまり、画像最適化はCore Web Vitalsを改善する上で最も効果的な施策です。しかし、画像が影響するのは読み込み速度だけではありません。レイアウトシフトの原因になることもあり、画像の多いページではインタラクティビティを低下させることすらあります。このガイドでは、HTML属性やプリロードから、レスポンシブ画像、モダンなフォーマット、そしてページ内の各画像に適用すべき戦略まで、あらゆる側面を解説します。
最終レビュー：Arjen Karel（2026年2月）
Core Web Vitalsを理解する
Core Web Vitalsは、Googleがランキングシグナルとして使用する3つのユーザー中心の指標です。Largest Contentful Paint (LCP)は読み込み速度を測定し、Interaction to Next Paint (INP)はインタラクティビティを測定し、Cumulative Layout Shift (CLS)は視覚的安定性を測定します。画像はこれら3つすべてに影響を与える可能性があります。
画像はどのCore Web Vitalsに影響を与えるか？
画像がCore Web Vitalsのすべてに影響すると聞いて驚くかもしれません。レンダリングの遅い段階でダウンロードのキューに入ったり、単に画像が大きすぎたりすると、通常はLCPスコアが悪化します。画像のサイズが設定されていなかったり、読み込み中にサイズが変わったりすると、CLSスコアにも影響します。さらに、画像のデコードにmain threadの処理時間を奪われすぎると、INPにまで影響を及ぼすことがあります。詳しく見ていきましょう。
Largest Contentful Paint
Largest Contentful Paint (LCP)は、ページ内で最大の要素（画像や動画など）がユーザーに表示されるまでの時間を測定します。2025 Web Almanacによると、デスクトップの85%、モバイルの76%のページで、画像がLCP要素となっています。画像のキューへの追加が遅すぎたり、読み込みに時間がかかりすぎたりすると、ページのLCPスコアは著しく悪化します。
Cumulative Layout Shift
Cumulative Layout Shift (CLS)は、読み込み中にページのコンテンツがどの程度移動するかを測定します。画像に適切なサイズが設定されていなかったり、ページの読み込み後に挿入されて他の要素を押し出したりすると、レイアウトシフトが発生します。2025 Web Almanacの報告によると、デスクトップページの65%には、明示的なサイズ指定のない画像がまだ少なくとも1つ存在します。
Interaction to Next Paint (INP)
画像はInteraction to Next Paint (INP)にも影響を与える可能性があります。これは、ユーザーが操作を行ってからページが視覚的に応答するまでの時間を測定します。デコードが必要な大きな画像が多すぎると、ユーザーの操作に対するページの応答に時間がかかり、INPスコアの悪化につながります。これは、何百もの画像がリソースを奪い合う商品一覧ページで最もよく見られます。
ステップ1：速度のためにHTMLのimage要素を最適化する
src属性
画像のURLを指定します。ブラウザに画像の場所を伝えるための必須の属性です。
width属性とheight属性
画像の幅と高さをピクセル単位で指定します。これらは画像コンテナのサイズと、画像がその中にどのように収まるかを定義するため、ページ上で画像を正しくレンダリングするために重要です。レイアウトシフトを防ぐために、必ずwidthとheightの両方を設定してください。
alt属性
画像が表示できない場合の代替テキストを指定します。視覚障害のあるユーザーが画像の内容を理解するのに役立つため、アクセシビリティの観点から重要です。また、検索エンジンはaltテキストを使用して画像の内容を理解するため、SEOにも重要です。
loading属性（lazy loading）
ブラウザが画像をどのように読み込むかを指定します（lazy、eager、またはauto）。画像を非同期で必要なときにだけ読み込めるようにするため、ページのパフォーマンス向上に重要です。LCP画像には絶対にloading="lazy"を設定しないでください。2025 Web Almanacによると、16%のページが依然としてLCP画像をlazy loadしており、これはWeb上で最もよくあるパフォーマンス上の間違いの1つです。
srcset属性
sizes属性
decoding属性
fetchpriority属性
fetchpriority属性は、ページ上の他のリソースに対するリソースの取得優先度を指定します。この属性には「high」、「low」、「auto」のいずれかの値を設定できます。優先度の高いリソースは、優先度の低いリソースよりも先に読み込まれます。2026年現在、fetchpriorityはすべてのモダンブラウザ（Chrome 102以降、Safari 17.2以降、Firefox 132以降、Edge 102以降）でサポートされており、本番環境で安全に使用できます。17%のページしかLCP画像にこれを使用していないため、大多数のサイトは簡単な改善のチャンスを逃しています。
ステップ2：可能な限り早く画像のダウンロードをキューに入れる
HTMLを最適化した後にすべき2つ目のことは、画像のスケジューリングを確認することです。多くの場合、画像がLCPに悪影響を与える最大のボトルネックは、スケジューリングの遅れです。ブラウザがレンダリングプロセスの早い段階でLCP要素をダウンロードできれば、画像はできるだけ早くブラウザで利用可能になり、ブラウザはレンダリングプロセスの早い段階でその要素の描画を開始できます。
簡単に聞こえますか？では、どうすれば可能な限り早く画像のダウンロードをキューに入れられるのでしょうか。
LCP要素のプリロード
早期のダウンロードを確実にする最も効果的な方法は、画像をプリロードすることです。画像のプリロードは、<head>要素の先頭にシンプルなタグを追加するだけで実行できます。例：
<link rel="preload" as="image" href="image.jpg">
このシンプルなタグにより、ブラウザは「image.jpg」がすぐに必要になることを認識し、即座にこのファイルのダウンロードを開始します。
CoreDashで監視しているサイトでは、LCP画像をプリロードしたページ読み込みの83%がLCPで「良好」のスコアを獲得していますが、プリロードしなかった場合は65%にとどまります。
LCP要素をeager loadする
fetchpriorityにhighを使用する
何らかの理由でLCP要素をプリロードできない場合は、少なくとも要素のfetchpriority属性にhighが設定されていることを確認してください。これにより、画像がページにとって重要であることがブラウザに伝わり、ブラウザは高い優先度で画像をダウンロードします。ただし、fetchpriority="high"を使用することは、通常、画像をプリロードするほど効率的ではないことに注意してください。
ステップ3：画像が可能な限り早くダウンロードされるようにする
3つ目にすべきことは、必要以上に大きな画像のために貴重なネットワークリソースを無駄にしないようにすることです。これは、レスポンシブ画像の使用、圧縮の使用、そして新しくて高速な画像フォーマットの使用によって実現できます。
レスポンシブ画像
srcsetとsizesを使用したレスポンシブ画像の例です。
<img src="hero-800.jpg" srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w" sizes="(max-width: 600px) 100vw, 800px" width="800" height="450" alt="Descriptive alt text">
ブラウザはviewportの幅に基づいて最も適切な画像を選択します。lazy loadされるファーストビュー以下の画像については、sizes="auto"（Chrome 126以降、Edge 126以降でサポート）を使用することもでき、これによりブラウザは画像のCSSレイアウトに基づいて正しいサイズを自動的に計算します。
画像の圧縮
新しくて高速な画像フォーマット
画像は多くの場合、Webページで最大のリソースの1つであり、最適化されていないとページの読み込み速度を著しく低下させる可能性があります。WebPやAVIFなどのモダンな画像フォーマットは、同じ視覚的な品質を維持しながら、JPEGよりも大幅に優れた圧縮を提供します。
WebPは事実上すべてのブラウザでサポートされており（世界のサポート率は約99%）、通常、JPEGと比較してファイルサイズを25〜35%縮小します。AVIFはさらに優れており、JPEGより50%以上サイズを削減でき、現在94.7%のブラウザサポート（Chrome 85以降、Firefox 93以降、Safari 16.4以降）があります。それにもかかわらず、2025 Web Almanacによると、LCP画像にAVIFが使用されているのはわずか0.7%であり、JPEGが57%と依然として優勢です。これは大きな改善のチャンスです。
<picture>要素を使用して、各ブラウザがサポートする最適なフォーマットを提供してください。
<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" width="800" height="450" alt="Descriptive alt text"> </picture>
ブラウザはまずAVIFを試み、フォールバックとしてWebPを使用し、最後の手段としてJPEGを使用します。今後の動向に興味がある場合は、JPEG XLとその現在のブラウザサポート状況について読んでみてください。
ステップ4：レイアウトシフトを排除する！
読み込み中にサイズが変わる画像は、レイアウトシフトを引き起こします。理由はごく単純です。このセクションでは、最も一般的な3つの原因について説明します。画像とメディアがCLSを引き起こすすべての原因（動画、iframe、アートディレクション、レスポンシブ画像の不一致、lazy loadingなど）の完全なガイドについては、画像とメディアがレイアウトシフトを引き起こす仕組みを参照してください。
1. 画像サイズが指定されていない
2. スタイリングの問題
通常、画像がviewportより大きくなるのを防ぐには、シンプルなCSSのテクニックを使用します。
img{
max-width:100%;
height:auto;
}
これは優れたテクニックであり、使用すべきです。しかし残念ながら、レイアウトシフトを引き起こすこのテクニックの亜種を定期的に目にします。例えば、width:autoを追加した場合です。
img{
max-width:100%;
height:auto;
width:auto;
}
これにより、すべての画像がautoの幅と高さでレンダリングされます。これは通常、画像がダウンロードされる前にブラウザが画像を0x0pxでレンダリングすることを意味します。
3. プレースホルダー
一部のJavaScriptベースのlazy loadingスクリプトは、プレースホルダーを使用します。前述のmax-width:100%やheight:autoのようなCSSのテクニックを使用している場合、正方形のプレースホルダーのautoの高さは、画像のheight属性と一致しません。基本的に、画像は最初に720x720の正方形のプレースホルダーとしてレンダリングされ、最終的な画像がダウンロードされると720x180でレンダリングされます。
<img src="1x1placeholder.png" data-src="hero.png" width="720" height="180" style="height:auto;max-width:100%" >
ステップ5：main threadを保護する
次に確認すべきは、一度に多くの画像がmain threadでデコードされないようにすることです。通常は問題になりませんが、商品一覧ページ（最大500枚もの画像がリソースを奪い合うこともあります！）で何度もこのような事態が発生するのを見てきました。
対策としては、すべての画像にdecoding="async"を追加し、これらの画像が別のスレッドでデコードされるようにします。また、ファーストビュー以下の画像や非表示の画像すべてにloading="lazy"を追加して、これほど多くの画像が一度にデコードされるのを避けてください。
ステップ6：各画像に適切な戦略を選ぶ！
LCP要素の画像戦略
LCP要素は通常、最も重要な視覚要素です。そのため、これを最優先にする必要があります。
- ページのhead内の早い段階で、次のコードを使って画像をプリロードします：
<link rel="preload" as="image" href="path-to-img.png"> loading="eager"を設定するか、loading属性を省略して、この画像をlazy loadしないようにブラウザに指示します。fetchpriority="high"を使用して、この画像を高い優先度でダウンロードすべきであることをブラウザに伝えます（画像をプリロードしている場合は、この手順をスキップできます）。- この要素は非常に重要であり、main threadでデコードする必要があるため、
decoding="sync"を設定します。
以下は、プリロードを適用した最適化されたレスポンシブなLCP画像の完全な例です。
<!-- In <head> --> <link rel="preload" as="image" href="hero-800.jpg" imagesrcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w" imagesizes="(max-width: 600px) 100vw, 800px"> <!-- In <body> --> <img src="hero-800.jpg" srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w" sizes="(max-width: 600px) 100vw, 800px" width="800" height="450" alt="Descriptive alt text" fetchpriority="high" decoding="sync">
ロゴやその他の可視画像（LCP以外）の画像戦略
可視画像はページ読み込み中のかなり早い段階で読み込まれるべきですが、できればLCP要素の後に読み込まれるのが望ましいです。これはLCP要素をプリロードすることで実現できます。これにより、これらの可視画像に自然で正しいダウンロードの順序が与えられます。
loading="eager"を設定するか、loading属性を省略して、この画像をlazy loadしないようにブラウザに指示します。- この要素はmain thread外で安全にデコードできるため、
decoding="async"を設定します！
ファーストビュー以下の画像の画像戦略
ファーストビュー以下の画像はすべてlazy loadすべきです。非常にシンプルです！例外はありません！
loading="lazy"を設定して、この画像をlazy loadするようにブラウザに指示します。- この要素はmain thread外で安全にデコードできるため、
decoding="async"を設定します！
背景画像を避ける
背景画像を使用している場合は、再考する必要があります。背景画像はlazy loadできず、decodingプロパティを制御することも、fetchpriorityを設定することもできません。背景画像は通常レスポンシブではないため、おそらく多くの帯域幅を消費します。しかし最も重要なのは、背景画像は通常、ブラウザがCSSファイルをダウンロードした後に検出されるということです。これは、画像のダウンロードをトリガーするタイミングとしてはほぼ常に不適切です！背景画像が有害な理由と、選択の余地がない場合に背景画像を遅延させる方法をお読みください。
通常の画像タグとCSSのobject-fit:coverを組み合わせることで、通常の画像を背景画像として機能させることができます！
Real User Monitoringで影響を監視する
これらの最適化を適用した後、それが実際のユーザーのパフォーマンスを実際に改善しているか確認してください。Lighthouseのようなラボツールは変更が正しいことを確認できますが、訪問者への実際の影響を示してくれるのはReal User Monitoringだけです。時間の経過とともにLCP、CLS、INPを追跡し、画像の最適化が期待通りに機能していることを確認してください。
