画像最適化

TL;DR — 画像最適化とは、見た目を悪くせずに画像を小さくして、ページを速く読み込めるようにすることです。WebPのような最新形式を使い、ファイルを圧縮し、画面上で表示するサイズよりはるかに大きな画像を配信しないようにします。最も多く破られるルールは、ページ最上部の大きな画像をすぐに読み込むことです。そこだけは決して「遅延読み込み」しません。適切に行ってもランキングが魔法のように上がるわけではなく、速度スコアの合格も保証しません。ページを速くすることが目的なので、実際の結果を前後で確認してください。

画像最適化が実際に行うこと

画像は、Webページでほぼ常に最も重い要素です。Googleの公式ドキュメントも、画像について “often the largest contributor to overall page size, which can make pages slow and expensive to load.” (翻訳)「ページ全体のサイズに最も大きく寄与することが多く、ページの読み込みを遅く、高コストにする」と説明しています。つまり最適化の目的は、訪問者がダウンロードするバイト数を減らし、ページをすぐ表示することです。

意外に思われる点は、形式そのものはランキング上昇要因ではないことです。JPEGをWebPに変えても、それだけで順位は上がりません。ファイルが小さくなってページが速くなり、役立つのは速度です。これはより広いImage SEOハブの姉妹記事です。そちらはaltテキスト、ファイル名、画像検索を扱い、こちらは「速く読み込ませる」実践ガイドです。

重要なのは次の数点

• 最新形式を使う。 WebPとAVIFは、見た目を悪化させずに古いJPEGやPNGよりファイルを大幅に小さくできます。現在の安全なデフォルトはWebPです。
• 圧縮する。 WebPでも大きすぎることがあります。画像を圧縮ツールに通し、ファイルが小さく、それでも十分きれいに見える点を探します。
• 小さな場所に巨大な画像を配信しない。 画像が幅500ピクセルでしか表示されないなら、3 000ピクセルのファイルは不要です。ダウンロードの無駄になります。
• ページ下部の画像を遅延読み込みする。 loading="lazy" を追加すると、画像の近くまでスクロールするまでブラウザーが読み込みを待ちます。画面の下にある画像には有効です。
• 上部の大きな画像は決して遅延読み込みしない。 ページの初回読み込み時に見える最大の画像を、Googleは速度計測の対象にします。そこはすぐに読み込む必要があります。

多くの人が最も間違えること

ヒーロー画像を含め、すべてを遅延読み込みすることです。 「読み込むものを減らす」と聞くと賢そうですが、逆です。ページ上部の画像を基準にページ速度スコアが測られるため、遅らせるとスコアが悪化します。すぐに読み込み、重要だとブラウザーに伝えます。具体的な方法はAdvancedタブで説明します。

正確なGoogleの引用、WebPとAVIFのトレードオフ、サイズ計算、fetchpriority の方法を知りたい場合は、Advancedタブへ移動してください。

TL;DR — 画像最適化は、直接的なランキング要因ではなく、ページ速度とCore Web Vitalsのための取り組みです。形式（WebP、AVIF）はバイト数を減らしますが、SEO上の上昇効果はありません。Muellerも3通りの言い方でそう述べています。圧縮率だけでなく、透明度、アニメーション、現在のブラウザー対応状況も考慮してください。最も価値の高いルールは、LCP画像（通常はヒーロー）を決して遅延読み込みしないことです。最適化しようとしている指標そのものが遅れます。loading="eager" と fetchpriority="high" を付けますが、優先度ヒントが効くのは発見や取得タイミングがボトルネックの場合だけで、すべてのLCP問題を解決するわけではありません。ネイティブの loading="lazy" は初期ビューポートの外にある画像向けで、固定した「画面下何ピクセル」という線に使うものではありません。圧縮に普遍的な「正しい」品質値はありません。画像の種類ごとにテストしてください。正しい寸法は、レンダリングされるコンテナーサイズ × デバイスピクセル比です。コンテナーサイズ自体がレスポンシブレイアウトで変わるので、<picture> のフォールバックとともに srcset/sizes の範囲を配信します（誤った sizes 値は、気付かないまま大きすぎる画像をダウンロードさせます）。Web上で最も一般的なLCP要素は画像なので、この記事はWeb Performanceにもまたがります。しかし、これらの方法でCore Web Vitalsの合格、ランキング変更、トラフィック増加が保証されるわけではありません。前後を測定してください。

