サイトの画像を最適化してPageSpeedを上げる方法

Q: サイトの画像をすべてWebPに変換する必要がありますか？

これから追加する画像については、WebPを標準にすべきです。すでにある画像は枚数によります。画像が20枚ほどのサイトなら急いで移行する必要はありませんが、商品写真が数百枚あるECサイトなら、変換後に体感できるほど速くなります。アップロードし直す前に、変換ツールでまとめて変換しておきましょう。

Q: 遅延読み込みはSEOに悪影響がありますか？

正しく実装していれば影響しません。Googlebotは2019年から標準の遅延読み込みに対応していて、loading="lazy"で読み込まれる画像も普通にインデックスされます。唯一気をつけたいのは、LCP画像——ファーストビュー内の主要な画像——に遅延読み込みを付けないことです。付けてしまうとページでいちばん重要な要素の表示が遅れ、LCPのスコアが下がります。

表示速度は、パソコンでは2018年から、スマートフォンでは2021年から、Googleが公式に認める順位の要因です。それ以上に、コンバージョン率にも直接効きます。Google自身のデータでは、読み込みが1秒延びるごとに離脱が最大32%増えます。ECサイトについては、Portentの調査で、1秒で表示されるページは5秒かかるページの最大3倍のコンバージョンを得られるとされています。

画像はふつう、ウェブページ全体の容量の50〜80%を占めます。つまり、画像をきちんと最適化することが、どんなサイトでもいちばん効く手立てになります。

PageSpeed Insightsが画像について見ていること

Google PageSpeed Insights（PSI）はページを分析し、画像に関する問題をいくつかの項目で指摘します。よく出るのは次のものです。

「次世代フォーマットでの画像の配信」：WebPやAVIFにすればファイルを大きく減らせるところで、サイトがJPGやPNGを使っているときに出ます。
「適切なサイズの画像」：サーバーに置いた画像が、実際に表示される枠より大きいときに出ます。たとえば400pxで表示する場所に2000pxの写真を置いている場合です。
「オフスクリーン画像の遅延読み込み」：画面外にある画像が、スクロールされたときではなくページの他の部分と一緒に読み込まれているときに出ます（遅延読み込みの指摘です）。
「効率的な画像の符号化」：見た目を損なわずにまだ圧縮できる余地が残っているときに出ます。
「LCP画像」：そのページのLargest Contentful Paintがどの画像かを示します。Core Web Vitalsの指標のひとつを決める、いちばん主要な要素です。

ウェブ向け画像最適化の6原則

1. 画像の種類に合った形式を使う

圧縮に取りかかる前の時点で、形式の選択がもっとも効く判断です。

画像の種類	2026年時点の最適な形式	代わりの選択肢
写真（商品・バナー・ブログ）	WebP（非可逆）	JPG 80〜85%
ロゴ、背景が透明なアイコン	WebP（可逆）またはSVG	PNG
アイコン、ベクターイラスト	SVG	WebP・PNG
文字入りのスクリーンショット	WebP（可逆）	PNG
短いアニメーション	アニメーションWebPまたはMP4	GIF
ファビコン	.ico＋PNG（複数サイズ）	—

WebPは、見た目を同等に保ったままJPGより25〜35%、PNGより20〜30%小さいファイルを作れます。2026年時点で利用されているブラウザの97%以上が対応しており、新しいサイトでWebPを避ける技術的な理由はもうありません。

🔄 すぐできること：アップロードする前に、ImageToolsの変換ツールで手持ちのJPGやPNGをWebPにしておきましょう。手間のわりに効果がいちばん大きい一手です。

2. 見た目を犠牲にせずに圧縮する

圧縮とは、画像の寸法を変えずにファイルサイズだけを減らすことです。JPGの写真なら、品質を100%から80%に下げるだけでファイルは5〜10分の1になり、画面上での差はほぼ分かりません。ウェブではこのあたりが狙いどころです。

画像の種類ごとの、容量の目安です。

ヒーロー画像・メインバナー：200 KB未満
商品写真（ECサイト）：50〜150 KB
ブログ記事の画像：50〜120 KB
サムネイル：10〜30 KB
ロゴ（PNG／WebP）：30 KB未満
SVGアイコン：5 KB未満

今すぐウェブ用に画像を圧縮

ImageToolsの画像圧縮ツールが、JPG・PNG・WebPを無理なく軽くします。ファイルは外部のサーバーに送られず、登録も不要です。

無料で画像を圧縮

3. 実際に表示する寸法でアップロードする

もっともよくあり、しかも影響が大きい失敗がこれです。表示される枠よりずっと大きい画像を置いてしまうと、ブラウザは画像を丸ごとダウンロードしたうえで、描画のときに余分なピクセルを捨てることになります。

