ブログの画像圧縮はSEOに効く？どこまでやるかは最初の1枚で決める

ブログの画像は、検索順位のためではなく、記事を開いた読者を待たせないために軽くします。 スマホの写真をそのまま貼っていて「画像が重いとSEOに悪い」と聞いた人、圧縮プラグインを入れるか過去の画像を全部作り直すか迷っている人に向けた記事です。 読み終えるころには、どこまでやれば十分で、どこから先は手を止めていいかが分かります。

画像を直す記事を「どれから」選ぶかを決めたいなら、そこを手伝う道具もあります。記事の最後に書きます。

画像を圧縮すると、検索順位は上がるのか

先に答えを書くと、画像を圧縮すると順位が上がる、とは私が確認したGoogleの公式ページには書かれていません。2026年10月7日に、画像と速度に関係する検索セントラルの4ページ(画像SEOのベストプラクティス、ページエクスペリエンス、Core Web Vitals、遅延読み込み)を取得して確かめました。

いちばん近いのは、Google 画像検索 SEO ベスト プラクティスの「速度と画質を考慮して最適化する」という節です。

一方、画像が原因で全体的なページサイズが大きくなり、ページの読み込みが遅く、通信費が高くなる場合がよくあります。最新の画像最適化技術やレスポンシブ画像技術を使用して、良質で高速なユーザー エクスペリエンスを提供するようにしてください。

英語版では "images are often the largest contributor to overall page size"(画像はページの大きさのいちばんの要因であることが多い)と、もう少し強く書かれています。どちらも、理由として挙がっているのは読み込みの遅さと通信費、つまり読者の側の負担で、順位の話ではありません。

順位との接点があるとすれば、Core Web Vitalsです。ページエクスペリエンスのページのよくある質問には「Google のランキング システムでは Core Web Vitals が使用されます。」とあり、画像の重さはこのうちの読み込みの指標に響きます。同じ質問の答えには、こうも書かれています。

このスコアは、サイトの全体的なユーザー エクスペリエンスの改善に役立てるためのものなので、SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう。

ですからこの記事では、画像を軽くすることを「読者を待たせないための作業」として扱い、点数を満点にするところまでは追いかけません。速度そのものがどこまで順位に効くかはページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つに、ページエクスペリエンスの要素の整理はページエクスペリエンスは順位に効く？に分けて書きました。

画像が重いと遅くなるのは、最初に大きく見える部分

Core Web Vitalsのうち、画像がいちばん関わるのはLCP(Largest Contentful Paint)です。web.dev の LCP のページによると、ページを開いてから、画面の中でいちばん大きな画像や文字の塊が表示されるまでの時間です。目安の時間は、Core Web Vitals のページには「優れたユーザー エクスペリエンスを提供するには、ページの読み込み開始から 2.5 秒以内に LCP を実現するようにします。」とあります。

同じweb.devのページでは、対象になる要素の最初に <img> 要素が挙がっています。ブログなら、記事を開いてすぐ目に入るアイキャッチや1枚目の写真がLCPになりやすい、ということです。逆に、スクロールしないと見えない5枚目の画像は、重くても最初の表示の時間には入りにくいと考えられます。

圧縮しても、LCPが縮まらないことがある

もう1つ知っておきたいのは、画像を軽くしただけではLCPが縮まらない場合があることです。web.dev の Optimize Largest Contentful Paintは、LCPの時間を4つに分けています。サーバーが最初の応答を返すまで、画像の読み込みが始まるまで、画像を読み込んでいる間、読み込み終わってから表示されるまで、の4つです。画像の圧縮で短くなるのは、このうち3つ目だけです。

同じページには、圧縮しても効かなかった例が載っています(英語版から引きます。日本語版はAIによる翻訳と注記されているためです)。

if you reduced the file size of our image by compressing it more or switching to a more optimal format (such as AVIF or WebP), that would reduce the resource load duration, but it wouldn't actually improve LCP because the time would just shift to the element render delay subpart

