画像圧縮の完全ガイド:JPG・PNG・WebPを用途別に選ぶ

2026-04-13公開 8分で読了

要約 (TL;DR)

先週末、4.2MBの猫写真をSquooshに放り込み、WebP品質80で書き出してみた。結果は380KB——91%の削減。正直なところ、スマホ画面では元画像との差を言い当てることができなかった。不可逆圧縮がきちんと働いているときの風景とはまさにこれだ。毎回この事実を忘れては、2MBのヒーロー画像が3秒かけてLTE越しに降ってくるブログを開き、同じ教訓を取り直している。

画像フォーマット選びは「どれが一番良いか」ではなく「何に使うか」で決まる。連続階調が中心の写真には不可逆系のJPEG、WebP(不可逆)、AVIFが向く。同じ視覚品質で比較すると、WebPはJPEGより概ね25–35%、AVIFは40–50%ほど小さいファイルを生成できる。逆にロゴ・アイコン・スクリーンショットのようにエッジが立っていて可読性が重要な画像には、PNG、WebP(可逆)、TIFFといった可逆フォーマットが安全だ。透過とアニメーションの両立が必要なら、WebP、APNG、AVIFが候補になる。ブラウザ対応は2026年初頭時点で広く、WebPはChrome 32(2014)、Firefox 65、Safari 14(2020年後半)以降に対応済みで事実上ユニバーサル。AVIFはChrome 85(2020年8月)、Firefox 93(2021年10月)、Safari 16(2022年9月)以降で動作する。実務的な基準線としては「ベクターロゴはSVG、写真はWebPまたはAVIF、スクリーンショットはPNG」を軸に、互換性が気になる場面で <picture> 要素によるJPEGフォールバックを足していく形が扱いやすい。

背景・コンセプト

JPEG、WebP(不可逆)、AVIFといった不可逆系は、人間の視覚が敏感ではない情報を捨てることでファイルサイズを削る。核となる手法は二つある。ひとつは量子化(quantization)で、周波数領域の係数を整数単位で丸める際、空間周波数が高い成分ほど大きく切り捨てる。写真のように緩やかな階調変化の画像では気づきにくいが、シャープなエッジではブロック境界が露出することがある。もうひとつはクロマサブサンプリング(chroma subsampling)。輝度(Y)より色差(Cb・Cr)の解像度を下げる技法で、4:4:4は色差を保持、より一般的な4:2:0は縦横それぞれ半分にする。大半の既定値は4:2:0なので、暗背景の赤・青の文字エッジが滲みやすいのはこのためだ。

JPEGは1992年に標準化され、8×8画素ブロックに適用される離散コサイン変換(DCT)を基盤にしている。WebPはVP8ビデオコーデックのイントラフレーム技術の応用、AVIFはAV1のイントラフレーム技術の応用で、どちらもJPEGより格段に近代的な予測・変換・量子化を使う。ブロックサイズが大きく、方向性予測が入り、エントロピー符号化も改良されている。PNGは別系統の仕組みで、deflate系の可逆圧縮を使い、アルファ透過とパレット型インデックスカラーを標準で備える。情報を一切捨てないが、写真系のコンテンツではそのぶんファイルが大きく膨らむ。

関連する概念としてプログレッシブデコードもある。プログレッシブJPEGとインターレースPNGは、バイトが到着するにつれて段階的に解像度を上げていくことができ、低速回線や大きな画像で体感が良くなる。WebPとAVIFは実装上、単一パスでデコードされることが多く、この点の差は大きな画像か遅い回線でないと目立たない。最後にSVGだが、これはそもそも圧縮されたラスター画像ではなく、図形と属性のテキスト記述であり、サイズは図形の数と本体テキストの圧縮(gzipやbrotli)に依存する。

比較・データ

フォーマット不可逆可逆透過アニメーション写真の平均圧縮比2025年ブラウザ対応
JPEG可不可不可不可およそ10:1全ブラウザ
PNG不可可可APNG拡張およそ2–3:1全ブラウザ
WebP可可可可JPEG比で25–35%小さいSafari 14(2020)以降、事実上全ブラウザ
AVIF可可可可JPEG比で40–50%小さいChrome 85+、Firefox 93+、Safari 16+
GIF可(256色パレット)不可1ビットのみ可写真には不向き全ブラウザ

これらの数字はあくまで傾向として読んでほしい。実際の圧縮効果は元画像・エンコーダ・プリセット・品質設定で大きくぶれる。同じJPEGでも品質85と60で3–4倍の差がつくし、AVIFも高速プリセットを使えば優位性が縮む。GoogleやMozillaが2019–2023年に発表したベンチマークでは、SSIMを揃えたときWebPはJPEGより26–34%、AVIFは40–50%小さいと報告されていたが、これは遅いプリセットで品質を詰めた結果であって、編集アプリのワンクリック既定値では再現しないことが多い。

もう一つの側面がエンコード・デコード負荷だ。JPEGのデコードはどの端末でも1ミリ秒未満で終わる。WebPも近い。AVIFのデコードはCPU負荷が高めで、高品質プリセットのエンコードは1枚数秒かかる。ビルド時パイプラインのようなバッチ処理には向くが、ユーザーがアップロードするたびにホットパスで再エンコードするには負担が重い。

