この記事の対象: 画像最適化に取り組みたいWeb制作者
読了時間: 約8分
ページ容量の半分以上を画像が占めているケースは珍しくありません。フォントやJSを削るより先に、画像を1枚直すほうが表示速度の改善幅は大きくなります。この記事では2026年時点のフォーマット選定から、実装で迷いやすい遅延読み込みやレスポンシブ画像の書き方まで、現場で使える形にまとめます。
なぜ画像最適化が重要か

画像最適化が効くポイントは大きく3つです。
- LCP改善: ページの最大コンテンツはほとんどの場合、ヒーロー画像やメインビジュアル。LCPスコアに直結する
- 帯域節約: モバイル回線のユーザーほど恩恵が大きい。データ通信量の削減はそのまま離脱率に効く
- UX向上: 画像がじわじわ表示される体験は、それだけでサイトの信頼感を落とす
Core Web Vitalsのスコアを底上げしたい場合、まず疑うべきは画像です。LCPまわりを網羅的に見直したい場合は、あわせて次の記事も参考になります。
2026年の画像フォーマット比較

| フォーマット | ファイルサイズ目安 | ブラウザ対応 | 透過 | アニメーション | おすすめ用途 |
|---|---|---|---|---|---|
| JPEG | 基準 | 全ブラウザで表示可能 | ✗ | ✗ | 写真全般 |
| PNG | JPEGより大きくなりやすい | 全ブラウザで表示可能 | ✓ | ✗ | ロゴ、アイコン |
| WebP | JPEGより軽量になるケースが多い | 主要ブラウザの現行版で対応 | ✓ | ✓ | 写真・イラスト全般 |
| AVIF | WebPよりさらに軽量になるケースが多い | 主要ブラウザの現行版で対応(一部旧環境は非対応) | ✓ | ✓ | 写真全般(最推奨) |
削減率は画像の内容(写真かイラストか、色数やディテールの量)によって変わるため、実際の効果は素材ごとに圧縮ツールで確認するのが確実です。AVIFはWebPよりさらに軽くなる傾向があり、対応ブラウザも実用上問題ないレベルまで広がっています。2026年時点での推奨構成は次のとおりです。
新しいフォーマットを使う際も、古いブラウザで画像が表示されない事故を防ぐため、必ず最終フォールバックまで用意します。<picture>要素を使えばこの分岐はブラウザ任せにできます。
画像最適化の実践テクニック

適切なフォーマットの選択
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="説明テキスト" width="800" height="600">
</picture>
<picture>要素を使うと、ブラウザが対応する最適なフォーマットを自動で選んでくれます。上から順に評価され、対応していないタイプは読み飛ばされる仕組みです。
つまずきやすい点: <source>の並び順を間違えると意味がありません。必ず軽いフォーマット(AVIF)から先に書きます。
対応ブラウザ: Chrome・Edge・Firefox・Safariの現行版はいずれも<picture>要素とAVIF/WebP双方に対応しています。ただし対象ユーザーに古いブラウザの利用者が多い場合は、必ずJPEG/PNGへのフォールバックまで実装してから公開してください。
リサイズ(表示サイズに合わせる)
表示サイズが400×300pxの箇所に、4000×3000pxの元画像をそのまま使うのはよくある無駄です。表示サイズの2倍(Retina対応)を目安にリサイズします。等倍で書き出すと、高解像度ディスプレイで画像がぼやけて見えるため、2倍サイズは省略しないほうが安全です。
画像を枠に合わせて綺麗に切り抜きたい場合は、object-fitとaspect-ratioの実装もあわせて押さえておくと崩れが減ります。
圧縮(lossy vs lossless)
- Lossy(非可逆圧縮): 画質をわずかに犠牲にして大幅に軽量化。写真向け
- Lossless(可逆圧縮): 画質を維持したまま圧縮。ロゴやアイコン向け
写真素材はLossy圧縮の品質80〜85%を起点に調整するのが、見た目の劣化とファイルサイズのバランスを取りやすい目安です。90%以上まで上げても見た目の差はほとんど分からないことが多く、容量だけが増えるケースが目立ちます。最終的な品質値は素材ごとに書き出して目視確認するのが確実です。
遅延読み込み(loading=”lazy”)
<img src="image.webp" alt="説明" loading="lazy" width="800" height="600">
ファーストビュー外の画像にloading="lazy"を指定すると、スクロールして画面に近づいたタイミングで読み込みが始まります。
注意: ファーストビュー内の画像(LCPの対象になりやすい画像)にはloading="lazy"を使わず、fetchpriority="high"を指定して優先的に読み込ませます。
<img src="hero.webp" alt="メインビジュアル" fetchpriority="high" width="1200" height="600">
つまずきやすい点: ヒーロー画像にまでloading="lazy"を付けてしまうケースが意外と多く、これをやるとLCPが悪化します。ファーストビューか否かで指定を分けることを徹底してください。
srcsetとsizesでレスポンシブ画像
<img
srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
src="image-800.webp"
alt="説明"
width="800" height="600"
loading="lazy">
画面サイズに応じて最適なサイズの画像を配信する仕組みです。モバイルユーザーに1200px幅の画像を送る必要はなく、sizes属性で実際の表示幅をブラウザに伝えることで、無駄な転送を防げます。
対応ブラウザ: srcset/sizesは主要ブラウザで安定してサポートされている機能です。
CDNの活用
CDNを使うと、ユーザーの地理的な位置に近いサーバーから画像を配信でき、読み込み速度が向上します。サービスによっては、URLパラメータを変えるだけでフォーマット変換やリサイズを自動化できるものもあり、実装コストを抑えたい場合の選択肢になります。導入する際は、対象サービスの料金体系と無料枠の条件を必ず公式サイトで確認してください。
画像最適化ツール