この失敗がどれだけむだかを示す例です。

3000×3000pxの商品写真を600×600pxの枠で表示すると、ブラウザは900万ピクセルをダウンロードして36万ピクセルしか使いません。96%がむだです。
レイアウトの最大幅が1440pxのサイトに幅4000pxのバナーを置くと、ダウンロードしたピクセルの63%がその場で捨てられます。

目安は単純です。サーバーに置く画像は、表示寸法の2倍までにします（2倍はRetinaやHiDPIの画面に備えるためです）。幅600pxの枠なら、最大1200pxということになります。

アップロードの前に、ImageToolsのサイズ変更ツールで寸法を整えておきましょう。ピクセル単位でも、パーセント指定でも入力できます。

4. 遅延読み込みを入れる

遅延読み込みは、ページの画像を最初にまとめてダウンロードするのではなく、画面に入りそうになった時点で読み込む手法です。効果は大きく、商品一覧や長い記事のように画像の多いページでは、最初に読み込む容量を60〜80%減らせることもあります。

いちばん簡単な方法は、いまのHTMLに標準で備わっています。画像のタグにloading="lazy"属性を足すだけです。

<!-- すぐ読み込むべき画像（ファーストビュー内） -->
<img src="hero-banner.webp" alt="バナー" loading="eager">

<!-- あとで読み込んでよい画像（ファーストビューより下） -->
<img src="product-1.webp" alt="商品1" loading="lazy">
<img src="product-2.webp" alt="商品2" loading="lazy">

注意：ファーストビュー内の主要な画像（ヒーロー画像、バナー、最初の商品写真）にloading="lazy"を付けてはいけません。Core Web Vitalsでもっとも重要なLCPが遅れ、PageSpeedのスコアがそのまま下がります。

5. 画像タグにwidthとheightを指定する

ブラウザはページを読み込みはじめるとき、画像の大きさが分かる前にレイアウトを組み立てます。widthとheightが指定されていないと、正しい場所を確保できず、画像が届いた瞬間にレイアウトが「跳ねて」、文字やボタンがずれます。これがPageSpeedのいうCumulative Layout Shift（CLS）で、これもCore Web Vitalsのひとつです。

<!-- 寸法なし：レイアウトのずれが起きる -->
<img src="product.webp" alt="商品">

<!-- 寸法あり：最初から正しい場所を確保できる -->
<img src="product.webp" alt="商品" width="600" height="600">

HTMLのwidthとheightは、実際に表示される大きさと一致していなくて構いません。縦横比を伝えるためのもので、表示サイズはCSSが決めます。

6. srcsetでレスポンシブな画像にする

srcset属性を使うと、同じ画像を端末ごとに違うサイズで配信できます。スマートフォンには小さいもの、パソコンには大きいものという具合です。どれを使うかはブラウザが画面に合わせて自動で選びます。

<img
  src="product-800.webp"
  srcset="product-400.webp 400w,
          product-800.webp 800w,
          product-1200.webp 1200w"
  sizes="(max-width: 600px) 400px,
         (max-width: 900px) 800px,
         1200px"
  alt="商品"
  width="800"
  height="800"
  loading="lazy"
>

商品写真が大量にあるECサイトでは、srcsetによってスマートフォン利用者への転送量を40〜60%減らせることがあります。

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

ページを公開する前、あるいは既存の画像を差し替える前に、このリストで確認しましょう。

☐ 画像はWebP（ベクターならSVG）になっている
☐ 圧縮をかけた。写真はできるだけ150 KB未満に
☐ 寸法が適切。表示領域の2倍を超えていない
☐ ファーストビューより下の画像すべてにloading="lazy"がある
☐ ファーストビュー内の主要画像はloading="eager"（または属性なし）
☐ すべての<img>タグにwidthとheightを指定した
☐ すべての画像に内容が伝わるaltを入れた（アクセシビリティとSEOのため）
☐ スマートフォンとパソコンで表示サイズが大きく違う画像にはsrcsetを使った
☐ LCP画像にloading="lazy"を付けず、可能ならfetchpriority="high"を付けた

プラットフォーム別の最適化

WordPress

WordPressは6.1以降、サーバーが対応していれば自動でWebPに変換します。確実にするなら、Imagify、ShortPixel、Smushといった最適化プラグインを入れましょう。メディアライブラリにすでにある画像も、圧縮・WebP変換・遅延読み込みの追加まで自動でやってくれます。

Shopify

