WebP vs AVIF vs JPEG：2026 年に選ぶべき画像フォーマットはどれか

要点。AVIF は WebP より 20〜30%、JPEG より 30〜50% 小さい。WebP も JPEG より 25〜35% 程度小さい。一方で AVIF のエンコードは WebP の 5〜20 倍遅く、デコード速度では WebP が三者の中で最速だ。2026 年に勝つワークフローはこうだ。AVIF を最優先で配信し、ダメなら WebP、最後の安全網として JPEG を残す。そして <picture> 要素に選択を任せる。

ほとんどの読者にはこれで十分な答えだろう。本当に面白いのは「いつ AVIF を使わないのか」だ。CI のリソース予算が厳しく、バイト数よりエンコード時間が重い場面では避けたほうがいい。ブラウザ側の AVIF エンコード対応がまだ不安定なため、リアルタイムのユーザーアップロードでも採用は見送ろう。生き残っている iOS 16.0〜16.3 や古い Edge をサポートしなければならないなら、JPEG を主役のままにしておく。それ以外の場面では AVIF がファイルサイズで勝つ。ただし <picture> のマークアップが正しく、CDN が適切な MIME タイプを送ることが前提だ。

ここから先はその実務の詳細を見ていく。2026 年の対応状況、実写ベンチマーク、ユースケース別の判断ツリー、コピペ可能な <picture> パターン、変換コマンド、そしてチームが時間を溶かす 4 つの落とし穴。今すぐ変換だけ済ませたいなら、画像圧縮ツール（無料）が JPEG・PNG・WebP・AVIF をブラウザ内で処理する。ファイルはどこにもアップロードされない。

1. 2026 年のブラウザ対応：WebP は 97%、AVIF は 93%

Edge が AVIF に対応してから 2 年半が経ち、対応ギャップはグローバルトラフィックの数パーセントまで縮まった。問いはもう「対応しているか」ではなく「最後の 3% に何を出すか」になっている。

1.1 WebP：安全なデフォルト

WebP は 2012 年に Chrome、2019 年に Firefox 65、2018 年に Edge 18、2020 年に Safari 14 で出荷された。2026 年 5 月時点の caniuse によると、グローバル対応率はおよそ 97% だ。WebP はもはや「モダンな代替手段」ではなく「普通に使えるフォールバック」のポジションに移った。JPEG 以外のフォーマットを 1 つだけ配信するなら、WebP を選ぶ。

1.2 AVIF：主役として使える段階に到達

AVIF は 2020 年 8 月の Chrome 85、2021 年 10 月の Firefox 93 で登場した。Safari 16.4 が 2023 年 3 月に macOS と iOS で有効化、Edge は遅れて 2024 年 1 月の 121 でようやくデコード対応を追加した。2026 年 5 月のグローバルカバー率は 93〜95% 程度だ。

ただし 1 点だけ注意がある。iOS 16.0〜16.3 には、特定の画像で Safari をクラッシュさせる既知の AVIF デコードバグが残っている。これらのビルドは企業 MDM で更新が抑えられたデバイスにまだ生き残っているため、WebP や JPEG のフォールバックが効いていない AVIF は実際の障害リスクになる。「単独の主役」ではなく「保険つきの主役」として扱おう。

1.3 互換性早見表

フォーマット	グローバル対応率（2026 年 5 月）	主な制約
JPEG	100%	ファイルが最大、透過なし、HDR なし
WebP	約 97%	HDR や 10-bit カラーに非対応
AVIF	約 93〜95%	エンコードが遅い、iOS 16.0〜16.3 のデコードバグ、Edge 121 以上が必要

2. 中核となる違い：圧縮率、速度、機能

2.1 実写でのファイル圧縮効率

同じ素材を使ったベンチマークを 1 本だけ用意した。4000×3000 の風景写真、元の PNG は約 24 MB、知覚的に同等の品質で再エンコードした結果はこうだ。

エンコード	サイズ	JPEG ベースライン比
JPEG q75（mozjpeg）	約 2.1 MB	0%（基準）
WebP q75（libwebp）	約 1.4 MB	33% 小さい
AVIF q60（libavif、cpu-used 4）	約 1.0 MB	52% 小さい

