WebP / AVIF / JPEG の使い分け — 2026年の実用選択ガイド

この比較での JPEG は、Webで一般的なベースライン逐次 DCT 方式を指します。JPEG 規格群には別のモードもあるため、規格全体の全機能を表す表ではありません。

項目	JPEG	WebP	AVIF
登場年	1992	2010	2019
標準化・開発主体	JPEG委員会	Google	Alliance for Open Media
圧縮効率	広く比較基準に使われる	同等の知覚品質で JPEG より小さくなることが多い	WebP/JPEG より小さくなることがあるが、画像と設定に依存
透過	×	◯	◯
アニメ	×	◯	◯
ロスレス	×	◯	◯
ブラウザ対応	非常に広い	主要な現行ブラウザ	主要な現行ブラウザ。古い OS・ブラウザは要確認
エンコード速度	一般に速い	設定次第	高圧縮設定では重くなりやすい
デコード速度	実装・画像次第	実装・画像次第	実装・画像次第

世界全体の利用率を自サイトへそのまま当てはめることはできません。主要ブラウザの対応状況は更新され続け、Safari の AVIF 対応も OS とバージョンの組み合わせで差があります。実際の対象環境は互換性資料と自サイトの計測で確認してください。

AOMedia の仕様では、AVIF は AV1 ビットストリームの構文・意味の一部を HEIF ファイルへ格納する画像形式です。単なる動画フレームの切り出しではなく、静止画・画像シーケンス向けの構造と制約を定めています。主な強みは次の通りです。

• 圧縮効率: 画像と設定によっては、同等の知覚品質で JPEG や WebP より小さくできる
• ビット深度: プロファイルに応じて 10bit/12bit を扱え、HDR画像の格納にも対応
• 透過と アニメーション: 単一フォーマットでカバー

欠点:

• エンコード負荷が高くなりやすい: 実装・設定・入力によって差がある。たとえば Next.js の公式資料では、AVIF は WebP より一般にエンコード時間が長いと説明されており、サーバーサイドの初回変換や静的サイト生成の時間に影響し得る
• 小さい画像では効果が薄い: アイコン・サムネイルレベルではメタデータのオーバーヘッドで JPEG より大きくなることも
• 古い環境との互換性: Safari 16 世代でも OS によって対応時期が異なるため、単純な「Safari 16+」判定では不十分

また、静止 AVIF と AVIF 画像シーケンスの対応開始時期は同じとは限りません。アニメーションを配信する場合は、単なる image/avif 対応ではなく、対象ブラウザが画像シーケンスを再生できるかを機能別に確認します。

HTML 標準が提供する方法が <picture> 要素です。ブラウザは <source> 要素を記述順に評価し、最初に条件を満たすソースセットを選んだうえで、その srcset から表示条件に合う画像候補を選択します。該当する <source> がなければ、内側の <img> がフォールバック元になります。

<picture>
  <source srcset="/hero.avif" type="image/avif" />
  <source srcset="/hero.webp" type="image/webp" />
  <img src="/hero.jpg" alt="..." width="1200" height="630" />
</picture>

注意点:

• <img> では原則として width と height などで表示比率を予約する(CLS 対策)
• alt 属性を忘れない
• source の順番は採用したいソースセットの優先順位で並べる。「新しい順」が HTML の規則なのではなく、ブラウザは条件を満たす最初の source を採用し、その srcset 内から記述子や表示条件に応じて画像候補を選ぶ

Next.js (Image コンポーネント)

現在の Next.js Image の既定出力形式は WebP のみです。AVIF も使う場合は next.config.js で明示します:

// next.config.js
images: {
  formats: ["image/avif", "image/webp"],
}

WordPress

WordPress 5.8 は WebP、WordPress 6.5 は AVIF のアップロードと画像処理に対応しました。ただし AVIF はホスト側の Imagick または LibGD が AVIF を扱える場合に限られます。また、コアだけで閲覧環境に応じた AVIF/JPEG の自動出し分けまで行うわけではありません。既存画像の変換や CDN での形式交渉は別途設計が必要です。

Cloudflare Images / Cloudinary

Cloudinary は変換指定 f_auto、Cloudflare の URL 変換は /cdn-cgi/image/format=auto/... のように、サービスごとに異なる構文で自動形式選択を提供します。共通の ?format=auto という API ではありません。キャッシュキーや Accept ヘッダーの扱いも各サービスの公式資料を確認してください。

写真(JPEG がデファクトだった領域)

AVIF → WebP → JPEG は有力な候補です。ただし、各形式を同じ見た目の品質で比較し、生成・キャッシュ・保守コストを含めて採用します。常に3形式が最小サイズになるとは限りません。

透過が必要な画像(PNG 領域)

写真調の透過画像では AVIF → WebP → PNG が候補になります。一方、ロゴやUIパーツのように輪郭が鋭い画像では、WebP/AVIFの可逆設定を含めて画質と容量を比較し、PNGやSVGも残して判断します。図形として表せるロゴはSVGが適することが多いです。

アニメーション(GIF 領域)

動画(MP4 や WebM)に置換する案を先に比較します。画像として扱う必要があるなら、対応環境と実測サイズを確認したうえでアニメーション WebP や AVIF 画像シーケンスを検討します。

アイコン・超小サイズ画像(1KB未満)

図形として表せるアイコンなら SVG が適することが多いです。ラスタが必要なら PNG/JPEG/WebP/AVIF を実測し、形式のヘッダーやコンテナ情報が占める比率も確認します。

レガシー対応が絶対必要(IE11含む)

<picture> を解釈しない古いブラウザでも、内側の <img src="...jpg"> は通常の画像として扱われます。そのため、写真なら JPEG、透過や図版なら PNG など、対象環境で表示できる形式を内側の <img> に指定します。IE11 自体はサポート終了済みなので、対象に含めるかは要件として明示します。

AVIF/WebP で転送量が減れば LCP 改善に寄与する可能性がありますが、LCP はサーバー応答、画像発見の早さ、優先度、デコード、レンダリング遅延にも左右されます。形式を変えるだけで必ず改善するとは限らないため、フィールドデータで確認します。

ファーストビュー外の画像には loading="lazy" が有効です。次は画面外画像の例です。LCP 候補や初期表示画像は遅延読み込みせず、必要に応じて取得優先度も検討します。

<picture>
  <source srcset="/img.avif" type="image/avif" />
  <source srcset="/img.webp" type="image/webp" />
  <img
    src="/img.jpg"
    alt="..."
    width="800"
    height="600"
    loading="lazy"
    decoding="async"
  />
</picture>

初期表示されるヒーロー画像やLCP候補には lazy を付けません。一方、ヒーロー用途の画像でも初期表示されない別ビューポートや非表示スライドにある場合は、一律ではなく実際の表示条件で判断します。LCP 候補を遅延させると指標が悪化します。

• 写真では AVIF → WebP → JPEG が有力だが、自サイトの画像と設定で比較する
• AVIF は小さくできる場合がある一方、高圧縮設定は生成コストが大きくなりやすい
• picture の source 要素は新旧ではなく、採用したいソースセットの優先順位で並べる
• width/height でレイアウトを確保し、画面外画像だけを遅延読み込みする
• 小さいアイコンは SVG が適することが多い。ラスタ画像の形式数は効果と運用コストで決める
• CDN の自動形式選択はサービス固有の構文・キャッシュ仕様を確認する