AVIF と WebP：2026年に選ぶべき画像フォーマットはどちら

ネットショップやブログ、商品カタログを運営しているなら、ページの中でいちばん容量を占めているのはほぼ確実に画像です。画像こそが読み込みを遅くし、訪問者の通信量を食い、検索エンジンの速度スコアを下げる原因になります。良い知らせは、ここ数年で従来の JPG よりはるかに強く圧縮できるフォーマットが登場したことです。しかも見た目は変わりません。悪い知らせは、そのフォーマットが一度に複数出てきて、それぞれに長所と落とし穴があり、勢いだけで選ぶのが難しいことです。この記事では、AVIF と WebP は何が違うのか、そこに JPEG XL がどう絡むのか、どの場面でどのフォーマットを使うのか、そして例外なくすべての訪問者に対して速くするにはどう設定するのかを整理します。

見た目がまったく同じ商品写真を2枚思い浮かべてください。片方は 800 KB、もう片方は 180 KB。目には区別がつきませんが、サイトにとっては大きな差です。カタログのページには通常 20〜40 枚の画像があり、一枚一枚が重ければページは数メガバイトにふくらみます。それほど速くない回線のスマートフォンで見ている訪問者は、読み込みを待たずにタブを閉じてしまいます。統計的にも、3秒より長く読み込みにかかるページからは相当数の人が離脱し、その原因の多くはまさに重い画像です。

読み込み速度はとうに検索順位の要素になっています。検索エンジンはページの主要コンテンツがどれだけ速く描画されるかを測っており、その影響度で画像が第一位です。画像が軽いほどページが速く表示され、訪問者が留まって購入する可能性が高まります。これは両方向に働きます。速いサイトは検索からより多くの訪問者を得られ、速いページはすでに来た人をよりよく引き留めます。この方程式の中で画像はほぼ常に最も弱い部分です。テキストやスタイルは数キロバイトなのに、圧縮されていない写真一枚で数メガバイトになることがあるからです。

純粋に費用の面もあります。訪問者に届ける1メガバイトは、そのまま通信量です。1日に数千アクセスがある大きなサイトでは、画像の重さがそのままホスティング費用とサーバーの負荷に直結します。画像を半分にすれば、画質を一切落とさずに負荷とコストを半分にできます。

古き良き JPG はその役目を果たしましたが、圧縮効率では絶望的に遅れています。現代のフォーマットは同じ見た目の品質で、半分ほど軽いファイルを作れます。問題は、どの新しいフォーマットを選ぶか、そして古いブラウザの人のためにサイトを壊さずに済ませるにはどうするか、それだけです。余計な理論は抜きにして、実務で役立つことだけ順番に見ていきましょう。

この先の話が分かるよう、フォーマットの短い用語集

比較の前に、登場人物をざっと押さえておきます。全部で5つ、それぞれに役割があります。

• JPG（JPEG）。 1992年からのベテラン。非可逆圧縮で、透明も動画（アニメーション）も非対応。どこでも開けますが、効率では絶望的に古いです。
• PNG。 可逆圧縮で透明に対応。ロゴ、アイコン、線がくっきりしたグラフィックには欠かせませんが、写真を入れると非常に重くなります。
• WebP。 Google 製で 2010年に登場し、2010年代半ばに広く普及しました。非可逆と可逆の両方、加えて透明とアニメーションに対応。互換性の点で黄金の中庸です。
• AVIF。 動画コーデック AV1 をベースにした新しいフォーマットで、2019年登場。同じ品質でいちばん強く圧縮でき、透明、アニメーション、広色域、HDR にも対応。最大の弱点はエンコードの遅さです。
• JPEG XL（JXL）。 ほぼ何でもこなし、JPG と後方互換もある有望な新参ですが、ブラウザ対応がまだ弱いです。これは後ほど別に取り上げます。

WebP は現代のライバルたちより先に登場し、事実上の標準になりました。とにかくどこでも動いて手間のかからない一つのフォーマットが欲しいなら、これです。

WebP の強み

