なぜ画像最適化が重要なのか：パフォーマンスへの影響
HTTPアーカイブの2026年のデータによると、ウェブページの平均転送量のうち画像が約50%を占めています。モバイルページの中央値で約1 MB、デスクトップでは1.5 MB以上が画像データです。つまり、画像最適化はWebパフォーマンス改善において最もインパクトの大きい施策の一つと言えます。
GoogleのCore Web Vitalsにおいて、画像はLCP（Largest Contentful Paint）に直接的な影響を与えます。ヒーロー画像やファーストビューの大きな画像が最適化されていないと、LCPスコアが悪化し、検索ランキングに悪影響を及ぼします。2026年のGoogleのページエクスペリエンスアップデートでは、INP（Interaction to Next Paint）への画像デコードの影響も重視されるようになりました。
パフォーマンス以外にも、帯域幅コストの削減、ストレージ容量の節約、モバイルユーザーのデータ通信量の節約など、ビジネス面でのメリットも大きいです。ECサイトでは、ページ読み込み時間が1秒改善するとコンバージョン率が2〜7%向上するという調査結果もあります。
本ガイドでは、フォーマットの選択基準、圧縮の仕組みと最適なパラメータ、レスポンシブ画像の実装、遅延読み込み、CDNの活用まで、画像最適化のすべてを体系的に解説します。
画像フォーマットの選択基準：JPEG、PNG、WebP、AVIF
JPEG（Joint Photographic Experts Group）は写真や複雑なグラデーションを含む画像に最適です。非可逆圧縮により高い圧縮率を実現しますが、テキストやシャープなエッジを含む画像ではアーティファクト（ブロックノイズ）が目立ちます。品質パラメータ（quality）は一般的に75〜85が良いバランスです。Progressive JPEGを使えば、低速回線でも画像が徐々に鮮明になる体験を提供できます。
PNG（Portable Network Graphics）は透過が必要な画像、テキスト、アイコン、スクリーンショットに適しています。可逆圧縮のためファイルサイズは大きくなりがちですが、画質の劣化がありません。PNG-8（256色まで）とPNG-24（フルカラー）を使い分けることで、アイコンやシンプルなイラストではファイルサイズを大幅に削減できます。
WebPはGoogleが開発した比較的新しいフォーマットで、JPEGよりも25〜34%小さいファイルサイズで同等の画質を実現します。可逆・非可逆の両方をサポートし、アニメーションやアルファ透過にも対応しています。2026年現在、すべてのモダンブラウザがWebPをサポートしており、実質的にJPEGとPNGの上位互換と言えます。
AVIFはAV1ビデオコーデックから派生した最新フォーマットで、WebPよりもさらに20〜30%高い圧縮効率を持ちます。HDR、広色域、12ビット色深度をサポートし、画質と圧縮率のバランスでは現時点で最強です。ただし、エンコード速度がWebPの5〜10倍遅いため、リアルタイム変換には不向きです。2026年時点でChrome、Firefox、Safariのすべてが対応しています。
<!-- picture要素によるフォーマットの段階的フォールバック -->
<picture>
<!-- AVIFをサポートするブラウザに最高効率のフォーマットを提供 -->
<source srcset="hero.avif" type="image/avif">
<!-- WebPをフォールバックとして提供 -->
<source srcset="hero.webp" type="image/webp">
<!-- すべてのブラウザで動作するJPEGフォールバック -->
<img src="hero.jpg" alt="ヒーロー画像" width="1200" height="630">
</picture>圧縮の仕組み：非可逆圧縮と可逆圧縮
非可逆圧縮（lossy compression）は人間の目に知覚されにくいデータを削除することで、大幅なファイルサイズ削減を実現します。JPEGの場合、DCT（離散コサイン変換）で画像を周波数成分に分解し、高周波成分（細かいディテール）を量子化（丸め込み）します。品質パラメータを下げるほど量子化が荒くなり、ファイルは小さくなりますが画質が劣化します。
可逆圧縮（lossless compression）はデータを完全に復元可能な方法で圧縮します。PNGのDeflate圧縮やWebPの可逆モードがこれに該当します。圧縮率は非可逆に比べて低いですが、元データが完全に保存されます。スクリーンショットやテクニカルダイアグラムなど、正確な再現が必要な画像に適しています。
知覚品質の最適化が現代の画像圧縮のキーコンセプトです。SSIMやButterwaughなどの知覚品質メトリクスを使って、人間の目に見える劣化を最小限に保ちながらファイルサイズを最大限削減します。Mozjpeg、libwebp、libavifなどの最新エンコーダは内部的にこれらのメトリクスを活用して最適な圧縮を行います。
チャンネルごとの圧縮という概念も重要です。人間の目はルミナンス（輝度）の変化には敏感ですが、クロミナンス（色差）の変化には鈍感です。JPEGのクロマサブサンプリング（4:2:0）はこの特性を利用し、色情報を半分に削減しても視覚的な劣化がほとんどありません。WebPやAVIFも同様のテクニックを使用しています。
レスポンシブ画像の実装：srcsetとsizes
レスポンシブ画像とは、デバイスの画面サイズやピクセル密度に応じて最適なサイズの画像を提供する仕組みです。4Kディスプレイに小さな画像を表示するとぼやけ、モバイルに巨大な画像を送信すると帯域幅が無駄になります。HTMLのsrcset属性とsizes属性を使って、ブラウザに最適な画像を選択させることができます。
srcset属性で複数の画像バリアントとそのサイズを宣言し、sizes属性でビューポートに対する画像の表示サイズを指定します。ブラウザはデバイスのピクセル密度（DPR）、ビューポート幅、ネットワーク状況を考慮して最適な画像を自動選択します。開発者が全条件を手動で判定する必要がありません。
一般的なブレークポイントとして、320w、640w、960w、1280w、1920wの5サイズを用意すれば、ほとんどのユースケースをカバーできます。Retina（2x DPR）対応が必要な場合は、表示サイズの2倍の解像度の画像が必要です。つまり、640px幅で表示する画像には1280wのバリアントが使われます。
Next.jsやAstroなどのモダンフレームワークは、画像コンポーネントがsrcsetの自動生成、フォーマット変換、サイズ最適化を一括で処理してくれます。手動での実装は複雑になりがちなので、フレームワークの画像コンポーネントを活用することを強く推奨します。
<!-- srcsetとsizesによるレスポンシブ画像 -->
<img
src="product-800.jpg"
srcset="
product-400.jpg 400w,
product-800.jpg 800w,
product-1200.jpg 1200w,
product-1600.jpg 1600w
"
sizes="
(max-width: 640px) 100vw,
(max-width: 1024px) 50vw,
33vw
"
alt="製品画像"
width="800"
height="600"
loading="lazy"
decoding="async"
>
<!-- Next.jsのImageコンポーネント（自動最適化） -->
<!-- import Image from 'next/image'
<Image
src="/product.jpg"
alt="製品画像"
width={800}
height={600}
sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
/> -->遅延読み込みとLCPの最適化
遅延読み込み（Lazy Loading）はビューポート外の画像の読み込みを延期し、初期ページロードを高速化するテクニックです。ネイティブのloading="lazy"属性を使えば、JavaScriptなしで遅延読み込みを実現できます。ブラウザがスクロール位置を監視し、画像がビューポートに近づいた時点で自動的に読み込みを開始します。
重要な注意点：ファーストビュー（above the fold）の画像には遅延読み込みを適用してはいけません。LCPの対象になる可能性のあるヒーロー画像やメインビジュアルにloading="lazy"を付けると、LCPスコアが悪化します。これらの画像にはloading="eager"（デフォルト）を使い、さらにfetchpriority="high"を追加して優先的に読み込ませます。
decoding="async"属性もLCP最適化に有効です。画像のデコード（圧縮データからピクセルデータへの変換）をメインスレッドの外で非同期に行うことで、ページの描画をブロックしません。ただし、LCP候補の画像ではdecoding="sync"の方がレンダリングが速い場合もあるため、実測して判断してください。
preload/preconnectを使ったリソースヒントも効果的です。LCP画像のURLが分かっている場合、<link rel="preload" as="image" href="hero.webp">をHTMLのhead内に追加することで、パーサーがimgタグに到達する前に画像のダウンロードを開始できます。外部CDNの画像の場合は<link rel="preconnect" href="https://cdn.example.com">でDNS/TLSの事前接続も行いましょう。
<head>
<!-- LCP画像のプリロード（フォーマット指定付き） -->
<link rel="preload" as="image" href="hero.avif" type="image/avif">
<link rel="preconnect" href="https://images.cdn.example.com">
</head>
<body>
<!-- ファーストビューの画像：遅延読み込みなし、高優先度 -->
<img
src="hero.webp"
alt="メインビジュアル"
width="1200"
height="630"
fetchpriority="high"
decoding="async"
>
<!-- ビューポート外の画像：遅延読み込み -->
<img
src="feature-1.webp"
alt="機能紹介1"
width="600"
height="400"
loading="lazy"
decoding="async"
>
</body>画像CDNとオンザフライ変換
画像CDN（Cloudinary、imgix、Cloudflare Image Resizing、Vercel OGなど）はURLパラメータで画像のリサイズ、フォーマット変換、品質調整をリアルタイムに行うサービスです。オリジナル画像を1枚アップロードするだけで、あらゆるサイズ・フォーマットのバリアントを動的に生成できます。事前にすべてのバリアントを用意する手間が不要になります。
Accept headerのContent Negotiation（auto format）機能は特に便利です。ブラウザがAccept: image/avifヘッダーを送信すると、CDNが自動的にAVIFを返します。WebPのみサポートするブラウザにはWebPを、どちらもサポートしないブラウザにはJPEGを返します。開発者はpicture要素やsrcsetの複雑な記述をせずに、常に最適なフォーマットを配信できます。
キャッシュ戦略も画像CDNの重要な側面です。変換済み画像はCDNのエッジにキャッシュされ、同じパラメータのリクエストには変換なしで即座にレスポンスされます。Cache-Controlヘッダーでブラウザキャッシュの期間を制御し、画像のURLにバージョン文字列やハッシュを含めることでキャッシュバストを実現します。
コスト面では、画像CDNの利用料（変換回数やCDN転送量による課金）と、自前でのバリアント生成・ストレージコスト・開発工数を比較検討してください。月間100万PV以上のサイトでは、画像CDNの導入によるパフォーマンス改善がSEOとUXの両面で十分にペイすることが多いです。
ビルドパイプラインでの自動最適化
CIパイプラインに画像最適化を組み込むことで、人的ミスを防ぎ、一貫した品質を保てます。sharpはNode.jsの高速画像処理ライブラリで、リサイズ、フォーマット変換、品質最適化をプログラマティックに実行できます。ビルド時にすべての画像を最適化するスクリプトを作成し、CIで自動実行する運用が理想的です。
Webpackやviteのプラグインとして画像最適化を統合する方法もあります。vite-plugin-image-optimizerやnext/imageの組み込み最適化は、開発者が意識せずとも画像が最適化される仕組みを提供します。ただし、ビルド時間が増加するトレードオフがあるため、大量の画像を扱うプロジェクトではキャッシュ戦略と組み合わせてください。
SVGはベクター画像のため、ラスター画像とは異なる最適化が必要です。svgoは不要なメタデータ、コメント、冗長な属性を除去してSVGファイルサイズを30〜70%削減します。ただし、viewBoxの削除やpathの最適化が表示に影響する場合があるため、出力結果の目視確認は必須です。
画像最適化の効果測定にはLighthouseのPerformanceスコア、WebPageTestの視覚的比較、Real User Monitoring（RUM）データを活用してください。最適化前後のLCPスコア、Total Blocking Time、ページ重量を比較し、改善効果を定量的に把握することが継続的な最適化のモチベーションになります。
// sharpを使ったビルド時の画像最適化スクリプト
import sharp from 'sharp';
import { glob } from 'glob';
import path from 'path';
// 最適化設定
const config = {
jpeg: { quality: 80, progressive: true },
webp: { quality: 80 },
avif: { quality: 65 }, // AVIFは低い品質値でも高画質
sizes: [400, 800, 1200, 1600], // レスポンシブ用サイズ
};
async function optimizeImages() {
const images = await glob('src/images/**/*.{jpg,jpeg,png}');
for (const imagePath of images) {
const image = sharp(imagePath);
const metadata = await image.metadata();
const baseName = path.basename(imagePath, path.extname(imagePath));
for (const width of config.sizes) {
// オリジナルより大きいサイズはスキップ
if (width > (metadata.width || 0)) continue;
const resized = image.clone().resize(width);
// WebP出力
await resized
.webp(config.webp)
.toFile(`dist/images/${baseName}-${width}.webp`);
// AVIF出力
await resized
.avif(config.avif)
.toFile(`dist/images/${baseName}-${width}.avif`);
}
}
console.log(`${images.length}枚の画像を最適化しました`);
}
optimizeImages();チェックリスト：画像最適化の実践まとめ
フォーマット選択の原則として、写真にはAVIF > WebP > JPEGの優先順位で提供します。透過が必要なグラフィックにはWebP > PNGを使います。アイコンやロゴなどのベクター画像にはSVGが最適です。アニメーションにはWebPアニメーションまたはAVIFシーケンスを使い、GIFは避けてください（ファイルサイズが5〜10倍大きくなります）。
サイズとレスポンシブの原則として、画像は表示サイズの最大幅に合わせ、2x DPR分を考慮したサイズで提供します。srcsetで複数サイズのバリアントを用意し、sizes属性で表示幅を正確に指定します。widthとheight属性を必ず指定してCLS（Cumulative Layout Shift）を防止します。aspect-ratioプロパティもCLS対策に有効です。
読み込み戦略として、LCP候補の画像にはfetchpriority="high"とpreloadを適用し、ファーストビュー外の画像にはloading="lazy"を適用します。above the foldの画像数は3〜5枚に抑え、初期ロードの画像合計サイズを200KB以下に目標設定しましょう。
運用面では、画像最適化をCIパイプラインに組み込み、新しい画像が追加されるたびに自動最適化が走る仕組みを構築してください。Lighthouseの定期実行でパフォーマンスリグレッションを検知し、画像CDNのアナリティクスで配信フォーマットの分布とキャッシュヒット率を監視します。画像最適化は一度やれば終わりではなく、継続的な改善プロセスです。