Shopifyは2021年から、画像を自動でWebPに変換し、端末に合わせた版を配信しています。店舗側が気をつけるのはアップロードする画像の大きさだけで、商品写真は2048×2048pxが推奨です。あとはShopifyが表示場所ごとにリサイズしてくれます。

Wix、Squarespaceなどのサイトビルダー

最近のサイトビルダーは、圧縮も遅延読み込みも自動で行います。利用者側に残るのは、常識的な寸法の画像を上げることです。カメラで撮った8 MBの写真をそのまま上げるとサーバーに負担がかかり、必要以上に大きい派生画像が作られることもあります。

素のHTML／CSSのサイト、またはフレームワーク（Next.js、Nuxtなど）

この場合、最適化はすべて開発者の仕事になります。たとえばNext.jsの<Image>コンポーネントは、遅延読み込み、srcset、WebP変換を自動で処理します。そうした仕組みのないフレームワークでは、上のチェックリストに沿って手作業で最適化する必要があります。

⚡ ECサイト向けのヒント：商品ページのLCP（Largest Contentful Paint）は、ほぼ必ず商品のメイン写真です。WebPにし、圧縮し、寸法を合わせ、遅延読み込みは付けないようにしましょう。この1枚が、そのページのPageSpeedスコアをいちばん大きく左右します。

最適化の効果を測る方法

手を入れたら、次のツールで結果を確かめましょう。

Google PageSpeed Insights（pagespeed.web.dev）— 要素ごとの診断まで含めた総合分析で、スマートフォンとパソコンを分けて見られます。
Google Search Console →「ページエクスペリエンス」レポート — 実際の訪問者のデータをもとに、Core Web Vitalsの状態が分かります。
WebPageTest.org — 読み込みのウォーターフォールまで見られる詳細な技術分析で、どの画像がLCPを遅らせているかを特定できます。
Chrome DevTools →「ネットワーク」—「Img」で絞り込めば、読み込まれた画像とそのサイズ、ダウンロード時間を一覧できます。

よくある質問

画像の最適化はGoogleの順位に本当に効きますか？

直接にも間接にも効きます。直接的には、表示速度とCore Web VitalsはGoogleが公式に認めている順位の要因です。間接的には、速いページほど直帰率が下がり滞在時間が伸びます。これはGoogleが関連性を測るのに使う行動シグナルです。中身が表示される前に訪問者を失うような遅いサイトは、そもそも関連性を示す機会すら得られません。

PageSpeed InsightsとCore Web Vitalsは何が違いますか？

PageSpeed InsightsはGoogleの診断ツールで、URLを分析して0〜100点の評価と改善案を出します。Core Web Vitalsは、Googleが順位の要因として使う3つの指標そのものです。LCP（Largest Contentful Paint、主要な要素が表示されるまでの速さ）、INP（Interaction to Next Paint、操作への反応）、CLS（Cumulative Layout Shift、表示の安定性）の3つで、画像はLCPとCLSに直接影響します。

サイトの画像をすべてWebPに変換する必要がありますか？

これから追加する画像については、WebPを標準にすべきです。すでにある画像は、枚数によります。画像が20枚ほどのサイトなら急いで移行する必要はありませんが、商品写真が数百枚あるECサイトなら、変換後に体感できるほど速くなります。アップロードし直す前に、変換ツールでまとめて変換しておきましょう。

LCPとは何ですか？なぜメイン画像がそこまで重要なのですか？

LCP（Largest Contentful Paint）は、ページ内でいちばん大きく表示される要素が読み込まれるまでの時間です。多くのサイトでは、それが画像——メインバナー、商品写真、記事のアイキャッチ——にあたります。Googleはこれを、利用者にとってページが「表示され終わったように見える」タイミングの目安として使います。良いスコアの目安は2.5秒未満です。最適化していない画像がLCPになっていると、この時間が3倍にもなりえます。

遅延読み込みはSEOに悪影響がありますか？

正しく実装していれば影響しません。Googlebotは2019年から標準の遅延読み込みに対応していて、loading="lazy"で読み込まれる画像も普通にインデックスされます。唯一気をつけたいのは、LCP画像——ファーストビュー内の主要な画像——に遅延読み込みを付けないことです。付けてしまうとページでいちばん重要な要素の表示が遅れ、LCPのスコアが下がります。

サイトのヒーロー画像やバナーはどのサイズにすべきですか？

パソコンの全幅バナーなら、最近のモニターをカバーするのに幅1920pxで十分です。スマートフォン向けなら768〜1024pxで足ります。srcsetを使えば、端末ごとに適した方を自動で配信できます。容量はWebPで200 KB未満に抑えましょう。1920pxの画像でも、きちんと圧縮したWebPなら余裕でその範囲に収まります。