AVIF vs WebP vs JPEG：実測圧縮比較と選び方の指針

最終更新：July 25, 2026

WebP はほとんどのウェブ画像におけるデフォルトの選択肢です。私のテストでは JPEG より 56–64% 小さく、現在のすべてのブラウザで表示できます。AVIF はさらに強力に圧縮し、JPEG より 81–89% 小さくなりますが、エンコードは約 2～3 倍遅くなります。JPEG はメールとレガシーシステム専用に残してください。以下の数値は、私が実際に実行した 4 枚の画像ベンチマークから得たものであり、どのフォーマット解説でも互いに受け売りしている「AVIF は 50% 小さい」という使い古された主張ではありません。

簡単な回答：AVIF、WebP、それとも JPEG？

オーディエンスが表示できる最小のフォーマットを選びましょう。ほとんどのサイトでは、まず AVIF、次に WebP をフォールバック、最後に JPEG となります。私は同一画质で 3 つのフォーマットを 4 タイプの画像でテストし、AVIF はすべてのカテゴリでファイルサイズに勝ちましたが、WebP は 3 分の 1 の時間でエンコードできました。

1 つのフォーマットだけを提供するなら、WebP を選びましょう。現在のすべてのブラウザで動作し、バイト数を半分以上節約できます。<picture> で複数フォーマットを提供できるなら、写真には AVIF を先頭にしてください。Image Converter と Image Compressor は 1 枚のソース画像から 3 つすべてを書き出せます。

「AVIF は 50% 小さい」という通説が過小評価である理由

ほとんどのフォーマット解説は同じ 3 つの数字を繰り返しています。「AVIF は JPEG より約 50% 小さい」「AVIF は WebP より約 20% 小さい」「WebP は JPEG より 25–34% 小さい」の 3 つで、すべて 1～2 社のベンダー研究に遡り、互いに循環引用しています。私のベンチマークは別の結果を示しています。同一画质で JPEG q80 と比較して、AVIF は 81–89% 小さく、50% ではありません。WebP は 56–64% 小さく、25–34% ではありません。

この差が重要なのは、現実の節約が現実の Core Web Vitals の改善につながるからです。ある解説が「WebP で 25–34% 節約」と語り、あなたがそれに基づいて帯域を計画すれば、半分見落とすことになります。私は sharp の libaom（AVIF）、libwebp、mozjpeg エンコーダーを effort 4 で使って 4 枚画像ベンチマークを実行し、上の表がそのままの出力です。どのパーセンテージ（私のものも含め）も信じる前に、ご自身の画像で再現してみてください。

より小さい AVIF ファイルは本当に同じように見えるのか？

はい、写真で適切な品質範囲であればそうです。「AVIF はより小さい」というのが全てではない理由は、品質を下げすぎるとフォーマットごとに異なる壊れ方をするからです。妥当な設定では、通常の視聴距離で差は消えます。

失敗モードはフォーマット固有で、それぞれがどこで崩れるかを示しています：

実用的な教訓：写真では AVIF を 60～70 の品質範囲に保ちましょう。およそ 30 を下回ると、AVIF のテクスチャ平滑化は、より大きい JPEG のリンギングより速く「おかしい」と感じられます。人間の目は欠落したテクスチャより JPEG のアーティファクトの方を許容します。

誰もベンチマークしないエンコード時間のトレードオフ

どのフォーマット解説も「AVIF はエンコードが遅い」と断言して先に進みます。実際のトレードオフをプロットしたものは一つも見当たりませんでした。私は同じポートレート写真を品質 65 で AVIF の effort スライダー全体に渡って計測し、曲線は想定とは異なりました：

Effort 4 がスイートスポットです。最小のファイル（9.8 KB）で、エンコード時間 209 ms は許容範囲です。Effort 6 まで押し上げるとファイルは大きくなり（11.7 KB）、エンコード時間は 536 ms と 3 倍になりました。エンコーダは 2.5 倍長く探索して、より悪い結果に到達しました。比較のため、同じ品質の WebP は effort に関わらず約 70 ms、JPEG は約 45 ms でエンコードされました。

要点：アップロード時に 1 回だけエンコードするなら、AVIF の 200 ms は無視できます。リクエストごとにエンコードするなら、WebP に対する 3 倍の差は積み重なります。そして ship すべきは effort 4（最大ではない）です。

どの画像タイプにどのフォーマットを？

これは AI 回答エンジンに最もよく聞かれる質問で、答えは画像の内容次第です。私の 4 タイプベンチマークに基づきます：

ビルドパイプラインがまだ AVIF を出力できないなら、まず WebP に切り替えましょう。これが最速の単一改善です。バイトを半分以上節約し、サポートも普遍的で、後から <img> マークアップを変えずに AVIF を上に重ねられます。

古いブラウザを壊さずに 3 つすべてを配信するには？

型付き source を持つ <picture> 要素を使いましょう。ブラウザはサポートする最初の型を選び、残りを無視します：

<picture>
  <source srcset="/img/product.avif" type="image/avif">
  <source srcset="/img/product.webp" type="image/webp">
  <img src="/img/product.jpg" alt="Green trail running shoe on white" width="800" height="600" loading="lazy">
</picture>

• 常に JPEG の src を持つ本当の <img> を最終フォールバックとして残しましょう。
• レイアウトシフトを防ぐため <img> に width と height を設定しましょう。
• ファーストビュー下の画像は遅延読み込みし、LCP ヒーローは遅延読み込みしないでください。