• ほぼ完全なブラウザ対応。 WebP は世界のブラウザの97パーセント以上が理解します。対応は Chrome では 2010〜2014年に、Firefox はバージョン65（2019年）から、Safari は macOS Big Sur のバージョン14（2020年）から、iPhone では iOS 14 から本格的に始まりました。つまり訪問者の圧倒的多数は、何の小細工もなしに画像を見られます。
• はっきりした容量削減。 同じ品質の JPG と比べて WebP はおよそ25〜35パーセント軽くなります。多くのサイトにとってこれはすでに大きな飛躍で、4 MB あったページが 2.5 MB 弱になります。
• 速いエンコード。 画像を WebP に変換するのは速く、AVIF より何倍も速いです。これはユーザーがアバターやレビュー写真をアップロードして、いま結果を待っているような、その場で変換するケースで決定的に重要です。
• 透明とアニメーションに対応。 WebP はアルファチャンネル（透明背景）もアニメーションも扱えるので、透明背景の PNG の代わりにも、重い GIF アニメの代わりにもなります。アニメーション WebP は同じ映像の GIF より何倍も軽いです。
• 可逆モード。 WebP には可逆モードもあり、PNG の直接のライバルです。ピクセルを完全に正確に保ちながら PNG より平均で20〜26パーセント軽いファイルになり、スクリーンショットやグラフィックに最適です。
• 成熟したエコシステム。 フォーマットは十分に長く存在しているので、人気のあるサイト管理システム、プラグイン、ツールはどれも問題なく扱えます。どこかのサービスが理解しない、という事態にはまず遭遇しません。

WebP が劣るところ

WebP への主な不満は、もっと強く圧縮できるフォーマットが存在することです。画像が非常に多い場合（カタログに数千点の商品）、節約できた1パーセントごとが、実際の通信量の節約と読み込みの高速化になります。画像が数十枚なら、WebP とより攻めた圧縮の差はほとんど分かりません。ですが大きなカタログや数百枚の写真ギャラリーがあると、そのパーセントが積み重なって数十から数百メガバイトになり、そこで WebP は負けます。

もう一つ。非可逆の WebP は、大きな写真の非常に滑らかなグラデーションを、最新のフォーマットより少し苦手にすることがあります。実務ではめったに目立たず、強く圧縮したときだけですが、芸術的な写真を扱うなら知っておく価値はあります。WebP には寸法の技術的制限もあり、最大 16383 × 16383 ピクセルです。ほとんどの場合は足りますが、巨大なパノラマは収まりません。

この節約がそもそもどこから来るのかを理解しておくと役立ちます。WebP は古い JPG より賢い方法で隣接ピクセルを予測し、画像の繰り返し部分をより効率よく詰め込みます。ざっくり言えば、次の一片がどうなるかをより上手に当て、全部ではなく差分だけを保存します。ユーザーにとっての意味は一つ、同じ見た目の鮮明さがより軽い容量で得られる、しかも自分側での設定は不要、ということです。

WebP が実務で特に効く場面

WebP への移行が最も速く、はっきり効果を出す典型シナリオがいくつかあります。しかも何かを壊すリスクはほぼありません。

• ブログや情報記事。 ここでは画像は主に説明用でそれほど多くなく、圧縮の最後の1パーセントより最大限の互換性が大切です。WebP で用は完全に足ります。
• カタログのサムネイルやプレビュー。 リスト表示の小さな画像で、大事なのは全員に同じように即座に表示されることです。WebP は速くエンコードでき、速く読み込まれます。
• 既製プラットフォーム上のサイト。 標準的なサイト管理システムなら、画像の WebP 化はたいてい一つの既製の仕組みで済み、対応する人には WebP を、それ以外には通常の JPG を自動で配ります。手作業ゼロで速度の恩恵を得る、いちばん簡単な道です。
• 重い GIF の置き換え。 GIF のアニメーションバナーや短いループ動画は途方もなく重いです。同じ映像をアニメーション WebP にすれば数倍軽くなり、見た目は同じかそれ以上です。

多くのサイト運営者にとっては、WebP へ移行するだけで、当面の数年は画像最適化のテーマを片づけられます。これは AVIF が不要という意味ではなく、WebP が20パーセントの労力で80パーセントの成果を出すので、そこから始めるのが理にかなっている、ということです。

WebP についての結論はシンプルです。安全な既定値です。細かい調整やフォールバックの設定に踏み込みたくないなら、すべて WebP にするだけで現代フォーマットの恩恵の大半を得られます。ここで間違えることはまず不可能で、非常に多くのサイトでは WebP だけで読み込みを劇的に速くするのに十分です。

AVIF は、現代の動画エンコードの技術の上に作られた新しめのフォーマットです。最新のストリーミングが動いているコーデック AV1 のフレーム内圧縮を使っています。その最大の切り札は攻めた圧縮で、ここでは AVIF がリーダーです。