私の訳では「画像をさらに圧縮したり、AVIFやWebPのようなより適した形式に変えたりしてファイルを小さくすると、画像の読み込み時間は縮むが、LCPは実際には良くならない。縮んだ時間が、表示されるまでの待ち時間に移るだけだからだ」です。この例のページでは、JavaScriptの読み込みが終わるまで画像が隠されていました。同じページは、よく最適化されたページの目安として、画像を読み込んでいる時間をLCP全体の4割ほどとしています。圧縮はLCPの一部にしか効かない作業だと分かっていれば、どこで手を止めるかも決めやすくなります。

どこまでやればいいか、4つで止める

ここからが本題です。私は次の4つを、上から順にやれば十分だと考えています。上の2つはすべての画像に関わる作業、3つ目は設定を1回決めるだけ、4つ目は「最初の1枚」だけでいい作業です(公式の手順ではなく、上の公式ページとweb.devの記述から私が組んだ順番です)。

1. 寸法を、表示される幅の2倍程度までに縮める

最初にやるのは、圧縮の前に画像の寸法そのものを小さくすることです(web.devも最初の最適化として挙げています)。特にスマホで撮った数千ピクセルの写真では、ここがいちばん効きます。web.dev の Image performanceは、最初にやる最適化として画像を正しい寸法で表示することを挙げ、500×500ピクセルの枠に表示するなら500ピクセルが最適で、1,000ピクセルの画像は必要な大きさの2倍だ、と説明しています。そのうえで、画面の1ピクセルを2つの点で描く端末(デバイスピクセル比が2)なら1,000ピクセル、3なら1,500ピクセルが最適になる、とも書いています。

ブログに当てはめると、本文の幅の2倍程度を上限にするのが私の目安です(web.devの数字ではありません)。たとえばこのブログの本文の枠は最大800ピクセルなので、800 × 2 = 1,600 ピクセルが目安です。スマホでは本文の枠がこれより狭くなるので、画面の解像度が高い端末でも、この目安でたいてい足りると私は見ています(端末ごとに測ったわけではありません)。スマホで撮った写真は横幅が数千ピクセルあることが多いので、ここを縮めるだけでファイルは大きく軽くなります。自分のブログの本文の幅は、テーマの設定か、ブラウザで画像を右クリックして「検証」を開くと確かめられます。

ただしアイキャッチ(og:image)は、検索結果での表示のために大きめの画像がすすめられているので、縮めすぎないでください(アイキャッチはSEOに効く？)。

2. 形式をWebPなどにする

画像SEOのページには、Google検索が対応している形式として「BMP、GIF、JPEG、PNG、WebP、SVG、AVIF」が並んでいます。WebPやAVIFにしたから検索で有利になる、とは書かれていません。形式を変える理由は、あくまでファイルを小さくするためです。

web.devは "Modern image formats like WebP and AVIF may provide better compression than PNG or JPEG"(WebPやAVIFは、PNGやJPEGより圧縮が効くことがある)と書いています。「必ず小さくなる」ではありません。実際、このブログの画像で測ると、同じ画像でAVIFのほうがWebPより大きくなった例がありました(下の「このブログの画像」に数字を書きます)。形式を変えたら、変える前と後のファイルサイズを一度は見比べてください。WordPressなら画像を変換するプラグイン、はてなブログやnoteなどのサービスなら、サービス側が変換しているかどうかを確かめるところからです。

3. 画質は、数枚を見比べて決める

「画質は何%にすればいいか」という数字を探す人は多いですが、web.devはこう書いています。

When compressing, there isn't a universal setting suitable for all cases.

私の訳では「圧縮するとき、どんな場合にも合う設定はない」です。続けて、圧縮の強さを変えて試し、画質とファイルサイズの折り合いがつくところを探すのがすすめられています。画質を落とす圧縮(非可逆圧縮)は、細かい模様の多い写真では崩れが目立ちにくく、文字や線のくっきりした画像では効きにくいことがある、とも書かれています。自分のブログによくある画像を写真とスクショで1枚ずつ選び、圧縮の強さを変えて見比べ、文字が読める範囲でいちばん軽い設定を1回決める。あとはその設定のまま使えば十分です。参考までに、このブログの配信の設定は画質75です。