ここでの AVIF q60 は視覚的に JPEG q80・WebP q75 と同等だ。品質スケールはコーデック間で互換ではない。「JPEG q75 を AVIF q75 に再エンコード」は典型的な初心者ミスで、元画像と見分けがつかないのに無駄に肥大化した AVIF が出来上がる。

2.2 エンコード速度：5〜20 倍の代償

AVIF が強く圧縮できるのは、それだけ多くの仕事をしているからだ。libavif の既定値 cpu-used 4 で 4000×3000 の画像を処理すると、libwebp の 5〜20 倍、mozjpeg のおよそ 50 倍の時間がかかる。このコストは CI ビルド、Lambda のコールドスタート、何千枚もの素材を再エンコードするパイプラインで雪だるま式に膨らむ。

逃げ道は 2 つ。cavif --speed 9（あるいは libavif の cpu-used 9）なら libwebp の 3 倍以内に収まり、ファイルサイズは 5〜8% ほど大きくなる程度で済む。もう 1 つは積極的なキャッシュだ。コンテンツアドレッシングで未変更の素材の再エンコードをスキップするアセットパイプラインを組んでおけば、遅いコーデックも一度きりのコストになる。

2.3 色深度と HDR

JPEG と WebP は 8-bit sRGB が上限だ。AVIF は 10-bit と 12-bit カラー、Rec. 2020、DCI-P3、PQ/HLG のトランスファーファンクションをネイティブで扱える。HDR 動画のサムネイル、プロ向け写真ギャラリー、ブラウザ上での印刷プルーフなら、現時点で標準化された選択肢は AVIF しかない。

2.4 透過とアニメーション

JPEG にはどちらもない。WebP と AVIF はアルファとアニメーションの両方を扱える。透過 PNG の置き換えに限れば、AVIF はアルファをよりコンパクトに圧縮する。WebP に変換すると 30〜40% しか縮まなかった UI イラストが、AVIF では 50〜70% 縮むことが多い。

3. 判断ツリー：どの仕事にどのフォーマットか

3.1 静的サイト：ブログ、マーケティングページ、ドキュメント

AVIF を主役、WebP をフォールバック、JPEG を安全網に。エンコードは CI で一度きりなので、5〜20 倍の代償はビルド時間で払うだけで、ユーザーの待ち時間にはならない。これは 4 章で扱う 3 ソース構成の <picture> パターンが最も素直にはまるケースだ。

3.2 ユーザーアップロード：アバター、UGC、フォーム添付

ブラウザ側で WebP に圧縮し、サーバー側で非同期に AVIF へ再エンコード。ブラウザ側の canvas.toBlob('image/avif') は現時点で Chrome 99 以降でしか動かないため、AVIF をアップロード経路にはできない。WebP はブラウザ内で高速に圧縮でき、アップロード自体の帯域も節約できる。

クライアント側ライブラリ（Squoosh、browser-image-compression、Compressor.js）の比較や、サーバー側の Sharp / Imagemin との組み合わせ方は、姉妹記事の画像圧縮：ブラウザ vs Node.js 比較ガイドで詳しく扱っている。フォーマットの選択と処理場所の選択は直交する軸で、本記事はフォーマット軸の話だ。

3.3 HDR と高品位写真

AVIF 一択。今のオープンウェブで 10-bit や 12-bit カラーをサポートするのは AVIF だけだ。HDR 専用素材ではフォールバックを切り捨てるか、JPEG フォールバックは SDR で妥協するかのどちらかになる。

3.4 レガシーブラウザ比率の高い読者層

JPEG を主役、WebP は任意、AVIF はなし。政府系ポータル、特定の東アジア企業環境、デバイステールが長い B2B ツールでは、解析データに 5〜10% の IE / 旧 Edge トラフィックが残っていることがある。WebP はもう安全圏、AVIF はまだ早い。

3.5 リアルタイム CDN 配信

サーバー側 libvips / Sharp で WebP をストリーミングしつつ、AVIF はバックグラウンドワーカーで生成してキャッシュヒット時に配信。AVIF のエンコードでレスポンスをブロックしてはいけない。Cloudflare Polish、Vercel Image Optimization、Cloudinary の f_auto がこのパターンを自動化してくれる。