AVIF が優れている点

• 最も強い圧縮。 同じ見た目の品質で、AVIF のファイルは WebP より20〜30パーセント、JPG よりおよそ50パーセント軽くなります。つまり AVIF は普段の JPG 画像の半分ほどの重さになり得て、目は違いに気づきません。
• 難しい画像に強い。 滑らかなグラデーションのある写真（空、肌、ぼけた背景）では、AVIF は JPG が強い圧縮で作りがちな、あの見苦しいアーティファクトやブロックをほとんど残しません。四角いブロックの代わりに柔らかいぼけになり、目にはずっと受け入れやすいです。
• 透明とアニメーション。 AVIF は WebP と同じくアルファチャンネル（透明背景）とアニメーションに対応するので、PNG も GIF も置き換えられます。
• 広色域と HDR。 これは WebP にはまったくないものです。AVIF は10ビットと12ビットの色深度、広い色空間、HDR を扱えます。靴のカタログには関係ありませんが、写真ギャラリーやフォトグラファーのポートフォリオ、旅行のサイトでは、鮮やかで生き生きした写真が最新の画面で目に見えて豊かに映ります。
• 低ビットレートでも粘る。 非常に強く圧縮したとき、AVIF はいちばんきれいに崩れます。容量を限界まで削っても画像は許容範囲に留まり、同じ状況の JPG がモザイクになるのとは対照的です。

AVIF の落とし穴

• 遅いエンコード。 これが最大の弱点です。画像を AVIF に変換するのは WebP より5〜10倍遅く、最高品質設定ではさらに遅くなります。なぜこれがユーザー生成コンテンツ（UGC）で特に重要かというと、人がまさにいまレビュー写真やアバターをアップロードして待っているとき、エンコードの余分な数秒が体験全体を台無しにするからです。サイトの静的な画像なら問題ではなく、一度変換して忘れればよいのですが、リアルタイム処理では遅延がはっきり体感されます。
• 対応は少し低いが、すでに優秀。 2026年時点で AVIF はブラウザの95パーセント強が理解します。Chrome はバージョン85（2020年）から、Firefox はバージョン93（2021年）から、Safari は iOS 16 と macOS Ventura のバージョン16（2022年）から対応。非常に良い数字ですが、それでも WebP より数パーセント低いです。つまり、開けない人のための予備が必要です。
• 古いソフトは開けない。 多くのデスクトップソフト、メールクライアント、メッセンジャー、写真エディタは今も AVIF を開けません。訪問者がその画像をパソコンに保存すると、いつもの画像ビューアで開けないことがあります。だから AVIF はサイト上での表示には向くものの、ダウンロードや送信用のファイルとしては今のところ微妙です。
• 表示時のリソース要求がやや高い。 AVIF の展開は WebP より少し端末の CPU に負荷をかけます。今どきのスマホやパソコンでは気づきませんが、非常に古く非力な端末では理論上、描画がわずかに遅くなり得ます。容量の恩恵に比べれば些細ですが、正直に触れておきます。

分かりやすくするため、1200 × 1200 ピクセルの写真1枚を載せた典型的な商品カードを考えます。ほどよい品質の JPG ではおよそ 350 KB です。同じカットを WebP にするとおよそ 230 KB。AVIF ではおよそ 140 KB。つまり AVIF はここで JPG より2.5倍、WebP より1.5倍軽いのです。これを数百の商品に掛ければ、節約の規模は一目瞭然です。

画像を AVIF と WebP に変換する方法

方法はいくつかあり、画像の枚数とどこまで自動化したいかで選び方が変わります。

1. 単発作業用のオンライン変換。 数枚を変換したいときの最も簡単な道です。画像をアップロードし、AVIF か WebP を受け取り、ダウンロードしてサイトに置きます。ファーストビューの画像、バナー、主要な写真の十数枚には理想的です。ブラウザ内で完結し、何もインストールせずに済むものもあります。
2. フォルダの一括処理。 画像が数百枚なら、まとめて処理する意味があります。多くの変換ツールはフォルダごと受け取り、同じ名前で新フォーマットのファイル一式を出力できます。
3. サイト側での自動化。 大きなカタログでは、新しい画像をアップロードするたびにサイト自身が AVIF と WebP を作り、ブラウザに応じて適切な方を配るよう設定するのが賢明です。そうすれば手動変換のことは完全に忘れられます。

