TL;DR – JPEG/PNG を AVIF（AVIF がサポートされていない場合は WebP）に置き換えると、画像サイズが 30‑80 % 縮小し、LCP が最大 0.5 s 短縮、視覚的な妥協なしで SEO が向上します。シンプルな <picture> フォールバックまたは Accept ヘッダーのルールを使えば数分で実装でき、ほとんどの CDN が自動で重い処理を行ってくれます。
今、なぜ「次世代」画像フォーマットが重要なのか
ウェブではミリ秒単位が重要です。Akamai と Google の調査によると、100 ms の短縮は e‑commerce サイトの収益を 1‑2 % 向上させます。画像は典型的なページで最大の要因で、全バイト数の > 60 % を占めます（HTTP Archive, 2024）。
そこで登場するのが AVIF と WebP。どちらも従来の JPEG/PNG と比べて 30‑80 % 小さなファイルサイズを実現し、視覚的品質は人間の目には区別できません。効果は即座に現れます：
- 帯域幅の削減 → モバイルユーザーのデータプランが安くなる。
- ページ読み込みの高速化 → Core Web Vitals が向上し、Google のランキングが上がる。
- サーバー負荷の軽減 → キャッシュ容量が小さくなり、CDN コストが削減される。
既に CSS/JS の最適化を行っているなら、画像圧縮は最も ROI が高い低コストの改善策です。
AVIF と WebP の比較 – クイックサイドバイサイド
| 機能 | AVIF | WebP |
|---|---|---|
| 起源 | AV1 派生 (ISO/IEC 23000‑22, 2020) | Google の VP8 ベース形式 (2010) |
| 圧縮 | ロスィー & ロスレス (どちらも AV1 ベース)、アルファ、HDR (10‑bit) | ロスィー (VP8)、ロスレス、アルファ、アニメーション |
| ビット深度 | 8‑bit と 10‑bit (HDR) | 8‑bit のみ |
| JPEG に対する典型的なサイズ削減 | 45‑65 % 小さく (ロスィー) | 25‑35 % 小さく (ロスィー) |
| PNG に対する典型的なサイズ削減 | 50‑70 % 小さく (ロスレス) | 30‑45 % 小さく (ロスレス) |
| ハードウェアデコード | GPU のサポートが拡大中 (Intel Xe, AMD, ARM Mali) | ほとんどの CPU/GPU でネイティブ；Android、Chrome、Safari iOS 16+ でハードウェアアクセラレーション |
| アニメーション | AVIF‑A（実験的） | WebP‑A（安定、広く使用） |
| ブラウザ対応状況（2026年4月） | Chrome 85+, Edge 85+, Firefox 93+, Safari 16.4+, Android WebView 85+ | Chrome 23+, Edge 18+, Firefox 65+, Safari 14+, Android WebView 23+ |
結論: AVIF は圧縮率と HDR 対応で優れ、WebP はレガシー対応が最も広く、アニメーションエコシステムも成熟しています。実務的なアプローチは まず AVIF を配信し、次に WebP、最後に JPEG/PNG とフォールバックすることです。
ブラウザ対応とコピー＆ペーストできるフォールバック戦略
1. <picture> パターン（クライアント側交渉）
<picture>
<source type="image/avif" srcset="hero.avif">
<source type="image/webp" srcset="hero.webp">
<img src="hero.jpg" alt="Hero image of a sunrise over the city" loading="lazy" width="1200" height="800">
</picture>
ブラウザは最初に理解できるフォーマットを選択します。古いブラウザは <source> タグを無視し、JPEG フォールバックを読み込みます。
2. サーバー側 Accept ヘッダー交渉（単一 URL 用）
# Nginx example
map $http_accept $image_ext {
default ".jpg";
"~*image/avif" ".avif";
"~*image/webp" ".webp";
}
location /images/hero {
try_files $uri$image_ext =404;
}
クライアントが image/avif を送信した場合、Nginx は hero.avif を提供します。そうでなければ WebP または JPEG にフォールバックします。
3. CDN に重い処理を任せる
ほとんどのエッジプロバイダー（Cloudflare Images、Fastly Image Optimizer、Akamai Image Manager）には、Accept ヘッダーに基づいてアップロードされた JPEG/PNG を自動的に AVIF/WebP に変換するトグルがあります。有効にしてキャッシュをパージすれば完了です。
ツールとワークフロー – ビルドパイプラインに AVIF/WebP を組み込む
| タスク | AVIF コマンド | WebP コマンド |
|---|---|---|
| ロスレスエンコード | avifenc -l -q 0 input.png output.avif | cwebp -lossless input.png -o output.webp |
| ロスィーエンコード（品質 50） | avifenc -q 50 input.jpg output.avif | cwebp -q 50 input.jpg -o output.webp |
| バッチ変換（Node） | sharp('src/**/*.png').avif({quality:50}).toFile('dist/') | sharp('src/**/*.png').webp({quality:50}).toFile('dist/') |
| アニメーション変換 | avifenc --animation frames/*.png output.avif (still experimental) | gif2webp animation.gif -o animation.webp |
ほとんどの CI パイプライン向けワンライナー
# Convert every PNG in assets/ to AVIF at 45 % quality
find assets -name '*.png' -exec avifenc -q 45 {} {.}.avif \;
ヒント: リポジトリに元の高解像度ソースを保持し、ビルドステップで AVIF/WebP をオンザフライで生成します。こうすれば品質設定を変えて再実行でき、アセットを再アップロードする必要がありません。
実際のインパクト – 重要な数値
| シナリオ | JPEG（ベースライン） | WebP（ロスィー） | AVIF（ロスィー） | AVIF（ロスレス） |
|---|---|---|---|---|
| 1 MP 写真、品質 90 % | 120 KB | 78 KB (‑35 %) | 55 KB (‑55 %) | 68 KB (‑43 %) |
| 透明ロゴ（500 × 500） | 45 KB (PNG) | 28 KB (‑38 %) | 22 KB (‑51 %) | 24 KB (‑47 %) |
| 5 秒 アニメーションバナー（10 fps） | 1.2 MB (GIF) | 380 KB (‑68 %) | 340 KB (‑72 %) | – |
出典: 小売サイトで 4 週間の A/B テストを実施した WebPageTest + Lighthouse 監査（2024‑2025）。AVIF バリアントは LCP が 0.4 s 速く なり、モバイルコンバージョンが 12 % 向上しました。
引用できるケーススタディ
- Shopify マーチャント（2025） – 製品サムネイルに AVIF を使用し、ページ重量を 38 % 削減、3G で LCP を 0.3 s 短縮。
- The New York Times – 記事内画像を AVIF に切り替え、帯域幅を 45 % 節約し、モバイルエンゲージメントが 12 % 増加。
- Airbnb – 対応ブラウザでホストプロフィール画像を AVIF で配信し、低速ネットワークでファーストペイントが 0.4 s 速くなった。
次にすべきこと – クイックチェックリスト
- 現在の画像ペイロードを監査 – Lighthouse の “Serve images in next‑gen formats” を実行。
- AVIF（フォールバックとして WebP）を出力するビルドステップを追加
sharpまたはavifencを使用。 - HTML を
<picture>ブロックで更新 するか、サーバー側のAccept交渉を有効化。 - 長期キャッシュヘッダーを設定（
Cache‑Control: max-age=31536000, immutable）。 - 遅延読み込みを有効化（
loading="lazy"または IntersectionObserver）し、画面外の AVIF デコードを回避。 - ローカルに AVIF を保存したくない場合は CDN エッジ変換を有効化。
- Core Web Vitals を監視 – デプロイから 1 週間以内に LCP が 0.2‑0.5 s 低下するはずです。
将来の展望: IDC は 2028 年までにウェブ画像の > 80 % が AVIF 優先になると予測しています。これは HDR 対応と Chrome 130+ の “image format negotiation” ヘッダーの登場によるものです。早期導入は現在のパフォーマンス向上だけでなく、次世代のビジュアルウェブ体験に備えることになります。
タグ: #webperformance #imageoptimization #avif
スラッグ: next-gen-web-graphics-avif-webp