4. 開いてすぐ見える1枚は、遅延読み込みを外す

遅延読み込み(画像が画面に近づくまで読み込まない仕組み)は、ページを軽くするためによく使われます。ただ、Google の遅延読み込みのページには、こう書かれています。

ページを開いた直後に表示される可能性が高いコンテンツには、遅延読み込みを実装しないでください。

理由として、ブラウザでの読み込みや表示に時間がかかり、読者の体験に影響しうることが挙がっています。上で書いたとおり、開いてすぐ見える1枚はLCPになりやすい画像です。アイキャッチや1枚目の画像に loading="lazy" が付いていないかを確かめ、付いていれば外します。テーマやプラグインによっては、1枚目だけ遅延読み込みから外す設定や、優先して読み込ませる設定(fetchpriority="high")を持っているものもあります。

あわせて、画像のタグに幅と高さ(width と height)が書かれているかも見ます。web.dev の遅延読み込みの記事は、画像の場所をあらかじめ空けて表示のずれを避けるために "we recommend adding width and height attributes to all <img> tags."(すべての画像タグに幅と高さを付けることをすすめる)と書いています。表示のずれはCore Web VitalsのCLSという指標で測られます。

ここまでの4つで、画像の作業は止めてかまいません。PageSpeed Insightsに画像の指摘がまだ残っていても、SEOのためだけに満点を目指す作業は、上で引いたとおり公式自身が「有効な時間の使い方とは言えない」と書いています。手が空いたら、画像よりも、検索から読まれている記事の中身やタイトルのほうへ時間を回すほうが返ってくる、と私は考えています。どの記事に手を入れるかを決めるところは、機械に任せることもできます。

過去の記事の画像は、全部やり直すべきか

全部やり直す必要はない、と私は考えています。上の4つを、まずこれから書く記事で守ります。過去の記事は、検索から読まれている記事の、開いてすぐ見える1枚だけを先に直します。スクロールしないと見えない画像は、最初の表示の時間には入りにくいからです。

もう1つの理由は、直した効果がSearch Consoleで見えないことがあるからです。Core Web Vitalsのレポートは実際の読者のデータで作られるので、アクセスの少ないブログでは「データがありません」になることがあります。その仕組みはウェブに関する主な指標レポートの見方は？URLグループとデータなしに書きました。効果を確かめられないまま何百枚も作り直すより、新しい記事で守るほうが確実です。

自分の記事で、重い画像を確かめる手順

どの画像から直すかは、次の手順で見当をつけられます。

1. 検索から読まれている自分の記事を1本選び、PageSpeed Insightsにその記事のURLを入れる
2. 結果の診断の中から、LCPの要素(またはLCPの内訳)を探す。画像なら、どの画像かが表示される
3. その画像のファイルサイズと寸法を確かめる。寸法が本文の幅の2倍を大きく超えていれば、手順1(寸法を縮める)から
4. その画像に遅延読み込みが付いていないかを、記事のソースで確かめる(手順4)

LCPの要素が画像ではなく見出しや文字だった場合は、画像を軽くしてもLCPはあまり変わらないと考えられます。PageSpeed Insightsの数字とSearch Consoleの数字が違うものを見ている話はページ表示速度はSEOに効くかの「測り方」にまとめています。

このブログの画像は、元のファイルは重いまま

正直に書くと、このブログの記事に入れている図は、元のファイルは重いPNGのままです。2026年10月7日に数えると、ブログの画像フォルダのPNGは287枚あり、アイキャッチ(1,200×630ピクセル)が168枚、本文の図(1,536×1,024ピクセル)が119枚でした。たとえば「タイトルの文字数」の記事の図は、元のファイルが1,560,984バイト(約1.6MB)あります。