変換時に気をつけること。品質は中〜高あたりに設定し、余計なキロバイトのために圧縮を最大まで振り切らないでください（それは眠たい画像になります）。そして元の JPG か PNG は必ずフォールバックとして残します。ピクセル寸法も重要で、ページ上で 800 ピクセルで表示されるのに 4000 ピクセル幅の写真を持つ意味はありません。まず必要な寸法に縮小してから変換すれば、恩恵は最大になります。

手短に言えば、AVIF は容量の最小化が何より大事で、単発の変換に時間をかけてもよい場合のために作られています。一度アップロードして数千人に見せる静的な画像に理想的なフォーマットです。一度だけ数秒を変換にかけ、その速度の恩恵はページ表示のたびに、何百万回も得られます。

仕様に迷わないよう、実践的な法則を覚えておきましょう。これでほぼすべての現実の状況をカバーできます。

カンニングペーパー：コンテンツ別のフォーマット

数秒で決めたいなら、画像の種類で判断します。

• カタログの商品写真： AVIF、フォールバックに WebP。枚数が多く、頻繁に読み込まれ、節約が最大になります。
• 大きなバナーやカバー： AVIF。最も重い要素で、攻めた圧縮の恩恵が最も大きいです。
• アイコン、ロゴ、単純なグラフィック： 可能なら SVG、無理なら PNG か可逆 WebP。
• 記事内のイラスト： WebP、量が多ければ AVIF。ここでは極端な圧縮より互換性が大切です。
• ユーザーがアップロードする写真（UGC）： WebP。即時処理が重要だからです。
• メール内の画像： JPG か PNG のみ。新しいフォーマットをメールは理解しません。
• SNS 用プレビュー（og:image）： JPG か PNG。そうしないとプレビューが生成されないことがあります。
• アニメーション： GIF の代わりにアニメーション WebP か AVIF。数倍の節約になります。

AVIF を選ぶのはこんなとき

• 画像が静的でめったに変わらない：カタログの商品写真、記事内のイラスト、バナー、ヘッダーやフッターの画像。
• 画像が多く、節約した1キロバイトごとが数千回の表示に掛け算される。
• 画像をあらかじめ用意する（サイトへのアップロード時に一度変換する）のであって、その場で変換しない。
• 広色域や HDR の鮮やかで生き生きした写真が必要、たとえばポートフォリオや写真ギャラリー。
• 主目的が、速度を最大に、通信量を最小に絞り出すこと。

WebP を選ぶのはこんなとき

• コンテンツをユーザーが作る：アバター、レビュー写真、まさにいまアップロードされ即座に処理されるべき画像。
• シンプルさと予測可能性が大切で、フォールバックの手間をかけたくない。
• 最小限の労力で最大限に広い互換性が欲しい。
• 圧縮率の差が決定的になるほど画像が多くはない。

PNG を選ぶのはこんなとき

• ロゴ、アイコン、スクリーンショット、線がくっきりしたグラフィックや単色のプレート。
• 縁に少しのアーティファクトもない、完全にきれいな透明が必要。
• あとで編集する画像で、ピクセルをそのまま正確に保つことが重要。

JPG を残すのはどんなとき

JPG は圧縮では古いですが、最も古いソフトや端末を含め、絶対にどこでも開けます。JPG を持っておく意味があるのは、例外的な場合のための最後の予備としてか、新しいものを何も理解しないシステムに画像を渡すとき（たとえば古典的なフォーマットしか受け付けない一部のマーケットプレイスへ商品写真を出すとき）だけです。サイト本体のメインフォーマットとして 2026年に JPG を選ぶことは、もうありません。

では JPEG XL はどうか

JPEG XL（JXL）は多くの人が期待を寄せる新しいフォーマットで、それも理にかなっています。技術的には見事で、写真では AVIF と同等かやや上の圧縮率、AVIF より速いエンコード、透明、アニメーション、広色域、HDR、プログレッシブ読み込み（上から順ではなく画像が徐々に現れる）に対応し、特に価値が高いのは、既存の JPG を可逆で約20パーセント圧縮し直し、元に戻せる可能性も保てる点です。理想のフォーマットに聞こえます。