画像最適化が目指すもの（最初に神話を正す）

まず最大の神話を片付けましょう。画像形式は速度のレバーであって、ランキングのレバーではありません。 WebPやAVIFに変換しても順位上昇は得られません。得られるのは小さなファイルで、それが速いページにつながり、Core Web Vitalsに影響します。検索システムが使うのはそこです。この連鎖は実在しますが間接的であり、「次世代形式のほうが上位表示される」と短絡するのが競合ガイドの多くの誤りです。

Googleのドキュメントは、画像が速度に重要な理由を率直に説明しています。画像は*“often the largest contributor to overall page size, which can make pages slow and expensive to load,”* (翻訳)「ページ全体のサイズに最も大きく寄与することが多く、ページの読み込みを遅く、高コストにする」ものです。助言は*“apply the latest image optimization and responsive image techniques to provide a high quality and fast user experience”* (翻訳)「最新の画像最適化とレスポンシブ画像技術を適用して、高品質で速いユーザー体験を提供する」ことです。 Google Search Centralが引用のアンカーに使う表現は、「画像はページ全体のサイズに最も大きく寄与することが多い」です。 Google Search Central — Images ここでの枠組みは、ファイル形式へのランキング報酬ではなく、速いユーザー体験です。

画像SEO全体の何を、なぜ行うか — altテキスト、ファイル名、画像サイトマップ、構造化データ、画像検索ランキング — は、親記事であるImage SEOハブの役割です。この記事は形式、圧縮、サイズ、読み込み戦略という、標準となる方法を扱います。

誰もが破るルールから始める：LCP画像は決して遅延読み込みしない

このページから1つだけ持ち帰るなら、これにしてください。**Largest Contentful Paint（LCP）要素は、読み込み時にビューポートへ描画される最大のものです。web.devによれば、それは”either an image or a web font,” (翻訳)「画像またはWebフォントのいずれか」です。 このルールは、LCP画像を決して遅延読み込みしないことです。 Optimize LCP 多くのページでは、ヒーロー、注目画像、商品画像などの画像です。web.devはGoogleが何かを表現するときと同じくらい率直に、次のルールを示しています。

“Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (翻訳)「LCP画像を決して遅延読み込みしないでください。そうしないと必ず不要なリソース読み込み遅延が生じ、LCPに悪影響を与えます。」

これは、「とにかく遅延読み込みを使う」という助言が完全に見落としているニュアンスです。遅延読み込みは画面下の画像には有効です。LCP画像に適用すると、改善しようとしている指標を自分で遅らせます。web.devの遅延読み込みガイドも、反対側から同じことを言っています。“Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images” (翻訳)「ページ読み込み時にビューポート内にある可能性が高い画像、特にLCP画像は遅延読み込みしないでください」（Browser-level lazy loading）。

私自身のAhrefsのLCP記事でも同じ主張をしています。最大の要素は*「通常は注目画像、あるいは <h1> タグになる」ので、修正方法はそこから決まります。「画像が不要なら、最も効果的な解決策は単純に削除することです。必要なら、できるだけ小さく保てるようサイズと品質を最適化することを勧めます」。「すぐに必要ない画像は遅延読み込みする」*べきですが、その裏返しは、理由があるので大文字で示す厳格なルールです。「画面上部の画像を遅延読み込みしないでください！」

LCP画像に fetchpriority="high" を付ける

ヒーローを遅延読み込みしないことは必要ですが、十分ではありません。LCP画像をできるだけ早く読み込ませるには、ブラウザーに優先度をヒントとして伝えます。web.devより：

“You can hint to the browser as to which resources are most important using the fetchpriority attribute… It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (翻訳)「fetchpriority 属性を使って、どのリソースが最も重要かをブラウザーに示せます。ページのLCP要素になりそうな <img> 要素には fetchpriority=\"high\" を設定するとよいでしょう。」

<img src="/hero.webp" alt="…" fetchpriority="high" width="1200" height="675">

LCPについての記事では、fetchpriority="high" を*「<img> または <link> タグで使え、ブラウザーに画像を早く取得させる」*ものとして説明し、メインHTMLが届く前に取得を始める補完策としてEarly Hints（103レスポンス）と組み合わせています。したがってLCPの手順は、早期読み込み + fetchpriority="high"（スタックが対応していればEarly Hints）です。ページの他の画像は遅延読み込みできます。