実践シナリオ

シナリオ1 — ブログのサムネイルとヒーロー画像。 自分のサイトを見直したら、ヒーローが1.8MBで配信されていた。WebP品質82で書き出し直すと210KBまで縮み、Lighthouseの4G絞りプロファイルでLCPが2.4秒から1.1秒に落ちた。既定はWebPにして、古い環境の互換が必要なら <picture> でJPEGフォールバック。表示CSS幅に合わせて画像もリサイズしないと、3000ピクセル幅の写真を600ピクセルのコンテナに入れるのと同じで、フォーマット選び以前に帯域を浪費する。

シナリオ2 — ロゴとアイコン。 ベクター元データがあるならSVGが第一候補。あるランディングページをレビューしたとき、赤いブランドロゴがJPEG品質75で書き出されていて、文字の縁がピンクの光暈に滲んでいたことがある。4:2:0のクロマサブサンプリングは、暗背景の赤エッジを真っ先に壊す。ラスターしかない場合はPNFまたは可逆WebPに。ロゴへの不可逆圧縮はレッドフラグで、最適化の話ではない。

シナリオ3 — スクリーンショットとUIキャプチャ。 スクリーンショットの既定はPNG。ブラウザクロム、コードスニペット、CJKフォントはJPEGのアーティファクトが強く出る——「monospaceフォントがにじんで見える」という指摘をレビューで連続2回受けてから、僕はこのルールを譲らなくなった。サイズを削りたければpngquant(macOSなら brew install pngquant)でパレットを256色に落とせばいい。UIスクリーンショットならほぼ気づかれず、ファイルは4–6倍軽くなることが多い。

シナリオ4 — 原本素材のアーカイブ。 将来また加工する可能性のある原本(写真マスター、スキャン、商品写真)はTIFFや可逆WebPで別にコールドストレージに置いておく。不可逆JPEGを何度も再圧縮すると「世代喪失」で劣化が累積するので、戻れる清潔なソースを持っておく方が安心だ。

よくある誤解

「PNGが常に最高品質」。 可逆という意味では正しいが、写真ではその純粋さがファイルサイズ数倍の代償になる。モバイルで数MBの写真はCore Web Vitalsや体感ロード時間を直撃する。

「WebPは全ブラウザで動かない」。 2020年後半のSafari 14以降、主要ブラウザすべてで動作する。どうしても心配なら <picture> にJPEGフォールバックを置けば済む。

「AVIFは魔法」。 圧縮効率は素晴らしいが、エンコードは遅い。僕のM2 MacBook Airで2400×1600の写真1枚を avifenc --speed 4 で処理すると5–9秒、--speed 0 なら30秒を超える。旧型モバイル端末でのデコード負荷も無視できない。AVIFはバッチパイプラインやビルド時最適化には向くが、ユーザーアップロードをホットパスで変換するには荷が重い。

「とりあえずJPEGでいい」。 2015年頃までは現実的な選択だったが、今は同等品質でより小さいWebPが広く使えるので、新しいパイプラインではWebPを基準に置く方が素直だ。

「高品質設定は常に価値がある」。 JPEGやWebPで品質85を超えると、ファイルサイズの伸びが知覚品質の伸びを追い越す。品質85と95の見分けはほぼつかないのに、ファイルは2倍になる。品質スライダーを線形と思い込まず、SSIMやbutteraugliのような知覚尺度で測るべき。

「よく圧縮すればリサイズは不要」。 画像配信でいちばん大きな節約は、たいてい適切なサイズにリサイズすることであって、圧縮のチューニングではない。800ピクセル幅のWebPは、品質設定に関係なく、3000ピクセル幅のWebPより常に軽い。画素を近似するのではなく、そもそも取り除いているからだ。

チェックリスト

  1. 画像ソースはベクターか? → はい:SVGで保存。
  2. 透過が必要か?
    • はい & 写真系 → WebP(不可逆+アルファ) または AVIF。
    • はい & ロゴ/アイコン → PNG または 可逆WebP。
  3. アニメーションが必要か? → アニメーションWebP、APNG、AVIF。GIFの256色パレットは写真に不向き。
  4. 写真・グラデーション中心か? → 不可逆WebPを基本に、帯域重視ならAVIFを追加。
  5. スクリーンショット・文字中心か? → PNGまたは可逆WebP。
  6. 最大限の互換性が必要か? → <picture> 要素でAVIF → WebP → JPEGの順にフォールバック。

関連ツール

この記事で扱ったトレードオフはそのまま Patrache Studioの画像圧縮ツール で試せる。画像は大きなアセットパイプラインの一部として扱われることが多いので、関連ガイドも一緒に読むと判断基準が揃う。ブラウザ内PDF結合・分割のセキュリティ上の利点 は画像が契約書やスキャン束の中に収まっていくときの話を扱い、QRコードのセキュリティ落とし穴 は商品パッケージやポスターに走査可能なQRが含まれる場合に役立つ。

参考文献

関連ツール

tools.patrache.studio/image/compress/