4. `<picture>` フォールバックを正しく書く

<picture> 要素は、ブラウザに対応している中で最良のソースを選ばせるためにある。AVIF を先頭に並べた 3 層構成にしておけば、古いクライアントを壊さずに最適なバイト予算を確保できる。

4.1 3 層のベースライン

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg"
       width="1200" height="800"
       alt="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

押さえておきたい点はいくつかある。ブラウザは <source> 要素を上から順に走査し、type を理解できた最初のものを採用する。それ以外はダウンロードすらされず無視される。<img> タグが実際にレンダリングされる要素であり、どのソースが勝っても alt・sizes・class といった属性はそこから受け継がれる。2026 年において <img> の width と height はもう任意ではない。領域を確保し、Cumulative Layout Shift を防ぐ役割を持つ属性だ。

ファーストビューに入る画像では loading="lazy" を loading="eager" fetchpriority="high" に置き換えよう。LCP 画像を遅延読み込みするのは、Core Web Vitals でもっとも踏みやすい地雷だ。

4.2 レスポンシブ＋フォーマット：完全版パターン

レスポンシブな解像度にも対応するなら、各 <source> の中で srcset を繰り返す。

<picture>
  <source type="image/avif"
          srcset="/img/hero-800.avif 800w,
                  /img/hero-1600.avif 1600w,
                  /img/hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="/img/hero-800.webp 800w,
                  /img/hero-1600.webp 1600w,
                  /img/hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="/img/hero-1600.jpg"
       width="1600" height="900"
       alt="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

そう、画像 1 枚あたり 9 ファイル生成することになる。この規模ではビルドステップが必須で、何を組み込めば良いかは 5.3 節で紹介する。

4.3 サーバー側 `Accept` ネゴシエーションという選択肢