fetchpriority とpreloadは、保証された修正策ではなく、ボトルネックに応じたツールとして扱ってください。LCP画像の発見や取得が遅い場合には役立ちますが、サーバーの応答が遅い場合、画像より前にレンダリングをブロックするリソースがある場合、またはファイル自体が本当に大きすぎる場合には何もしません。優先度ヒントだけで数値が動くと考える前に、実際のボトルネックを確認してください（PageSpeed InsightsやLighthouseはLCPをサブパートに分解します）。

ネイティブの loading="lazy" — 無料で簡単、画面下では正しい

初期ビューポートにないすべての画像では、ネイティブの遅延読み込みがパフォーマンス改善の最も簡単な方法です。web.devは、*「loading 属性を使えば、独自の遅延読み込みコードや別のJavaScriptライブラリを書かずに画像を遅延読み込みできます」*と説明しています。

<img src="/below-the-fold.webp" alt="…" loading="lazy" width="800" height="600">

安全に使うためのポイントは2つです。

• 固定した「画面下」ラインではなく、初期ビューポートを基準にする。 「画面下」は固定ピクセル数ではなく、ビューポートのサイズとレイアウトで変わります。実際の判定は、ページが最初に描画されたとき画像が見える可能性が高いかどうかです。そうした画像、特にLCP画像には loading="eager"（デフォルト）を使い、lazy は使いません。
• JSのハックよりネイティブ属性を優先する。 実際のURLを data-src に隠し、src を一度も公開しないJavaScript遅延ローダーは、まったくインデックスされないリスクがあります。ネイティブの loading="lazy"（または適切なIntersectionObserver）なら、クローラーから src が見えます。親記事のImage SEOハブで、このインデックス上の注意点を詳しく説明しています。

最新形式：WebPとAVIF、JPEG/PNGの比較

形式は神話を正すうえで最も重要な部分なので、それぞれがもたらすものを正確に見ましょう。得られるのはランキングではなく、バイト数の削減です。

• WebP — “often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression” (翻訳)「JPEG、PNG、GIFより圧縮率が高いことが多く、非可逆圧縮と可逆圧縮の両方を提供する」。 アンカーされる表現は WebP often has better compression (翻訳)「WebPは圧縮率が高いことが多い」です。 web.dev — Image performance JPEGよりおおむね25–35 %小さく、ほぼすべてのブラウザーが対応しています。現在の写真向け安全なデフォルトです。
• AVIF — “supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (翻訳)「非可逆圧縮と可逆圧縮の両方に対応し、場合によってはJPEGと比べて50 %を超える削減がテストで示されている」。圧縮は最上級ですが対応の普遍性はやや低いため、WebPまたはJPEGのフォールバックと組み合わせます。
• JPEG — 写真向けの普遍的なフォールバックです。
• PNG — 透明度や輪郭の鋭いグラフィックが必要な場合に使います。
• SVG — ロゴやアイコン向けです。ベクターなので無限に拡大縮小でき、非常に小さくなります。

どの形式を選ぶかは、最も強く圧縮できるかだけでなく、画像が何をする必要があるかにも左右されます。透明度、アニメーション、ブラウザーやツールがその組み合わせをどれだけ一貫してサポートするかは、上記の生のサイズ削減とともに判断材料になります。特にアニメーションを使う場合は、形式をデフォルトに決める前に、必要な機能の現在の対応状況を確認してください。

Google Searchは、<img> の src で参照される*「BMP、GIF、JPEG、PNG、WebP、SVG、AVIF」*に対応しています。<picture> を使い、最新形式を適切なフォールバック付きで配信します。

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="…" width="1200" height="800" loading="lazy">
</picture>

最後の <img src> が安全網です。古いブラウザーやクローラーはそこへフォールバックし、Googleが実際にインデックスするURLもそこです。

形式はランキングに影響するか？（いいえ — Muellerが3通りで説明）

これは、テーマ全体を通して引き出す価値のある、唯一の神話解体の筋道です。時期の異なる3つのJohn Muellerの発言は、すべて同じ結論に至ります。形式はクロールやインデックスの仕組みとページ重量には影響するが、ランキングに直接影響しないということです。