フォーマット選択は Core Web Vitals にどう影響するか？

画像の多いページでは、画像が Largest Contentful Paint（LCP） を制御することが多いです。バイトが小さいほどヒーローが早く到着し描画されます。私のファイルサイズ比はおおむね LCP 比に換算できます：

Cumulative Layout Shift（CLS） はフォーマット非依存です。width/height でスペースを確保するかどうかに依存し、バイトのフォーマットには依存しません。現在のデコーダサポートについては Google の 画像と Core Web Vitals のガイダンスと 画像フォーマットリファレンス を参照してください。

いつ JPEG を選ぶべきか？

JPEG は時代遅れではありません。汎用のフォールバックです。HTML メール（ほとんどのクライアントは WebP と AVIF を除去する）、JPEG のみを受け付けるパートナー・マーケットプレースのフィード、WebP より前の古い組み込みブラウザ、再エンコードで一桁 KB しか節約できない小さなサムネイルに残しておきましょう。

関連ガイド

• Compress Images Without Losing Quality
• How to Compress an Image to Under 100KB
• How Image Compression Works
• Complete Image Optimization Checklist

よくある間違い

• 1 枚の巨大な AVIF を提供してリサイズをスキップする。 フォーマットは 400px で表示される 4000px 画像を救いません。まずリサイズし、それからエンコードしましょう。
• 同じ品質数値でフォーマットを比較する。 AVIF q70、WebP q85、JPEG q90 はほぼ同じに見えます。視覚的に揃えた品質で比較しましょう。
• AVIF の品質を 30 以下に下げる。 平滑化はより大きい JPEG より悪く見えます。
• <img> フォールバックを忘れる。 <source> タグだけの <picture> は、未対応クライアントでは何も描画しません。
• ヒーローを遅延読み込みする。 LCP 画像は fetchpriority="high" で先行読み込みすべきです。

シンプルなロールアウト順序

1. PageSpeed Insights で画像バイトと LCP を計測する。
2. JPEG の後ろに WebP をフォールバックとして追加する。互換性リスクなしの即効改善。
3. 写真用に <picture> 内で WebP の上に AVIF ソースを追加する。
4. すべての画像をエンコード前に表示サイズに圧縮・リサイズする。
5. すべての画像にサイズ（width/height）を予約して CLS を固定する。
6. 再計測し、LCP が低下し 404 リクエストがないことを確認する。

よくある質問

AVIF は常に WebP より小さいか？

私の 4 枚画像ベンチマークでは、はい。同一品質で AVIF は全 4 タイプに渡り WebP より 60–73% 小さかったです。フラットなグラフィックやスクリーンショットで差は縮まる可能性がありますが、テストしたすべてのカテゴリで AVIF が勝ちました。

あなたのテストで AVIF は JPEG よりどれだけ小さかったか？

4 種類の画像タイプで同一品質の場合、AVIF は JPEG q80 より 81–89% 小さかったです。ポートレート写真は 90 KB（JPEG）から 9.8 KB（AVIF）になりました。

すべてのブラウザが AVIF をサポートしているか？

現在の主要ブラウザは AVIF をデコードできますが、バージョン 16 未満の古い Safari や一部の組み込み WebView はサポートしないため、<picture> による WebP または JPEG へのフォールバックが必要です。

WebP を唯一のフォーマットとして使うのは安全か？

安全です。WebP は現在の主要ブラウザでネイティブサポートされ、私のベンチマークでは JPEG より 56–64% 小さくなり、AVIF を追加できない場合は堅実な単一フォーマットの選択になります。

AVIF のエンコードは WebP よりどれだけ遅いか？

Effort 4 で、ポートレートで AVIF は約 210 ms、WebP は約 70 ms でした。約 3 倍遅いです。アップロード時に 1 回エンコードすれば差は無関係ですが、リクエストごとにエンコードすれば WebP の速度が重要になります。

どの AVIF effort 設定を使うべきか？

私のテストでは effort 4 がスイートスポットでした。ファイルが最小でエンコード時間も許容範囲です。Effort 6 はファイルを大きくし 2.5 倍の時間がかかったため、最大 effort が最良とは限りません。

ヒーロー画像にはどのフォーマットを選ぶべきか？

AVIF を選び、WebP フォールバックと JPEG <img> ベースを組み合わせましょう。ヒーローのバイトは直接 LCP を制御し、AVIF の JPEG 比 80% 以上の節約はそこで最も速く現れます。

いつ AVIF や WebP ではなく JPEG を使うべきか？

HTML メール、パートナー・マーケットプレースのフィード、印刷パイプライン、および WebP と AVIF サポートより前の古い組み込みブラウザには JPEG を残してください。

画像クレジット

• カバー — ノート PC、一眼レフ、タブレットで写真を編集する写真家、Pexels の cottonbro studio による写真（WebP に変換）。
• フォーマット比較、ファイルサイズチャート、アーティファクト拡大 — 作者がオウムの羽の写真（Pexels #36720663、Kaca Skok による写真）から生成。4 タイプ圧縮ベンチマークと AVIF effort スイープは、sharp の libaom、libwebp、mozjpeg エンコーダーを使用し、実際の写真の圧縮性に較正した合成テスト画像で生成しました。