webp avif 比較：2026年の対応状況・サイズ・フォールバック

webp avif 比較の結論を先に述べます。事前にエンコードできるならAVIFを先に配信し、WebPかJPEGをフォールバックにしてください。エンコードを速く行う必要がある場合や、単一の簡単な形式で済ませたい場合はWebPだけを使います。どちらも2026年10月時点でBaselineとして広く利用可能なので、ブラウザ対応はもう決め手になりません。WebP画像の上限は16383 × 16383 pxです（WebPのFAQ）。これが問題になるのは極端に大きなパノラマだけです。web.devが公開したテストでは、AVIFは同じ見た目の品質でより小さいファイルを生成し、HDRにも対応しました。一方、WebPのエンコードははるかに速いです（web.dev、2023年の更新）。バイト数の差は画像によって異なるため、採用前に自分の写真で測ってください。

WebPとAVIFの比較一覧

2つの形式は、対応状況よりもコストと機能で大きく異なります。対応状況のデータはweb-features 3.44.0（2026年10月22日）によるもので、その他の行はGoogleのWebP文書とweb.devによります。

AVIFは、2024年1月25日にEdge 121が対応したことで「新たに利用可能」になり、30か月後の2026年7月25日に「広く利用可能」になりました。解析データでSafari 16やEdge 121より古いブラウザがまだ一定の割合を占めるなら、フォールバックを残してください。

ファイルサイズ：どちらが小さいか

web.devが公開した比較ではAVIFの方が小さくなりましたが、差は大きくばらつくため、1つの割合だけでは誤解を招きます。Googleの公表値では、WebPはJPEGより25〜34%小さいとされています。web.devのAVIFの記事は「JPEGに比べて50%超の削減」と述べていますが、圧縮の設定や内容、品質目標によって実際の削減率は変わると注意しています。さらに、2023年のweb.devの更新では、Imgixの測定としてJPEG比60%減、WebP比35%減が紹介されています。これらは異なる画像セットによる数値なので、自分の画像で測定してください。

結果は内容によって変わるため、自サイトの少なくとも3種類の画像でテストしてください。大きな写真、文字を含むスクリーンショットやグラフ、小さなサムネイルです。それぞれを複数の品質設定でエンコードし、許容できる品質でのファイルサイズを比べます。ツールはcwebpと、libavifのavifencを使います。

# WebP、品質75
cwebp -q 75 hero.jpg -o hero.webp

# AVIF、調整の出発点として品質60、8スレッドを使用
avifenc -q 60 --jobs 8 hero.jpg hero.avif

ls -l hero.*

Squooshならブラウザ上で同じことを、左右の比較スライダー付きで行えます。画像が少ないときに便利です。

エンコード速度とツール

WebPはエンコードが速く、画像をリクエストごとに生成する場合にはこの差が効きます。web.devの2023年の更新では、オンザフライ利用ではAVIFが一般的なエンコーダーの中で最も遅いとされています。ただし、事前にエンコードする場合は既定の設定でも十分競争力があります。avifencには--speedがあり、0（最も遅い）から10（最も速い）まで指定でき、既定値は6です。速度を上げると圧縮効率は下がります。web.devは8スレッドで約5倍速くエンコードできたと報告していますが、テストの詳細は記載していません。

実際には次のように考えてください。

• ビルド時に画像を生成するパイプライン（静的サイト、キャッシュ付きのnext/image、キャッシュ付きの画像CDN）では、各画像を一度だけエンコードすればよいため、AVIFを扱いやすいです。
• キャッシュなしでその場でリサイズする用途では、WebPの速さが効きます。
• CMSへのアップロード：パイプラインを変える前に、CMSがAVIFを受け付けるかを確認してください。WordPressは6.5（2024年）以降AVIFのアップロードに対応していますが、サーバーのImagickまたはGDライブラリが対応している場合に限られます。ツール > サイトヘルス > 情報 > メディア処理で確認できます（WordPressの公式ブログ）。

pictureでフォールバック付きに両方配信する

<picture>要素を使うと、各ブラウザが上から順に対応する最初の形式を選び、対応しなければ<img>を使います。

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w" sizes="100vw">
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w" sizes="100vw">
  <img src="hero-800.jpg"
       srcset="hero-800.jpg 800w, hero-1600.jpg 1600w" sizes="100vw"
       width="1600" height="900" alt="Product on a desk">
</picture>

スマートフォンでは次の3点が重要です。

• <img>のwidthとheightを指定すると、ファイルが届く前にブラウザが場所を確保できます。これにより、画像の読み込み時のレイアウトシフトを防げます。
• srcsetとsizesを使うと、幅390px・ピクセル比2の端末は1600wではなく800wのファイルを選びます（390 × 2 = 780の物理ピクセル）。ピクセル比3の端末は1170の物理ピクセルが必要なので、1600wのファイルを選びます。スマートフォン向けの画像サイズの決め方はモバイル対応サイトの作り方で扱っています。
• alt、loading、fetchpriorityは<img>に付けます。<source>には付けません。