問題は一つ、しかし決定的です。ブラウザ対応です。2026年時点で JPEG XL を標準で理解するのは Safari（バージョン17から）で、Chrome は対応を外し、Firefox はフラグ付きでのみ有効にします。つまり、信頼できるフォールバックなしに大多数の訪問者へ JXL を配ることはまだできず、実務では割に合わないことが多いのです。結論として、JPEG XL は非常に有望なフォーマットとしてレーダーに載せつつ、2026年の実運用サイトでは AVIF プラス WebP の組み合わせのほうが確実です。Chrome が対応を戻せば状況は変わり得るので、そのときは戦略を見直す価値があります。

判断に迷う状況

ときには課題が法則にきれいに収まりません。よくある分かれ道と、その裁き方です。

• カタログは大きいが、写真は販売者自身がアップロードする。 ここではハイブリッドが賢明です。アップロード時はどんなフォーマットも受け付け、その場で即座に表示するための速い WebP を作り、夜間にバックグラウンド処理で溜まったものを AVIF に変換します。こうすればユーザーは待たされず、訪問者は最終的に最も軽い版を受け取ります。
• ロゴ、アイコン、線がくっきりした単純なグラフィック。 色数の少ないこうした画像には、今もベクター（SVG）か PNG がよく合い、ラスターなら可逆モードの WebP。単純なグラフィックでの AVIF の恩恵は、写真より小さいです。
• メール配信用の画像。 メールソフトは新しいフォーマットへの対応が弱く、AVIF も WebP もメールでは当てにできません。古典的な JPG か PNG を残してください。ここは容量より互換性が大切な場面です。
• SNS やリンクプレビュー用の画像。 シェア時にプレビューを作る SNS のロボットは、JPG と PNG しか理解しないことが多いです。og:image 用の画像は古典的なフォーマットにしておかないと、プレビューが出ないことがあります。

移行をためらわせる誤解

新しいフォーマットの周りには、簡単で得な一歩を妨げる思い込みがいくつも溜まっています。よくあるものを解きほぐします。

• 誤解：新しいフォーマットは画質が悪い。 逆です。同じ容量なら AVIF と WebP は JPG より見栄えがよく、同じ品質なら軽くなります。画像が悪く見えるのは圧縮を限界まで振り切ったときだけで、それはフォーマットではなく設定の問題です。
• 誤解：導入が難しい。 最小限のレベルなら、オンライン変換ツール一つとファイルの差し替えだけです。picture を使った完全な仕組みは少し複雑ですが、上に示したひな形どおりに作り、あとは複製するだけです。
• 誤解：訪問者の半分は画像が見えない。 これはフォールバックなしで新フォーマットを配った場合だけ正しいです。picture の連鎖があれば、100パーセントの訪問者が確実に画像を見られます。ある人は軽い AVIF を、ある人は予備の JPG を受け取るだけです。
• 誤解：検索エンジンは新しいフォーマットを嫌う。 まったく逆で、速度チェックツール自体が現代フォーマットへの移行を勧めますし、速いサイトは順位が上がります。
• 誤解：AVIF があれば WebP はもういらない。 必要です。まさに AVIF のフォールバックとして、そしてユーザーアップロード用の速いフォーマットとして。両者は組みで働きます。

最もエレガントな解は、一つのフォーマットを選ぶことではなく、各ブラウザに、そのブラウザが使える中で最良の一つを配ることです。ブラウザは自分が理解できる最初のフォーマットを選び、残りを飛ばします。これは picture タグで行います。

picture タグの仕組み

picture の中では、最も効率の高いものから最も互換性の高いものへと順に候補を並べます。ブラウザは上から下へ読み、最初に適合したものを取ります。

• 最初に AVIF、最も軽い候補。ブラウザが理解すればこれを読み込みます。
• 次に WebP、AVIF が非対応の場合の備え。
• いちばん最後に、JPG か PNG を指定した通常の img タグ。これはとても古いブラウザ向けの保険です。

構造はこうなります。

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

重要な点。alt、width、height、loading などの属性は、source ではなく picture 内の img タグに付けます。source タグはファイルの選択だけを担い、それ以外はすべて最終的な img から取られます。

カタログページで実際に起きること

恩恵を抽象論のままにしないよう、生きた例で計算しましょう。カタログのページが 1200 ピクセルの商品写真を30枚と、ファーストビューのバナーを表示するとします。