1. AVIFにSEO上の上昇効果はない。 GoogleがAVIFのネイティブ対応を追加した後、Muellerは、対応している他形式よりAVIFを使っても*「SEO上の上昇効果」*はないと確認しました（SE Roundtable coverage）。
2. WebPは「問題ない」。 「WebP画像は画像検索に問題ありません」 — 重要なのは「より良い」ではなく「問題ない」という表現です（SE Roundtable coverage）。
3. WebPのインデックス上の癖は形式固有ではない。 WebPファイルがGSCで「クロール済み — 現在インデックス未登録」と表示されたとき、Muellerの指摘は、画像ファイルはHTMLページとしてインデックスされず、その現象がWebPに限られるとは考えていない、というものでした（SEJ coverage）。

圧縮と品質：「正しい」設定は1つではない

画像ガイドで最もよくある悪い助言は、「80 %に圧縮する」という1つの箇条書きです。web.devは、そのような魔法の数値はないと明確にしています。

“When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (翻訳)「圧縮時に、すべてのケースに適した普遍的な設定はありません。画像品質とファイルサイズのよい妥協点が見つかるまで、異なる圧縮レベルを試す方法が推奨されます。」

実際には、画像の種類ごとにテストします。 写真は強い非可逆圧縮にもよく耐えますが、グラフィック、ロゴ、文字入りのスクリーンショットはすぐにアーティファクトが現れ、可逆圧縮または高い品質設定を必要とすることが多いです。1つのスライダーを信じる代わりに、同じ画像を2〜3段階の品質で書き出し、実際の表示サイズで見比べます。元画像と見分けられない最小のものが、画像ごとの答えです。これは「TinyPNGに通して祈る」方法ではなく、実際のワークフローです。

正しい寸法：コンテナーサイズ × デバイスピクセル比

「とにかく小さくする」がルールではありません。レンダリングサイズ × デバイスピクセル比（DPR）に合わせることがルールです。web.devより：

“An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (翻訳)「500ピクセル×500ピクセルのコンテナーに表示される画像は、500ピクセル×500ピクセルが最適なサイズです。」

“If the device has a DPR of 2 and the image is displayed in a 500 pixel by 500 pixel container, then a square 1000 pixel image… is now the optimal size.” (翻訳)「デバイスのDPRが2で、画像が500ピクセル×500ピクセルのコンテナーに表示される場合、1,000ピクセル四方の画像が最適なサイズになります。」

つまり、2×（Retinaクラス）のディスプレイ上の500×500コンテナーには、1 000×1 000のソースが必要です。それより大きくすると目に見える効果なしにバイト数を浪費し、小さくすると高DPR画面でぼやけます。そのため、srcset + sizes を使ってサイズの範囲を配信し、ブラウザーに選ばせます。

<img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 500px"
  alt="…" width="800" height="600" loading="lazy">

ブラウザーはコンテナーの幅（sizes）と自身のDPRを読み取り、srcset から適切な候補を選びます。これは上記のDPR計算をレスポンシブ配信にしたものです。Googleはレスポンシブ画像に <picture> または srcset を推奨し、“always specify a fallback URL using the src attribute.” (翻訳)「src 属性を使ってフォールバックURLを必ず指定する」と述べています。

sizes を間違えても警告は出ません。宣言した値が画像の実際の表示幅と一致しない場合（レイアウトやCSS変更後によく起こります）、ブラウザーはそれを知る方法がなく、与えられた不正確な数値に基づいて候補を選びます。通常はレイアウトが必要とするより大きなファイルをダウンロードし、上記の形式・圧縮の作業を気付かないうちに台無しにします。確実に検出するには、DevToolsのNetworkパネルを開き、画像リクエストを見つけ、配信ファイルの寸法とコンテナーの実際の表示幅を比較します。

上の500×500の例は説明用であり、サイト全体にハードコードする数値ではありません。同じヒーロー画像でも、モバイルとデスクトップでは異なる幅で表示されます。つまり「コンテナーサイズ」はレスポンシブレイアウトに合わせて動き、固定ではありません。だからこそ、1つの「最適」サイズを書き出して終わりにせず、srcset の範囲を配信します。

これらすべてがCore Web Vitalsにつながる理由

上で説明したすべての技術をつなぐ軸はLCPです。画像はWeb上で最も一般的なLCP要素であり、LCPは3つのCore Web Vitalsの1つです。Googleの目標は、モバイルとデスクトップのページ読み込みの75パーセンタイルで、“LCP should occur within 2.5 seconds” (翻訳)「LCPは2.5秒以内に発生すべき」ことです。 ページのアンカー表現は、「Core Web VitalsはすべてのWebページに適用されるWeb Vitalsの一部」です。 web.dev — Vitals Core Web Vitalsは*“apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.”* (翻訳)「すべてのWebページに適用され、すべてのサイト所有者が測定すべきもので、Googleのすべてのツールに表示される」ものです。