CSSの背景画像では、type()を使ったimage-set()で同じことができます。2026年3月からBaselineで広く利用可能です。

.hero {
  background-image: image-set(
    url("hero.avif") type("image/avif"),
    url("hero.webp") type("image/webp"),
    url("hero.jpg") type("image/jpeg")
  );
}

CDNでのコンテンツネゴシエーション

画像CDNの中には、<picture>の代わりにリクエストのAcceptヘッダーで形式を選ぶものがあります（詳細はCDNのドキュメントを確認してください）。iPhoneではこれに注意が必要です。MDNの既定のAcceptの値の一覧（2026年10月更新）によると、Chromeと Edge 121以降はimage/avif,image/webp,...を送り、Firefoxもimage/avifを送ります。一方、Safariの値はimage/webpから始まり、AVIFを含みません。そのためAcceptだけを読むCDNは、Safari 16.4からAVIFをデコードできるにもかかわらず、Safariに対してWebPを返してしまいます。iPhoneでもAVIFを使いたい場合は、<picture>を使うか、CDNがSafariをどう判別しているかを確認してください。

JPEG XLはどうか

JPEG XLはまだBaselineではないため、フォールバックが必要です。2026年10月時点では、Safari 17以降（静止画のみ）、Chrome 155、Firefox 158（2026年10月13日リリース、リリースノートによる）、Edge 155（2026年10月8日リリース、リリースノートによる）で対応しています。Samsung Internetは未対応で、MDNのbrowser-compat-data 8.1.7ではEdgeも未対応のままのため、web-featuresではBaselineに含まれていません（MDN browser-compat-data）。対応ブラウザ向けに、AVIFの上に3つ目の<source>として追加することはできますが、画像ごとにエンコードが1回増えます。

JPEGで十分な場合

次のような場合、よく圧縮されたJPEGは妥当な選択です。

• マークアップやビルドを変更できず、CMSやCDNが形式を変換してくれない場合。
• 小さなサムネイルで、節約できるバイト数が数キロバイト程度の場合。
• ファイルがユーザーによってダウンロード、メール送信、編集されることを想定している場合。JPEGはどのツールでも開けます。
• すでに端末ごとに適切なサイズを配信していて、ページが画像の監査を通っている場合。

Lighthouse 13（2025年10月）では、古い監査「次世代フォーマットで画像を配信する」は、画像配信のインサイトに統合されました（Chrome for Developers）。これはページ内で最も大きな削減余地を示すものとして扱い、形式を変える前に画像のサイズを確認してください。監査の実行と結果の読み方はLighthouseでのモバイル監査ガイドにあります。

スマートフォン幅のページで結果を確認する

形式を変えた後は、正しいファイルが読み込まれているか、レイアウトが動いていないかの2点を確認してください。DevToolsのNetworkパネルでは、各画像が実際に使った形式とサイズが分かります。Imgでフィルターし、Type列を確認してください。実ユーザーのデータで速度を見るには、モバイルページ速度テストのガイドの方法を使います。

レイアウトの確認には、スマートフォンの幅でページを開きます。Mobile View Extensionは、タブをスマートフォンのユーザーエージェント、画面サイズ、ピクセル比で読み込み直すため、実際のモバイル版のページのレイアウトを確認できます。ただし、画像の重さや読み込み時間は測定できず、デスクトップ版Chromeのエンジンで描画されるため、Safariでの形式の扱いはSafariで確認してください。

よくある質問

AVIFはWebPより優れていますか？

ファイルサイズの点では、公開されたテストではAVIFの方が小さくなっています。web.devの比較では、同程度の見た目の品質でJPEGやWebPより小さく、HDRにも対応します。差は内容によるため、自分の画像で確認してください。エンコード速度が重要な場合や、ツールがAVIFを扱えない場合はWebPの方が適しています。

2026年にAVIFはすべてのブラウザで対応していますか？

現在の主要ブラウザはすべて対応しています。AVIFは2026年7月25日から広く利用可能で、Chrome 85、Firefox 113、Safari 16.4（Safari iOS 16.1）、Edge 121から対応しています。

WebPはまだ使うべきですか？

はい。AVIFの後のフォールバックとして、またはエンコードをリクエストごとに行うパイプラインでは唯一の最新形式として使えます。WebPは2020年のSafari 14以降、主要ブラウザすべてで対応しています。

AVIFはSEOに悪影響がありますか？

ありません。Google検索は、WebP、JPEG、PNG、GIF、BMP、SVGと並んでAVIFを対応画像形式として挙げています（Google Search Central、2026年3月更新）。このページは、形式をランキングのシグナルとしては説明していません。