• 以前、すべて JPG： 350 KB の写真30枚とバナー 500 KB で、画像だけで約 11 MB。モバイル回線ではこのページは苦しいほど遅く開き、かなりの訪問者が待ちきれず離脱します。
• 移行後、すべて AVIF（WebP フォールバック付き）： 140 KB の写真30枚とバナー 200 KB で、約 4.4 MB。容量は半分以下に落ち、しかも目で分かる画質の劣化は一切ありません。

1ページで6メガバイト超の節約は、訪問者にとって速い読み込みであるだけでなく、サーバー側の通信量の削減であり、速度チェックツールでのより良いスコアでもあります。1日に数千の表示があれば、月あたりの通信量の節約は数十から数百ギガバイト単位になります。

導入の手順

1. 画像の各版を用意する。 各画像について AVIF と WebP の2つを作ります。元の JPG か PNG は最後のフォールバックとして残します。
2. img タグに width と height を書く。 これは画像用の場所を確保し、読み込み時のページのガタつきを防ぎます。ついでにレイアウト安定性の指標（CLS）も改善します。
3. ファーストビューより下の画像には loading lazy を付ける。 訪問者がそこまでスクロールしたときにだけ読み込まれ、ファーストビューがさらに速く開きます。
4. ファーストビューの主要画像には lazy を付けない。 逆に fetchpriority high を付けて、ブラウザが真っ先に読み込み、できるだけ早く表示されるようにします。
5. 複数のブラウザで確認する。 どこでも画像が表示され、かつ最新のブラウザが実際に軽い AVIF を引いていることを確かめます。開発者ツールの Network タブで、どのファイルが読み込まれたかを見れば簡単に確認できます。

PageSpeed、Core Web Vitals、SEO への影響

画像を現代フォーマットに移すことは、検索が考慮する最も重い速度指標を直接叩きます。

• LCP（最大要素の描画）。 画面上の最大の要素は、多くの場合まさにファーストビューの画像です。それが JPG の 350 KB ではなく AVIF の 140 KB なら、目に見えて速く読み込まれ、LCP が改善します。これは Core Web Vitals で最も重要な指標で、画像がそこに最も強く影響します。
• CLS（レイアウトのずれ）。 フォーマットの変更自体は CLS に影響しませんが、picture を導入するときに必ず width と height を書くので、読み込み時のページの飛びがなくなります。一つの行動で二重の効果です。
• ページ全体の重さと PageSpeed スコア。 速度チェックツールは重い画像を直接指摘し、現代フォーマットへの移行を提案します。これをやれば、推奨項目でよく出る一つを片づけられ、総合点が上がります。
• 行動指標と SEO。 速いページは訪問者を失いにくく、直帰率が低く、閲覧の深さが増します。検索はそれを見て、そういうサイトを引き上げます。つまり軽い画像の恩恵は技術的なだけでなく、順位と売上に変換されます。

導入時によくある失敗

• フォールバックを忘れる。 予備なしで AVIF だけを配ると、少数の訪問者は画像が読み込めません。連鎖の最後には必ず WebP か JPG を残してください。
• type 属性を違う source に付ける。 ブラウザは source の type の値を頼りにします。type を取り違えると、間違ったフォーマットを選んだり、適合するものを飛ばしたりします。image/avif が AVIF ファイルに、image/webp が WebP に付いているか確認しましょう。
• AVIF 版を圧縮しすぎる。 画質を失うまで容量の最小化を追う必要はありません。AVIF には品質設定があり、攻めすぎた値は眠たさとディテール喪失を生みます。バランスを取り、通常は中〜高の品質でまだ十分に軽く、素晴らしい画像になります。
• レイアウト上の寸法を更新しない。 ある版と別の版で縦横比が違うと、ページが飛びます。同じ画像のすべての版は同じ幅と高さを持つべきです。
• AVIF をダウンロード用に置く。 古いソフトは開けないことを思い出してください。画像をダウンロードするボタンがあるなら、そこでは通常の JPG か PNG を配り、AVIF はページ上の表示だけに使います。

各画像を二重変換する手間をかけたくないなら、小さく始めましょう。最も重い画像（商品写真、大きなバナー、ファーストビューの画像）を WebP フォールバック付きの AVIF にし、残りは WebP のままにします。部分的な導入でも体感できる速度向上があり、性能スコアの差はすぐに見えます。流れに慣れたら、徐々にサイト全体へ広げていけばよいのです。

よくある質問

AVIF は常に WebP より軽い？