したがって画像最適化は個別のランキング要因ではなく、検索システムが使うページ体験シグナル（Core Web Vitals）への寄与要因です。この区別が正確な枠組みであり、この記事がImage SEOクラスターとWeb Performanceクラスターの両方に属する理由です。指標そのものを詳しく知りたい場合は、Web PerformanceのCore Web VitalsとLCPを参照してください。

もう1つ、率直に述べておくべき注意があります。このページの修正で何かが保証されるわけではありません。画像のバイト数はLCPを構成する可能性のある要素の1つにすぎません。web.dev自身のLCPサブパートの内訳には、サーバー応答時間や画像より前にあるレンダリングブロックリソースなどが含まれ、形式や圧縮では触れられません。画像の寸法もCLSへの入力の1つであって、特定スコアの保証ではありません。ヒーロー画像を小さくすると測定可能な改善があるかもしれず、何も変わらないかもしれず、別のものが本当のボトルネックなら数値がほとんど動かないかもしれません。画像最適化だけでCore Web Vitalsの合格、ランキング変更、トラフィック増加、コンバージョン増加、AI検索での引用が保証されることもありません。それらは画像バイト数以上の要素に依存します。画像の修正は完了事項ではなく仮説として扱い、ラボとフィールドの両方でLCPとCLSを前後に測定してください。「最適化が効いた」という思い込みではなく、データに何かが動いたかを判断させます。

よくある実装上の落とし穴

• CSSの背景画像はインデックスされない。 開発者がレイアウトの都合で <img> を background-image に置き換えることがあります。Googleは*「<picture> 要素の子要素など、他の要素の子であっても、<img> 要素の src 属性にある画像を見つけられる」一方、「CSS画像はインデックスしない」*と説明しています。画像検索に載せたいなら、<img> に置いてください。（これはパフォーマンスに近い話ですが、よくある間違いなので取り上げます。）
• パフォーマンス/SEOの「刷新」で既存ファイルを一括リネームしない。 Muellerは、Googleのシステムがリネームした画像を再処理するには*「非常に長い時間」*がかかり、すでに文脈がよければ効果は小さいと述べています。詳しくは親記事のImage SEOハブを参照してください。
• width/heightがない。 画像の読み込み前にブラウザーがスペースを確保できるよう、固有の width と height（またはCSSの aspect-ratio）を必ず設定します。これは画像によるレイアウトシフトを減らしますが、CLSを構成する複数の入力の1つであり、特定スコアの保証ではありません。

簡単な手順

• ヒーロー / LCP画像：最新形式、適切なサイズ、loading="eager"、fetchpriority="high"。
• 画面下にあるものすべて：loading="lazy"。
• <picture> の src フォールバック付きでWebP/AVIFを配信する。
• コンテナー × DPRに合わせ、sizes 付きの srcset 範囲を配信する。
• 画像の種類ごとに圧縮する。2〜3段階の品質をテストし、1つのスライダーを信じない。
• width/height を必ず設定する。

画像SEOの残り — altテキスト、ファイル名、画像サイトマップ、構造化データ、画像検索ランキング — については、Image SEOハブに戻ってください。

AIによる要約

Advanced版の要点をまとめます。

