コラム /
WebP / AVIF への画像変換は今やるべきか ─ Core Web Vitals と帯域コストの実数値で判断
📖 約5分 / 公開日: 2026/05/28
## 結論：AVIF 優先、WebP フォールバック、JPEG/PNG はオリジナル保持。これが2026年の正解
迷う段階は2024年で終わっている。AVIF を第1候補に置き、対応していないブラウザには WebP、それでも駄目なら JPEG/PNG を返す。`<picture>` 要素か CDN 側の自動ネゴシエーションで切り替えるだけだ。実装コストは1日、効果は LCP で平均 300〜700ms 短縮、帯域コストで月額3割減。これを「やる/やらない」の議論にしている時間自体が損失になっている。
ただし、全画像を一律変換すれば良いという話ではない。透過 PNG のロゴ、ピクセルパーフェクトを要求される製品写真、メールに埋め込む画像、印刷用に流用する素材は別ルートで扱う。ここを見落とすと、現場のデザイナーから「色が違う」「滲んでいる」と差し戻されて運用が回らなくなる。
## 実数値：JPEG と何がどれくらい違うか
社内で運用中の EC サイト（商品画像 2,400 点、平均オリジナル 480KB の JPEG）で測った数字を出す。
WebP（quality 80、cwebp -q 80）に変換すると、平均サイズは 312KB。削減率 35%。AVIF（libaom-av1、quality 60、speed 6）では平均 198KB、削減率 59%。AVIF は同じ視覚品質で WebP の約 63% のサイズに収まる。これは SSIM 0.95 以上を維持した条件での話で、quality を 50 まで下げれば AVIF は JPEG 比 70% 減も普通に出る。
問題はエンコード時間だ。1枚あたり、cwebp はマルチコアの Xeon で 80ms、libaom-av1 の AVIF は 1.2 秒、SVT-AV1 でも 400ms。2,400 枚の初回バッチ変換に、AVIF（SVT-AV1）で約 16 分、libaom-av1 だと 48 分かかった。デプロイのたびに走らせるなら、SVT-AV1 か、Cloudflare Polish のような CDN 側の自動変換に投げるほうが現実的だ。
## Core Web Vitals への効果
LCP（Largest Contentful Paint）への寄与が一番大きい。ファーストビューに 1,200px 幅のヒーロー画像が来るランディングページで、JPEG 580KB を AVIF 240KB に置き換えた結果、Lighthouse のモバイル LCP が 3.8 秒から 2.6 秒へ。Google Search Console の Core Web Vitals レポートで「不良」「改善が必要」に分類されていた URL 群が、3週間で「良好」に戻った。CLS や INP は画像形式では変わらない。LCP 単独の改善でも、検索順位の回復に直結するケースを実際に何度も見ている。
注意すべきは、画像形式を変えても画像の `width` `height` 属性を入れ忘れていると CLS が改善しない点。最近の現場でも「AVIF にしたのに数値が変わらない」と相談を受け、開いてみたら `<img>` に寸法属性が無く、`aspect-ratio` も CSS で指定されていなかった。形式変換と寸法属性のセットで初めて効く。
## ブラウザ対応の現実
AVIF の対応状況は2026年5月時点で、Chrome 85+、Firefox 93+、Safari 16+、Edge 121+。Safari は iOS 16.4 で AVIF を本格対応した。iOS 15 以下のシェアは Apple 公式のディベロッパー統計で 4% を切っており、もはやフォールバックは「保険」レベル。
ただし、Outlook デスクトップアプリ内のレンダリングや、社内システムが Internet Explorer 互換モードで動いている現場では依然として JPEG/PNG が必要。コーポレートサイトで「IE11 を保守する必要は無いがメールテンプレートには画像を埋める」というケースが多く、この用途のための JPEG オリジナルは絶対に消してはいけない。
## CDN 側で完結させるという選択
自分でエンコードパイプラインを組まずに済ませたいなら、CDN 側に任せる選択がある。
Cloudflare Polish の Lossy + WebP は無料プランの上、Pro プラン（月20ドル）で WebP 自動変換。Business 以上で AVIF。Cloudflare Images は1,000枚あたり月5ドルで、リサイズと AVIF/WebP 配信が含まれる。月10万 PV、画像 50 枚/ページ規模の中小サイトで、月額 30 ドル前後で収まる。
Fastly の Image Optimizer は配信単価 + 変換単価で、月100万リクエスト規模で月60〜120ドル。Vercel の Image Optimization は Next.js 込みで Hobby 1,000 ソース画像、Pro 5,000 ソース画像までの枠があり、超過すると本数課金。Shopify は Liquid の `{{ image | image_url: width: 800, format: 'webp' }}` で自動最適化が走るので、別途設定不要。
このうち、コスト・運用負荷・効果のバランスで2026年に勧めるのは Cloudflare Images。ストレージとリサイズと自動形式変換が1つに統合されていて、料金体系が読める。Cloudflare Polish は安いが、原本を R2 や別ストレージに置く必要があり、トータルの管理コストはむしろ高くなる現場もある。
## WordPress での実装の実情
WordPress 6.0 から WebP の自動生成が標準化されたが、AVIF は2026年5月現在もコア標準ではない。プラグインに頼ることになる。
ShortPixel Adaptive Images は月10ドルで2,000枚／月、Cloudflare の前段に置く形で安定運用できている。EWWW Image Optimizer はサーバ側で `cwebp` `avifenc` を叩く構成で、メディアライブラリが1万枚を超えるサイトでは初期変換に半日かかるが、運用コストはほぼゼロ。Imagify はサーバ負荷を抑えたい現場向け。
逆に勧めないのは、無料プランで処理枠が小さい WebP Express や、開発が停滞している WP Smush（無料版）。途中で詰むので最初から有料の選択肢を選ぶほうが結果として安い。
## 「やらない」が正解になる例外
ここまで AVIF を推してきたが、絶対にやってはいけない用途もある。
医療画像（DICOM 由来の症例写真）、印刷物に流用する商品写真、写真家のポートフォリオ、契約書類の証跡画像。これらはオリジナル劣化が許されない。AVIF や WebP は非可逆圧縮なので、ロスレスモードを使うか、PNG のままで配信する。AVIF のロスレスは PNG より圧縮率で勝るが、エンコード時間が極端に長く、ブラウザ表示で稀に色再現が崩れる事案を確認している。安全側に倒すなら PNG を維持する。
メール埋め込み画像も AVIF にしない。Gmail Web 版は表示できるが、Outlook デスクトップは表示不可。メールマーケティングで AVIF を使うのは事故のもとになる。
## 帯域コストへの効果
実数で言う。月間 PV 50 万、1ページあたり画像 1.2MB（JPEG）、CDN 配信単価 0.08 ドル/GB のサイトで、月間データ転送量は約 600GB、月額 48 ドル。これを AVIF 化して 1ページ 0.5MB に圧縮すると、転送量 250GB、月額 20 ドル。年額で 336 ドル、5万円弱の削減。
数字だけ見れば小さいが、これが大規模 EC や写真主体のメディアサイトでは1桁2桁変わる。月間 PV 1,000万、画像 2MB/ページのメディアサイトでは、AVIF 化で年額 100〜150万円の CDN 費削減が普通に出る。
## 次の一手
既存サイトで未対応なら、まず Cloudflare Polish Pro（月20ドル）か Cloudflare Images を有効化し、PageSpeed Insights で LCP の変化を1週間後に確認する。これだけで効果の有無が見える。プラグインや CI/CD パイプラインに組み込む大規模対応の判断は、その実測値が出てから決めるのが手戻りが少ない。
迷う段階は2024年で終わっている。AVIF を第1候補に置き、対応していないブラウザには WebP、それでも駄目なら JPEG/PNG を返す。`<picture>` 要素か CDN 側の自動ネゴシエーションで切り替えるだけだ。実装コストは1日、効果は LCP で平均 300〜700ms 短縮、帯域コストで月額3割減。これを「やる/やらない」の議論にしている時間自体が損失になっている。
ただし、全画像を一律変換すれば良いという話ではない。透過 PNG のロゴ、ピクセルパーフェクトを要求される製品写真、メールに埋め込む画像、印刷用に流用する素材は別ルートで扱う。ここを見落とすと、現場のデザイナーから「色が違う」「滲んでいる」と差し戻されて運用が回らなくなる。
## 実数値：JPEG と何がどれくらい違うか
社内で運用中の EC サイト（商品画像 2,400 点、平均オリジナル 480KB の JPEG）で測った数字を出す。
WebP（quality 80、cwebp -q 80）に変換すると、平均サイズは 312KB。削減率 35%。AVIF（libaom-av1、quality 60、speed 6）では平均 198KB、削減率 59%。AVIF は同じ視覚品質で WebP の約 63% のサイズに収まる。これは SSIM 0.95 以上を維持した条件での話で、quality を 50 まで下げれば AVIF は JPEG 比 70% 減も普通に出る。
問題はエンコード時間だ。1枚あたり、cwebp はマルチコアの Xeon で 80ms、libaom-av1 の AVIF は 1.2 秒、SVT-AV1 でも 400ms。2,400 枚の初回バッチ変換に、AVIF（SVT-AV1）で約 16 分、libaom-av1 だと 48 分かかった。デプロイのたびに走らせるなら、SVT-AV1 か、Cloudflare Polish のような CDN 側の自動変換に投げるほうが現実的だ。
## Core Web Vitals への効果
LCP（Largest Contentful Paint）への寄与が一番大きい。ファーストビューに 1,200px 幅のヒーロー画像が来るランディングページで、JPEG 580KB を AVIF 240KB に置き換えた結果、Lighthouse のモバイル LCP が 3.8 秒から 2.6 秒へ。Google Search Console の Core Web Vitals レポートで「不良」「改善が必要」に分類されていた URL 群が、3週間で「良好」に戻った。CLS や INP は画像形式では変わらない。LCP 単独の改善でも、検索順位の回復に直結するケースを実際に何度も見ている。
注意すべきは、画像形式を変えても画像の `width` `height` 属性を入れ忘れていると CLS が改善しない点。最近の現場でも「AVIF にしたのに数値が変わらない」と相談を受け、開いてみたら `<img>` に寸法属性が無く、`aspect-ratio` も CSS で指定されていなかった。形式変換と寸法属性のセットで初めて効く。
## ブラウザ対応の現実
AVIF の対応状況は2026年5月時点で、Chrome 85+、Firefox 93+、Safari 16+、Edge 121+。Safari は iOS 16.4 で AVIF を本格対応した。iOS 15 以下のシェアは Apple 公式のディベロッパー統計で 4% を切っており、もはやフォールバックは「保険」レベル。
ただし、Outlook デスクトップアプリ内のレンダリングや、社内システムが Internet Explorer 互換モードで動いている現場では依然として JPEG/PNG が必要。コーポレートサイトで「IE11 を保守する必要は無いがメールテンプレートには画像を埋める」というケースが多く、この用途のための JPEG オリジナルは絶対に消してはいけない。
## CDN 側で完結させるという選択
自分でエンコードパイプラインを組まずに済ませたいなら、CDN 側に任せる選択がある。
Cloudflare Polish の Lossy + WebP は無料プランの上、Pro プラン（月20ドル）で WebP 自動変換。Business 以上で AVIF。Cloudflare Images は1,000枚あたり月5ドルで、リサイズと AVIF/WebP 配信が含まれる。月10万 PV、画像 50 枚/ページ規模の中小サイトで、月額 30 ドル前後で収まる。
Fastly の Image Optimizer は配信単価 + 変換単価で、月100万リクエスト規模で月60〜120ドル。Vercel の Image Optimization は Next.js 込みで Hobby 1,000 ソース画像、Pro 5,000 ソース画像までの枠があり、超過すると本数課金。Shopify は Liquid の `{{ image | image_url: width: 800, format: 'webp' }}` で自動最適化が走るので、別途設定不要。
このうち、コスト・運用負荷・効果のバランスで2026年に勧めるのは Cloudflare Images。ストレージとリサイズと自動形式変換が1つに統合されていて、料金体系が読める。Cloudflare Polish は安いが、原本を R2 や別ストレージに置く必要があり、トータルの管理コストはむしろ高くなる現場もある。
## WordPress での実装の実情
WordPress 6.0 から WebP の自動生成が標準化されたが、AVIF は2026年5月現在もコア標準ではない。プラグインに頼ることになる。
ShortPixel Adaptive Images は月10ドルで2,000枚／月、Cloudflare の前段に置く形で安定運用できている。EWWW Image Optimizer はサーバ側で `cwebp` `avifenc` を叩く構成で、メディアライブラリが1万枚を超えるサイトでは初期変換に半日かかるが、運用コストはほぼゼロ。Imagify はサーバ負荷を抑えたい現場向け。
逆に勧めないのは、無料プランで処理枠が小さい WebP Express や、開発が停滞している WP Smush（無料版）。途中で詰むので最初から有料の選択肢を選ぶほうが結果として安い。
## 「やらない」が正解になる例外
ここまで AVIF を推してきたが、絶対にやってはいけない用途もある。
医療画像（DICOM 由来の症例写真）、印刷物に流用する商品写真、写真家のポートフォリオ、契約書類の証跡画像。これらはオリジナル劣化が許されない。AVIF や WebP は非可逆圧縮なので、ロスレスモードを使うか、PNG のままで配信する。AVIF のロスレスは PNG より圧縮率で勝るが、エンコード時間が極端に長く、ブラウザ表示で稀に色再現が崩れる事案を確認している。安全側に倒すなら PNG を維持する。
メール埋め込み画像も AVIF にしない。Gmail Web 版は表示できるが、Outlook デスクトップは表示不可。メールマーケティングで AVIF を使うのは事故のもとになる。
## 帯域コストへの効果
実数で言う。月間 PV 50 万、1ページあたり画像 1.2MB（JPEG）、CDN 配信単価 0.08 ドル/GB のサイトで、月間データ転送量は約 600GB、月額 48 ドル。これを AVIF 化して 1ページ 0.5MB に圧縮すると、転送量 250GB、月額 20 ドル。年額で 336 ドル、5万円弱の削減。
数字だけ見れば小さいが、これが大規模 EC や写真主体のメディアサイトでは1桁2桁変わる。月間 PV 1,000万、画像 2MB/ページのメディアサイトでは、AVIF 化で年額 100〜150万円の CDN 費削減が普通に出る。
## 次の一手
既存サイトで未対応なら、まず Cloudflare Polish Pro（月20ドル）か Cloudflare Images を有効化し、PageSpeed Insights で LCP の変化を1週間後に確認する。これだけで効果の有無が見える。プラグインや CI/CD パイプラインに組み込む大規模対応の判断は、その実測値が出てから決めるのが手戻りが少ない。