写真ではほぼ常に、通常は20〜30パーセント軽いです。ただし色数が数色しかない非常に単純なグラフィックや小さなアイコンでは差がほとんど消えることがあり、ときには可逆 WebP のほうが勝ることさえあります。法則はこうです。写真なら AVIF、単純なグラフィックなら両方を試して軽く出たほうを取る。

AVIF や WebP に移ると画質を失う？

いいえ、圧縮を限界まで上げなければ。まともな品質設定なら、現代フォーマットは元と見分けのつかない画像を、数倍軽く出してくれます。画質が落ちるのは最小容量のために圧縮を最大まで振り切ったときだけで、それはやるべきではありません。

変換後、古い JPG は削除すべき？

いいえ、逆です。picture の連鎖の最後のフォールバックとして残してください。ディスク上でほとんど容量を取りませんし、とても古いブラウザや、古典しか理解しない外部システムに備えて保険になります。

AVIF は透明背景に対応している？

はい、AVIF は PNG や WebP と同じく完全なアルファチャンネルを持ちます。透明付きの重い PNG を置き換え、同じきれいな透明のまま数倍軽いファイルにできます。

ユーザーがアップロードする写真には何を選ぶ？

WebP です。AVIF はエンコードが5〜10倍遅く、ユーザーが待たされます。速い WebP は結果を即座に見せます。どうしても最大の圧縮が欲しければ、溜まった写真を後から夜間のバックグラウンド処理で AVIF に変換すればよいです。

いますぐ JPEG XL に移るべき？

まだです。技術的には優れたフォーマットですが、Chrome が対応しておらず、それは訪問者の割合として大きすぎます。2026年の実運用サイトでは AVIF プラス WebP の組み合わせのほうが確実です。JPEG XL には、ブラウザ対応が育ってから戻る価値があります。

画像フォーマットは検索順位に影響する？

間接的ですが、はっきりと。フォーマット自体は順位の要素ではありませんが、読み込み速度と Core Web Vitals を改善し、そちらはすでに考慮されています。加えて速いサイトは訪問者をよりよく引き留め、行動シグナルもあなたに有利に働きます。

ここまでを、1分で判断できる素早い覚え書きにまとめます。

• 一つのフォーマットで手間なく済ませたい？ WebP を。対応97パーセント超、速いエンコード、間違えようがありません。
• 速度を最大まで絞り出したい？ 静的な画像には AVIF を。WebP より20〜30パーセント、JPG よりおよそ2倍軽いです。
• 写真をユーザーがリアルタイムでアップロードする？ WebP を。AVIF はエンコードが5〜10倍遅いからです。
• ロゴ、アイコン、スクリーンショット？ PNG か SVG、または可逆 WebP。
• メール、SNS、リンクプレビュー？ 古典的な JPG か PNG。新しいフォーマットはそこでは対応されません。
• 完璧にやりたい？ picture タグで AVIF、次に WebP、最後に保険の JPG という連鎖。
• JPEG XL？ 有望ですが時期尚早。Chrome がまだ対応していません。

もう一つ役立つ習慣。新しいフォーマットを導入したら、結果を測ってください。変更前と後で速度チェックツールを開き、ページの重さと性能スコアを比べ、ついでに LCP 指標も見ます。そうすれば恩恵の具体的な数字が見え、残りの画像も移す価値があるか判断できます。計測なしの最適化は当てずっぽうに、計測ありなら分かりやすく制御できるプロセスになります。

肝心なのはこの点です。AVIF と WebP は殲滅戦の競争相手ではなく、相棒です。AVIF は最良の圧縮を、WebP は最良の互換性とエンコード速度を与え、古典の JPG と PNG は保険として、古いシステムへの橋として残ります。この組み合わせがあらゆる場面をカバーします。

この話でいちばん難しいのは、どのフォーマットが良いかを理解することではなく、実際に画像を変換することです。最も重い画像を数枚 AVIF に変換し、前後の容量を比べてみてください。おそらく数字が心地よく驚かせてくれますし、訪問者は速い読み込みに感謝するでしょう。トップページのいちばん重い画像から始め、数クリックで軽い AVIF にして、その場で前後の速度を測れば、あとは流れに乗って進みます。

プライバシーについての大切な点。処理はすべて あなたのブラウザの中、あなたの端末上 で行われる方式のツールもあります。写真や書類はどこにもアップロードされず、クラウドへ出て行かず、あなたのパソコンから離れません。商品写真や個人的な写真、機密性のあるものを扱うなら、これは特に価値があります。