• 画像最適化は速度のためであり、ランキングのレバーではない。 形式（WebP/AVIF）を選ぶとバイト数が減り、ページが速くなり、Core Web Vitalsが改善します。形式自体に直接のランキング上昇効果はありません。Muellerも、AVIFには「SEO上の上昇効果がない」、WebPは「問題ない」、WebPのインデックス上の癖は形式固有ではないと、3通りで確認しています。
• 第1ルール：LCP画像を決して遅延読み込みしない。 ページが最初に描画されるとき見える可能性が高い画像（通常はヒーロー）がLCPを決めます。それを遅延読み込みすると、修正しようとしている指標自体が遅れます。loading="eager" + fetchpriority="high"（任意でEarly Hints）を使います。ただし優先度ヒントが直すのは発見・取得タイミングのボトルネックだけです。ヒントだけで解決すると考える前に、LCPのサブパートを確認してください。
• ネイティブの loading="lazy" は無料で正しい。 初期ビューポートの外にある画像に使うもので、固定した「画面下」ピクセル線に使うものではありません。URLを data-src に隠すJS遅延ローダーは避けます。
• 形式： WebPは安全なデフォルト（JPEGより約25–35 %小さい）です。AVIFはフォールバック付きでさらに圧縮できます（テストによっては50 %以上）。ただし選択は圧縮率だけでなく、透明度、アニメーション、現在のブラウザー/ツール対応にも左右されます。<img src> のフォールバックを含む <picture> で配信し、Googleがインデックスできるようにします。
• 圧縮： 普遍的な「正しい」品質はありません。画像の種類ごとにテストします（写真は強く圧縮でき、文字やグラフィックはすぐにアーティファクトが出ます）。
• サイズ： 正しいサイズ = レンダリングされるコンテナーサイズ × デバイスピクセル比（500pxのコンテナーでDPR 2なら1 000pxのソース）です。コンテナーサイズ自体もレスポンシブレイアウトで動くので、固定した1つの書き出しではなく、srcset + sizes で範囲を配信します。誤った sizes 値は、気付かないままブラウザーに大きすぎる候補をダウンロードさせます。
• 重要な理由： 画像は最も一般的なLCP要素で、LCPの目標は75パーセンタイルで2,5秒です。そのためこの記事はWeb Performanceにもまたがりますが、LCPには画像バイト数だけでは直せない他のサブパート（サーバー応答時間、レンダリングブロックリソース）もあります。
• 保証はない： 画像最適化だけでCore Web Vitalsの合格、ランキング変更、トラフィック増加、コンバージョン増加、AI検索での引用が保証されるわけではありません。ラボとフィールドの両方でLCP/CLSを前後に測定します。
• 落とし穴： CSSの background-image はインデックスされません。ファイルを一括リネームせず、width/height を必ず設定します。レイアウトシフトは減らせますが、特定のCLSスコアは保証しません。

公式ドキュメント

検索エンジンとChromeチームによる一次資料です。

Google / web.dev

• Image performance (web.dev “Learn Performance”) — 形式、「普遍的な圧縮設定はない」という点、DPRのサイズ計算。
• Browser-level image lazy loading (web.dev) — ネイティブの loading="lazy" の仕組みと、「ビューポート内/LCP画像は遅延読み込みしない」という例外。
• Optimize LCP (web.dev) — fetchpriority、LCPリソースが画像またはフォントであること、「LCP画像を決して遅延読み込みしない」というルール。
• Fetch Priority API (web.dev) — LCP画像向け fetchpriority="high" の詳しい解説。
• Web Vitals (web.dev) — Core Web Vitalsの定義と、LCPが75パーセンタイルで2,5秒以下という基準。
• Google Images best practices — 対応形式、<img>/<picture> のインデックス（CSS背景ではない）、レスポンシブ画像、フォールバック src の推奨。

Bing / Microsoft

• Bingは、Googleほど詳細な画像最適化専用の技術ガイドを公開していません。関連する助言は一般的なBing Webmaster Guidelinesにあり、画像の重量を含むページ速度を考慮事項として扱っています。存在しないBingの「引用」を作らず、この点は正直に示します。
• Bing Visual Search — オブジェクトレベルのビジュアル検索。画像の発見に関係するもので、形式や圧縮によるページ速度の効果とは別です。

ソースからの引用

GoogleのChromeチームとSearch Advocatesによる、記録に残る発言です。ページに引用箇所が表示される場合、リンクは引用部分へ移動するディープリンクになっています。

web.dev（Google Chromeチーム）— LCPのルール

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (翻訳)「LCP画像を決して遅延読み込みしないでください。そうしないと必ず不要なリソース読み込み遅延が生じ、LCPに悪影響を与えます。」 引用へ移動
• “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.” (翻訳)「ページ読み込み時にビューポート内にある可能性が高い画像、特にLCP画像は遅延読み込みしないでください。」 引用へ移動
• “It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (翻訳)「ページのLCP要素になりそうなら、<img> 要素に fetchpriority=\"high\" を設定するとよいでしょう。」 — web.dev, Optimize LCP。

web.dev（Google Chromeチーム）— 形式、圧縮、サイズ