| ツール | 特徴 |
|---|---|
| Squoosh | ブラウザ上で使える画像圧縮ツール。インストール不要で手早く試せる |
| ImageOptim | Mac向けの画像最適化アプリ。ドラッグ&ドロップで一括圧縮できる |
| Sharp | Node.jsの画像処理ライブラリ。ビルドプロセスへの組み込みに向く |
| Cloudinary | クラウドベースの画像管理・最適化サービス。URLパラメータで変換できる |
料金体系や無料枠の条件は変わりやすいため、導入前に必ず各サービスの公式サイトで最新の内容を確認してください。案件ごとに1枚1枚手で圧縮するのは非効率です。ビルドプロセスに組み込むか、CMS側でアップロード時に自動変換させる仕組みを用意しておくと、運用が始まってからの取りこぼしを防げます。
Sharpでの一括変換例
npx sharp-cli -i input/*.jpg -o output/ -f webp -q 80
フォルダ内の画像をまとめてWebP・品質80で書き出すコマンドです。納品前の一括変換や、既存サイトの画像を後からまとめて軽量化する際に使います。
WordPressでの画像最適化

WordPressサイトでは、以下のようなプラグインでアップロード時の最適化を自動化できます。
- EWWW Image Optimizer: アップロード時に自動でWebP変換と圧縮を行う
- ShortPixel: 高品質な圧縮に対応し、AVIF書き出しにも対応
各プラグインの料金プランや無料枠は変更されることがあるため、導入前に公式サイトで最新情報を確認してください。クライアント案件でCMS側の画像運用を任せる場合、プラグイン任せにするだけでなく、テンプレート側でも遅延読み込みやサイズ指定が正しく出力されているかを確認しておくと安心です。カスタムフィールドで画像を出力している箇所は、実装漏れが起きやすいポイントです。
よくある質問
AVIFとWebP、どちらか一方だけ用意すればいい?
両方用意するのが基本です。AVIFのほうが軽量になりやすい一方、対応ブラウザの範囲がわずかに狭いため、AVIF→WebP→JPEGの3段構成でフォールバックを組んでおくと、どの環境でも確実に画像が表示されます。
画像圧縮の品質は何%に設定すればいい?
写真素材はLossy圧縮の品質80〜85%を起点に調整するのが目安です。この範囲であれば、目視では劣化がほとんど分からないことが多い一方、ファイルサイズは大きく削減できます。ロゴやアイコンなど輪郭がはっきりしたものは、劣化が目立ちやすいためLossless圧縮を使います。最終的な数値は素材ごとに書き出して確認してください。
既存サイトの画像を後からまとめて最適化することはできる?
可能です。SharpなどのCLIツールで既存の画像フォルダを一括変換できますし、WordPressであればEWWW Image OptimizerやShortPixelに既存メディアの一括再圧縮機能があります。ただし、テンプレート側のHTMLが古いフォーマットを直接指定している場合は、コード側の修正も必要になります。
loading=”lazy”を全部の画像に付ければ安全?
いいえ、ファーストビュー内の画像には付けないほうが安全です。LCP対象になりやすい画像にloading="lazy"を付けると、読み込み開始が遅れてLCPスコアが悪化します。ファーストビュー内はfetchpriority="high"、それ以外はloading="lazy"という使い分けが基本です。
CDNを導入すれば画像最適化は不要になる?
CDNは配信経路の高速化であり、画像そのものの軽量化とは別の話です。CDN側で自動変換機能を持つサービスもありますが、それを使わない場合は元画像のフォーマット・サイズ・圧縮率をあらかじめ整えておく必要があります。
まとめ
画像最適化のポイントをまとめます。
- AVIF > WebP > JPEG/PNGの優先順位で
<picture>要素を使用する - 表示サイズの2倍にリサイズしてRetina対応する
- Lossy圧縮 品質80〜85%を起点に写真のバランスを調整する
loading="lazy"でファーストビュー外の画像を遅延読み込みし、ファーストビューはfetchpriority="high"srcset+sizesでレスポンシブ画像を配信し、モバイルへの無駄な転送を減らす
どれも実装自体は難しくありませんが、ファーストビュー内外の判定を誤ると効果が逆転する点だけ注意してください。