その代わり、配信するときに画像の変換サービスで縮めています。同じ日に、本番のサイトからこの図を取得して大きさを測りました(画質75、形式はブラウザに合わせて自動で選ぶ設定)。

828ピクセルのWebPは、元のファイルの約3%の大きさです。元の寸法のままWebPにしただけで約6%まで縮み、828ピクセルに縮めるとさらに半分以下になりました。この図はPNGの図版なので、形式と画質の変換がいちばん効いています。そして、この図ではどちらの幅でもAVIFのほうがWebPより大きくなりました。1枚の画像で測っただけなので、一般にそうだとは言えません。ただ、新しい形式にすれば必ず小さくなるわけではない、という実例にはなります。

一方で、公式のすすめ方と合っていない可能性がある点もあります。記事のタイトルの下に出すアイキャッチには、遅延読み込みが付いたままです。タイトルと説明文のすぐ下、本文より前に出る画像なので、上で引いた「ページを開いた直後に表示される可能性が高いコンテンツ」に当たりえます。このブログのLCPが悪いと測ったわけではありませんが、直す候補として控えています。

よくある質問

画像圧縮のプラグインを入れれば、SEO対策になりますか

順位が上がるとは、私が確認した公式の4ページには書かれていません。プラグインがやるのは、この記事の手順の2と3(形式と画質)が中心です。寸法を縮める設定と、1枚目を遅延読み込みから外す設定まであるかを確かめてください。

WebPにしないと、検索で不利になりますか

不利になるとは書かれていません。画像SEOのページでは、JPEGもPNGもWebPと並んで対応している形式として挙がっています。WebPにする理由はファイルを小さくするためで、寸法を縮めるほうが先です。

画質を落とすと、検索結果の画像で不利になりませんか

文字が読めないほど落とす必要はありません。画像SEOのページの同じ節は、鮮明な画像が検索結果のサムネイルで目立つことにも触れています。検索結果の画像の話はアイキャッチはSEOに効く？検索結果の画像はGoogleが選ぶに書きました。見比べて、読める範囲でいちばん軽い設定を選んでください。

画像の圧縮と一緒に、altも直したほうがいいですか

altは別の作業として考えてください。altやファイル名、遅延読み込みで画像がGoogleから隠れていないかの確かめ方は画像SEOのalt属性の書き方とファイル名にまとめています。こちらも、これから入れる画像で守れば十分です。

まとめ

• 画像を圧縮すると順位が上がる、とは私が確認したGoogle検索セントラルの4ページに書かれていない。書かれているのは、画像がページを重くし読み込みを遅くすることがよくある、という読者の体験の話
• 順位との接点はCore Web Vitals、画像なら主にLCP。ただし圧縮で縮むのはLCPの一部だけで、web.devは圧縮しても効かなかった例を挙げている
• やるのは、寸法を本文の幅の2倍程度(私の目安)までに縮める、WebPなどにする、画質は見比べて1回決める、開いてすぐ見える1枚の遅延読み込みを外して幅と高さを書く、の4つまで
• 過去の画像は全部やり直さず、新しい記事と、読まれている記事の1枚目から。点数の満点は追いかけない

次にやるのは、検索からいちばん読まれている自分の記事を1本開き、PageSpeed InsightsでLCPの要素がどの画像かを確かめることです。その1枚の寸法が本文の幅の2倍を大きく超えていたら、そこから縮めてください。

画像を直す記事も、ほかの手を入れる記事も、どれから手を付けるかの順番を決める必要があります。ここから先は、その並べ替えを機械にやらせる自作ツールの宣伝です。

サーチコンソールのエクスポートをZIPのまま置くだけで、4.0〜20.5位のページを、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分け、この順に、同じ区分の中ではCTR機会差の多い順に並べて出します。 判定と候補3記事のCTR機会差の確認、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ このツールは、画像の重さや表示速度、LCPを測るものではありません。読むのはエクスポートしたときのページごとの平均掲載順位・表示回数・CTRと、記事の本文です。画像の確かめ方は、この記事の手順でPageSpeed Insightsを使って手で行ってください。また、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。