• “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (翻訳)「WebPはJPEG、PNG、GIFより圧縮率が高いことが多く、非可逆圧縮と可逆圧縮の両方を提供します。」 引用へ移動
• “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (翻訳)「AVIFは非可逆圧縮と可逆圧縮の両方に対応し、場合によってはJPEGと比べて50%を超える削減がテストで示されています。」 — web.dev, Image performance。
• “When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (翻訳)「圧縮時に、すべてのケースに適した普遍的な設定はありません。画像品質とファイルサイズのよい妥協点が見つかるまで、異なる圧縮レベルを試す方法が推奨されます。」 — web.dev, Image performance。
• “An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” … “If the device has a DPR of 2 … then a square 1000 pixel image … is now the optimal size.” (翻訳)「500ピクセル×500ピクセルのコンテナーに表示する画像は500ピクセル×500ピクセルが最適です。デバイスのDPRが2なら、1,000ピクセル四方の画像が最適なサイズになります。」 — web.dev, Image performance。

Google Search Central — 画像が速度に重要な理由

• “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” (翻訳)「画像はページ全体のサイズに最も大きく寄与することが多く、ページの読み込みを遅く、高コストにすることがあります。」 引用へ移動

web.dev — Core Web Vitalsの説明

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (翻訳)「Core Web VitalsはすべてのWebページに適用され、すべてのサイト所有者が測定すべきもので、Googleのすべてのツールに表示されます。」 引用へ移動

John Mueller、Google — 形式はランキングのレバーではない

• AVIFについて：AVIFファイルを使っても**「SEO上の上昇効果」はありません**。 報道
• WebPについて：“WebP images are fine for Image Search.” (翻訳)「WebP画像は画像検索に問題ありません。」 報道

画像最適化チェックリスト

パフォーマンスが重要なページで、この手順を実行します。

• LCP画像（通常はヒーロー、注目画像、最初の商品画像）を特定した。
• LCP画像を遅延読み込みしていない。デフォルトの loading="eager" を使っている。
• LCP画像に fetchpriority="high" がある（スタックが対応していればEarly Hintsも検討する）。
• 画面下にあるすべての画像に loading="lazy" がある。
• 最新形式を配信している（WebPをデフォルトとし、対応していればAVIF）。<picture> に src フォールバックがある。
• 各画像をコンテナー × デバイスピクセル比に合わせている。500pxの場所に3 000pxのファイルを置いていない。
• 表示幅が異なる場所では、srcset + sizes でレスポンシブ配信している。
• 圧縮を画像の種類ごとにテストしている（表示サイズで2〜3段階の品質を比較）。一括設定ではない。
• レイアウトシフト（CLS）を減らすため、すべての画像に固有の width と height（またはCSSの aspect-ratio）を設定している。特定スコアの保証ではない。
• コンテンツ画像がCSSの background-image にしか存在しない状態ではない（CSS画像はインデックスされない）。
• 遅延読み込みにネイティブ属性（または適切なIntersectionObserver）を使っており、URLを data-src に隠すJSハックではない。
• フィールドでLCPを確認した（CrUX / PageSpeed Insights）。75パーセンタイルで2,5秒以下を目標にしている。

画像最適化チートシート

レバー — それぞれが行うこととベストプラクティス

早見表

• 形式はランキングではなく速度のレバーです。MuellerによればAVIFに「SEO上の上昇効果」はなく、WebPは「問題ない」だけです。
• WebPはJPEGより約25–35 %小さく、AVIFはテストで50 %以上小さくなることがよくあります。
• 最も価値の高いルールは、LCP画像を決して遅延読み込みしないことです。
• LCPの目標： 75パーセンタイルで2,5秒以下（モバイル + デスクトップ）。
• 対応形式：BMP、GIF、JPEG、PNG、WebP、SVG、AVIF。
• 正しいサイズ = レンダリングされるコンテナーサイズ × デバイスピクセル比。

LCPスコアを損なう間違い

ヒーロー画像を遅延読み込みすることは、この記事で扱う中で最もコストの高い間違いです。残りに進む前に、これだけを取り上げる価値があります。

• 誤り： 画面上部にある最大の画像（通常はヒーロー、注目画像、最初の商品画像）に loading="lazy"（またはJS遅延ローダー）を適用する。 なぜ誤りか： その画像はほぼ常にLCP要素であり、web.devも、遅延読み込みは*「必ず不要なリソース読み込み遅延を生じ、LCPに悪影響を与える」*と明言しています。改善しようとした指標自体を遅らせることになります。 代わりに行うこと： LCP画像に loading="eager"（デフォルト）と fetchpriority="high" を付け、loading="lazy" は画面下のすべての画像に限定する。

