AVIFやWebPに替えれば、画像は必ず速くなる？

必ずしもそうではありません。転送量を減らせる場合はありますが、画像の種類、エンコード設定、表示サイズ、端末でのデコード、キャッシュヒットにも左右されます。同じ画像を同じ表示サイズで変換し、容量と見える劣化を比べてから、代替形式とキャッシュ経路を確認しましょう。web.devの画像パフォーマンス解説

形式名ではなく画像と品質を比べる

AVIFは、AV1画像データをHEIFベースのファイル形式に格納する仕様です。HDR、広色域、透過、複数のビット深度に対応しますが、拡張子だけではエンコーダー設定や特定ブラウザーでのデコード負荷は分かりません。AOMedia AVIF仕様 v1.2.0 WebPは非可逆・可逆圧縮と透過をサポートします。GoogleのWebP解説

写真は非可逆圧縮の比較に向いています。一方、文字や細い線のあるスクリーンショットや図では、同じ設定でもにじみや色の縁取りが目立つ場合があります。小さなサムネイルと大きなメイン画像を、実際の表示サイズで確認してください。全画像に一律の形式を適用するのではなく、目で見た品質と転送量で選びます。web.devの圧縮・形式の説明

例：商品画像を1枚だけ安全に切り替える

幅800ピクセルで表示する商品写真を想定します。同じ寸法でJPEG、AVIF、WebPを用意し、写真の質感だけでなく、価格文字や輪郭も確認します。ファイル容量、モバイルでの実転送量、メイン画像のLCP、対応端末でのデコードを測定します。AVIFが小さくても、初回変換の遅延や端末負荷が結果を損なうなら、WebPや既存JPEGの方が適することがあります。これは測定項目であり、常に勝つ形式があるという意味ではありません。

ブラウザー別の代替には、<picture>にAVIFとWebPの候補を置き、内側の<img>にJPEGなどを指定できます。alt、width、heightは<img>に設定します。表示幅が変わる場合はsrcsetとsizesも使い、モバイルに必要以上に大きな元画像を送らないようにします。web.devのpicture・レスポンシブ画像例

同じURLでAccept交渉をするときのキャッシュ

リクエストのAcceptに応じて同じパスからAVIF、WebP、JPEGを選ぶ場合、共有キャッシュが各応答を区別できる必要があります。一般的なHTTP構成ではVary: Acceptを正しく返し、キャッシュキーが形式ごとの応答を区別しているか確認します。web.devのAccept交渉の説明

CloudflareのVary for Images機能はAcceptを解析し、形式別にキャッシュします。現行文書ではPro、Business、Enterpriseプランが対象で、オリジンはVary: Acceptを返し、設定した形式を実際に提供する必要があります。設定形式をオリジンが返さない場合、キャッシュされずBYPASSになることがあります。これはCloudflare固有の条件で、すべてのCDNに当てはまるとは限りません。Cloudflare Vary for Images文書

公開前の確認順

  • 1. 写真、文字や細線を含む画像、必要なら透過画像を選び、同じ寸法・目的品質で形式を比べます。
  • 2. HTMLの代替経路とレスポンシブサイズを確認し、応答のContent-Typeが実際のファイル形式と合っているか試します。
  • 3. 異なるAcceptヘッダーを少なくとも2種類送って、返された形式、Vary、キャッシュ状態を確認します。初回と再リクエストを分けて測ります。
  • 4. 必要な変種だけに絞ります。サイズと形式の組み合わせを増やすほど、キャッシュ項目やオリジンへの再取得も増えます。

圧縮率だけでなく、適切な画素寸法、ネットワーク転送量、キャッシュ効率を測りましょう。ファイルが小さいだけでLCPや体感速度の改善が保証されるわけではありません。web.devの画像パフォーマンス解説

参考資料