CDN がサポートしているなら、コンテンツネゴシエーションを使ってマークアップを単一の <img> タグまで畳める。ブラウザが Accept: image/avif,image/webp,image/apng,*/* を送り、CDN は同じ URL に対して最良のフォーマットを返す。

Cloudflare Polish、Vercel Image Optimization、Cloudinary の f_auto、CloudFront + Lambda@Edge はどれもこの方式を実装している。トレードオフは、HTML が小さくなり画像 URL も 1 本にまとまる代わりに、CDN ロックインが発生し、ローカルでのデバッグが難しくなる点だ。実用的な落としどころとしては、マーケティングページは CDN ネゴシエーション、決定論的な挙動が求められるプロダクト UI では明示的な <picture> という併用パターンが定石になる。

5. 画像をフォーマット間で変換する方法

5.1 ブラウザ内で完結、アップロードなし

単発や少量バッチの最短ルートはブラウザ完結だ。JPEG を画像圧縮ツール（無料）に放り込み、出力を WebP か AVIF に選ぶだけで、ファイルはマシンの外に出ない。AVIF の入力はどこでも読める。AVIF 出力は Chrome 85 以上でブラウザネイティブのエンコーダを使い、AVIF をまだエンコードできないブラウザでは黙って WebP へフォールバックする。

5.2 ビルドパイプライン向けコマンドライン

本番パイプラインでは、決定論的な出力と再現可能なビルドが欲しくなる。次の 3 つのコマンドはどれも実用的だ。

# AVIF: cavif（Rust 製、cargo か brew で簡単インストール）
cavif --quality 60 --speed 4 input.jpg -o output.avif

# WebP: cwebp（Google 公式の libwebp）
cwebp -q 75 -m 6 input.jpg -o output.webp

# 両方＋リサイズも、libvips で（バッチ処理が最速）
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed は 0（最遅・最小）から 10（最速・最大）まで指定できる。既定値の 4 はナイトリービルド向けのスイートスポット。バイトより速度を優先したい PR プレビューでは 9 まで上げよう。

5.3 ビルドパイプラインへの組み込み

主要な静的サイトフレームワークはすでにこれらのエンコーダをラップしている。スタックに合うものを選べばいい。

// Next.js — next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
  },
};

// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/sharp' },
  },
});

// プログラマブルに — Sharp（Node.js）
import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600 })
  .avif({ quality: 60, effort: 4 })
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600 })
  .webp({ quality: 75, effort: 6 })
  .toFile('output.webp');

5 KB 未満のアイコン、インラインアバター、メールヘッダーといった極小素材なら、ネットワークごと省略してBase64 エンコードで data URI としてインライン化するのも手だ。HTTP リクエスト 1 本を HTML の数バイトと交換する取引で、おおむね 5 KB 以下なら割に合う。

クライアント側と Node 側の圧縮ライブラリ（Sharp vs Squoosh vs browser-image-compression）の選択で迷っているなら、画像圧縮：ブラウザ vs Node.js 比較ガイドがベンチマークとトレードオフをさらに細かく扱っている。

6. 落とし穴と誤解

6.1 「AVIF が常に勝つ」、スクリーンショットや線画では違う

AVIF が真価を発揮するのは連続階調の写真だ。シャープな文字を含むスクリーンショット、UI キャプチャ、ピクセルアートでは、同等品質で WebP のほうが小さくなることが多い。AVIF のデブロッキングは、ベタ塗り領域に微妙なバンディングを生むこともある。両方変換して、アセット種別ごとに勝者を選ぼう。

6.2 「ロスレス WebP は透過 PNG を完全に置き換える」、ほぼそうだが完全一致ではない

WebP のロスレスは PNG より確かに小さく、おおむね 26% 縮む。ただし「ロスレス」は圧縮画像に対する概念であり、エンコーダは高勾配領域でアルファの丸めを変えてしまうことがある。ピクセル完全な再現が必要な用途（医療画像、アーカイブ素材、ソースとの一致が法的に求められるもの）では PNG を残そう。それ以外では WebP ロスレスのほうが正味で得だ。

6.3 「`.avif` ファイルを置けば終わり」、CDN がそれを知らないかもしれない

古い nginx や Apache の設定は AVIF より前から動いている。/etc/nginx/mime.types に image/avif avif; がなければ、nginx は AVIF を application/octet-stream として配信してしまう。ブラウザは誤った Content-Type を見て画像を描画せず、こっそり JPEG にフォールバックする。最適化の意味が丸ごと吹き飛ぶわけだ。デプロイ後にアセット URL を curl して Content-Type ヘッダを確認しよう。5 秒のひと手間が「なんで本番で AVIF が動いていないんだ」という 1 週間を救う。

6.4 iOS 16.0〜16.3 の AVIF クラッシュ

特定の AVIF ファイルは iOS 16.0〜16.3 の Safari をデコード時にクラッシュさせる。バグは 16.4（2023 年 3 月）で修正済みだが、企業 MDM や緩慢な OEM アップデートのせいで古い端末は生き残っている。緩和策は 2 つ。同じ <picture> の中に動作する WebP ソースを必ず併置すること、そして <img> の src 属性に直接 AVIF を指定しないこと。4 章のパターンに従っていれば、ここはすでに守られている。

7. 2026 年のチートシート

シナリオ	主役	フォールバック	エンコーダ
静的なマーケティングページ	AVIF q60	WebP q75 + JPEG q80	CI 上の cavif + cwebp
ブログ記事・ドキュメント	WebP q75	JPEG q80	画像圧縮ツール（無料）（手動）または Sharp（ビルド時）
ユーザーアップロード	WebP（クライアント側）	JPEG（WebP エンコード非対応ブラウザ）	browser-image-compression＋サーバー側 Sharp で AVIF
HDR / プロ写真	AVIF 10-bit q70	なし（SDR フォールバックを諦めるか、AVIF を見送るか）	cavif + libavif の HEIF モード
リアルタイム CDN 配信	ネゴシエーション（AVIF または WebP）	JPEG	Cloudflare Polish、Cloudinary `f_auto`、Vercel Image

出荷前に押さえておきたいことが 2 つ。<img> には必ず width と height を設定して CLS を防ぐ。AVIF レスポンスのうち少なくとも 1 本は本番の Content-Type ヘッダを検証する。壊れた MIME 設定ほど、本番の AVIF を静かに殺している原因はない。

FAQ

2026 年でも JPEG フォールバックは必要か？

必要だ。AVIF はグローバルユーザーのおよそ 93%、WebP は約 97% に届く。残った小さくて確実な層、つまり古い Edge、Firefox 93 未満、iOS 16.4 より前、それに iOS 16.0〜16.3 のバグ圏、こうした層には JPEG が必要になる。アナリティクスで該当ブラウザのトラフィックが実質ゼロだと証明できる場合に限って、JPEG を捨てていい。

AVIF のエンコードが遅いとき、CI ビルドを速く保つには？

使えるレバーがいくつかある。cavif --speed 6 以上（既定は 4）にして、サイズを 5% 譲って速度を 3 倍稼ぐ。GNU parallel やビルドツールのワーカープールでコア間に並列化する。コンテンツハッシュでキャッシュし、変更のないソースはエンコーダを完全にスキップさせる。組み合わせれば、AVIF のビルド時間を旧シングルスレッド時代の WebP より下に抑えられることが多い。

WebP のデコードは本当に AVIF より速いのか？

そうだ。libwebp は libavif の 2〜3 倍のスピードでデコードでき、ローエンドのモバイルでは差がさらに広がる。ボトルネックがネットワークではなくデコードにあるなら（廉価な Android 端末で長い画像ギャラリーを開くようなケース）、主役を WebP にしたほうがいい。一般的なウェブトラフィックではネットワーク削減効果のほうが支配的なので、AVIF が総合で勝つ。

iPhone ユーザーは AVIF を見られるか？

iOS 16.4（2023 年 3 月）以降の iPhone なら Safari がネイティブに AVIF をサポートする。iOS 16.0〜16.3 のデバイスには、特定の AVIF ファイルで Safari をクラッシュさせる既知のデコードバグが残っており、それより古い iOS は AVIF をまったくサポートしない。<picture> の中に WebP か JPEG のフォールバックを必ず仕込んで、影響を受けるユーザーにも何かが見えるようにしておこう。

`<picture>` と Accept ヘッダのネゴシエーション、どちらを選ぶ？

小規模プロジェクトでは明示的な <picture> マークアップが向いている。挙動が決定論的でローカルでデバッグでき、画像あたり HTML が増えるのは 80 バイト程度。トラフィックの多いサイトでは CDN 側の Accept ネゴシエーションが効く。画像 1 枚あたり URL は 1 本、フォーマットは自動アップグレード、CDN は各フォーマットを別々にキャッシュする。よくあるハイブリッドは、アプリ UI には <picture>、マーケティングアセットには CDN ネゴシエーション、という組み合わせだ。

PNG を WebP に変換したらサイズが大きくなった、なぜ？

ほぼ確実に、元の PNG がすでに pngquant や oxipng、ZopfliPNG で十分に最適化されていて、ブラウザの Canvas ベースのエンコーダがそれに追いつけないからだ。最適化済みの PNG ではなく、オリジナル（Photoshop の書き出し、デザインツールのマスター、RAW）から再エンコードしよう。最適化済み PNG しか手元にないなら、それはほぼ最適に近いということ。下手に触らず、そのまま置いておこう。

AVIF は透過をサポートしているか？

サポートしている。AVIF は 8〜12-bit のフルアルファチャンネルを扱え、アルファのエンコードはおおむね WebP より小さく済む。透過 PNG イラストを AVIF に変換すると 50〜70% 縮むことが多いのに対し、WebP では 30〜40% にとどまる。ピクセル完全なロスレスを要求しない限り、透過 PNG の置き換えとしては AVIF が一番強い。

ブラウザは `toBlob('image/avif')` でネイティブに AVIF をエンコードできるのか？

現時点では Chrome 99 以上だけだ。Safari と Firefox は AVIF のデコードはできるが、2026 年 5 月時点で Canvas API 経由のエンコードはできない。クライアント側で AVIF をエンコードするには libavif-wasm や jsquash のような WebAssembly ライブラリが必要で、1〜2 MB のペイロードが上乗せになる。本番スタックの大半は、ブラウザ側では WebP に圧縮し、AVIF 生成はサーバーワーカーに引き渡している。