すべてに同じ圧縮設定を適用する

• 誤り： 内容に関係なく、すべての画像を同じ「80 %に圧縮」プリセットに通す。 なぜ誤りか： web.devは*「すべてのケースに適した普遍的な設定はない」*と明言しています。写真用に調整したプリセットは、ロゴ、スクリーンショット、文字の多いグラフィックを過度に圧縮し、目に見えるアーティファクトを生みます。 代わりに行うこと： 同じ画像を2〜3段階の品質で書き出し、実際の表示サイズで比較する。画像の種類ごとに、元画像と見分けられない最小のものを選ぶ。

コンテナーではなく手元のファイルを基準に画像サイズを決める

• 誤り： 実際の表示場所に画像を合わせず、元ファイルの解像度をそのまま配信する、またはすべてのレイアウトで固定サイズを使う。 なぜ誤りか： web.dev自身の計算では、正しいサイズはレンダリングされるコンテナーサイズ × デバイスのピクセル比です。DPR 2の500×500コンテナーには、500×500でも3 000×3 000でもなく、1 000×1 000のソースが必要です。大きくすると目に見える効果なしにバイト数を浪費し、小さくすると高DPR画面でぼやけます。 代わりに行うこと： sizes 付きの srcset 範囲を配信し、ブラウザーがコンテナーとデバイスに合う候補を選べるようにする。

本物のコンテンツ画像をCSSの背後に隠す

• 誤り： レイアウトの都合で <img> を background-image に置き換える。 なぜ誤りか： Googleは*「CSS画像をインデックスしない」*ため、最適化されていても background-image にしか存在しないコンテンツ画像は画像検索から見えません。 代わりに行うこと： コンテンツ画像は <img>（または <picture> 内の <img> フォールバック）に置き、CSS背景は純粋に装飾的な処理に限定する。

マークアップを節約するためにwidth/heightを省略する

• 誤り： <img> タグから固有の width と height（またはCSSの aspect-ratio）を外す。 なぜ誤りか： 画像の読み込み前にブラウザーがレイアウトのスペースを予約できず、画像が到着するたびにページが動きます。LCPと並ぶCore Web VitalであるCLSを悪化させます。 代わりに行うこと： 形式やサイズも最適化している画像を含め、すべての画像に width/height（または aspect-ratio）を必ず設定する。

メンタルモデル

1. LCP画像は決して遅延読み込みしない。 このテーマ全体で最も価値の高いルールです。画面上部で最大の要素（通常は画像）がLCPの計測対象です。遅延読み込みしても何も節約できず、最適化しようとしている指標を遅らせるだけです。ページの他の画像は loading="lazy" の候補ですが、LCP画像は決してそうしません。

2. 普遍的な圧縮設定はない。 「どの品質で圧縮すべきか」はサイト全体の方針ではなく、画像ごとの問いとして扱います。写真は強い非可逆圧縮に耐えますが、文字の多いグラフィックやスクリーンショットは耐えません。ワークフローは比較です。2〜3段階の品質で書き出し、表示サイズで目視します。一度設定して忘れる単一のスライダーではありません。

3. 正しいサイズ = コンテナーサイズ × デバイスピクセル比。 「小さいほどよい」がルールではなく、一致させることがルールです。最適なソースの寸法は、画像が実際に表示されるサイズにデバイスのピクセル比を掛けたものです。DPR 2の500×500コンテナーなら1 000×1 000のソースが必要です。すべての画像の書き出しサイズを決める公式であり、1つの固定ファイルではなく srcset で範囲を配信する理由でもあります。

4. 形式は速度のレバーであって、ランキングのレバーではない。 この連鎖を正しく理解します。形式の選択 → 小さなファイル → 速いページ → より良いCore Web Vitals → ランキングシステムが使うシグナルです。「次世代形式のほうが上位表示される」と短絡するのは、この話題で競合ガイドが最もよく犯す間違いです。Muellerは形式そのものに直接のSEO上の上昇効果はないと、3回別々に述べています。

画像主導のページ速度を測る継続KPI

これは画像最適化の取り組みが実際に成果を出しているかを示す継続的な数値です。今週リサイズまたは変換した1枚の画像だけとは切り離して考えます。

自分でテスト：画像最適化

形式、圧縮、サイズ、読み込み戦略についての短い5問です。それぞれ答えを選んでから、確認してください。

変更履歴