2026 年のウェブサイトに最適な画像形式：JPG、WebP、AVIF、それとも PNG？

手短な答え：2026 年のウェブサイトに最適な画像形式

2026 年、多くのサイトに最適な画像形式は WebP です。写真、商品画像、サムネイル、ブログ画像、多くの透過グラフィックにとっての実務的な既定値で、モダンブラウザ全般で動きながら、JPEG や PNG より小さくなるのがふつうです。

とはいえ「すべてを WebP に変換する」が良い移行計画とは限りません。大きなビジュアル素材では AVIF がファイルサイズで WebP を上回ることがあります。JPEG は依然、古いブラウザ、メール、CMS への取り込み、外部のアップロードフォームで最も安全なフォールバックです。エッジの厳密さや透過が肝心なスクリーンショット、ダイアグラム、ビットマップ素材には PNG が正解のままです。ロゴやアイコンについては、アートワークがベクターならこれらすべてに勝るのが SVG です。

2026 年の本当の答えは次のとおりです。

この判断が今も重要な理由

画像形式は、訪問者がダウンロードするバイト数に影響します。とりわけファーストビューにある画像では、ページ速度、モバイル通信量、Largest Contentful Paint に効きます。Chrome の Lighthouse ドキュメントも、多くのウェブ画像において AVIF と WebP を、古い JPEG や PNG より圧縮と品質の面で優れたモダン形式として扱い続けています。

とはいえ形式は画像 SEO のごく一部です。完璧にエンコードされた AVIF でも、幅 4000 px の画像を 700 px のスロットに表示すればパフォーマンスを損ないます。alt テキストがなくコンテンツが薄いページでは、小さな WebP を貼っても順位は変わりません。まず形式を選び、そのうえでリサイズし、圧縮し、width と height を指定し、意味のある alt テキストを書き、レスポンシブなソースを配ることです。

役に立つ考え方はシンプルです。まず適切なピクセル、次に適切な形式。

WebP を日常の既定値にする

2026 年のウェブ画像仕事の多くにとって、WebP が最良の既定値です。写真向けのロッシー、グラフィック向けのロスレス、透過、アニメーションを扱えます。Google によれば、ロスレスの WebP は PNG より 26 % 小さく、ロッシーの WebP は同等品質で JPEG より 25〜34 % 小さくなります。

WebP を使う場面：

• ブログやヘルプセンターの写真。
• 商品一覧の画像とサムネイル。
• カテゴリーページの画像。
• チーム写真や執筆者のポートレート。
• AVIF ほどの節約が要らない背景画像。
• CMS と対象ブラウザが WebP を確実に扱えるときの透過グラフィック。

運用面でも WebP は良い選択です。多くの画像編集ソフト、ビルドツール、CMS プラグイン、CDN、ブラウザ変換ツールが生成できます。小さなチームが単一のモダン形式で回したい、画像ごとにフォールバックを管理したくない、というならもっとも手のかからない答えが WebP です。

節約がパイプラインの手間に見合うところで AVIF を使う

画像の重さが実際にビジネスの問題になっている場面、たとえば大きなヒーロー画像、トラフィックの多いランディングページ、全幅で写真を並べるポートフォリオ、モバイルですべて読み込まれる商品ギャラリーなどで試すべきなのが AVIF です。MDN は AVIF を、高性能でロイヤリティフリー、透過、アニメーション、高い色深度、HDR、広色域に対応する形式と説明しています。実務上の一番の日常的な利点は、多くの写真素材でファイルが小さくなることです。

引っかかりはワークフローにあります。AVIF はエンコードが遅くなりがちで、古いブラウザ、アプリ内 Webview、CMS ツール、アップロードポータルの一部が JPEG や WebP ほどスムーズに扱えません。だから AVIF はふつう、フォールバック列の先頭に置くソースであり、保持する唯一のファイルではありません。

AVIF を使うのは次のようなときです。

• バイト削減が効くだけの大きさがある画像。
• ビルド時か CDN を通じて生成されるアセット。
• 公開前に見た目を確認できる。
• WebP か JPEG のフォールバックを配れる。
• アクセス解析でモダンブラウザの利用が確認できる。

小さなサムネイルまで機械的に AVIF にする必要はありません。14 KB の WebP が 10 KB の AVIF になるとしても、生成に時間がかかり、パイプラインが複雑になるなら、割に合わないこともあります。

互換性、フォールバック、ウェブ以外の用途には JPEG を残す

JPEG は死んでいません。ウェブのパフォーマンス重視の配信で、いちばんの既定値ではなくなっただけです。

互換性が最大圧縮よりも大事なときは、JPEG のままにします。

• ニュースレターやメール添付。
• ファイル検査が厳しい古い CMS への取り込みやメディアライブラリ。
• JPEG しか受け付けないネイティブアプリやアップロードポータル。
• どうせすべて再圧縮する SNS ツール。
• レガシーブラウザ、アプリ内ブラウザ、キオスク端末、組み込み機器。
• <picture> 要素の中のフォールバック画像。

ページが画像重心でなく、パフォーマンスの余裕もあるときも JPEG で十分です。適切にリサイズされ、妥当な品質の JPEG は、寸法を間違えて配られた巨大な WebP よりずっと良いです。画像パフォーマンスの多くは、JPEG ではなく過大なピクセル寸法から生まれます。

ピクセルを厳密に残したいときは PNG

PNG はモダンな写真配信フォーマットではなく、精度のためのフォーマットです。ロスレスなエッジ、文字、透過が、ファイルサイズより重要なときに使います。

PNG に向く場面：

• 小さな文字を含む UI スクリーンショット。
• グラフ、ダイアグラム、線画。
• SVG が用意できないときのロゴ。
• デザインワークフローで使う透過ビットマップ素材。
• 繰り返し編集するファイル。

PNG に向かない場面：

• カメラ写真。
• ヒーロー背景。
• 透過のない大きな商品写真。
• WebP や AVIF でも良い装飾画像。

写真の PNG は、見た目が同じような JPEG／WebP／AVIF に比べて何倍にも重くなり得ます。写真的で、透過も厳密なピクセル保存も不要なら、PNG は書き出し先として不適切です。

ロゴとアイコンには SVG を忘れずに

「最適なフォーマット」の記事の多くは JPG／PNG／WebP／AVIF の比較で終わりますが、サイトのロゴやアイコンはむしろ SVG に向きます。SVG はベクターなのでどのサイズでもシャープなまま、ラスターのロゴよりずっと軽いことがよくあります。

SVG を使う場面：

• サイトのロゴ。
• 単純なアイコン。
• インターフェースのシンボル。
• もともとベクター的なフラットイラスト。

代わりに PNG や WebP を使うのは、素材が複雑なラスター画像、プラットフォームが SVG を除去する場合、SVG の出所が信頼できない場合です。SVG はコードに近いマークアップを含み得るので、信頼できるフローから来た SVG だけを使ってください。

ページ種別ごとのフォーマット選び

ページの種類が違えば、最適なフォーマットも違います。トップページのヒーローと、ヘルプ記事のスクリーンショットを同じに扱うべきではありません。

今週ひとつだけ変えられるなら、ファーストビューにある最大の画像と、閲覧数の多い画像重視のテンプレートから手を付けます。まず小さなアイコンをすべて変換するのは進んだ気になりますが、パフォーマンス指標はほとんど動きません。

正しいフォールバックのパターン

本番ページでは <picture> 要素に、対応する最初の形式をブラウザに選ばせます。web.dev は AVIF を最初、次に WebP、フォールバックに JPEG というパターンを推奨しています。ネストした img は引き続き alt、width、height、フォールバックの src を担います。

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-1200.avif 1200w, /images/hero-2400.avif 2400w"
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="/images/hero-1200.webp 1200w, /images/hero-2400.webp 2400w"
    sizes="100vw"
  />
  <img
    src="/images/hero-1200.jpg"
    width="1200"
    height="800"
    alt="ウォルナットのキャビネットに自然光が入るリフォーム済みキッチン"
  />
</picture>

フォールバックの JPEG は img 要素に置きます。alt テキストも img に。唯一の意味ある説明を source タグに隠してはいけません。ブラウザは source から alt を読みません。

LCP のヒーロー画像なら、読み込み優先度も考えます。メインのヒーローには lazy load をかけません。ファーストビュー下の画像には lazy load が効きます。

実際に役立つ品質設定

品質値は普遍的ではありません。WebP の品質 80、AVIF の 50、JPEG の 85 は同じ意味ではありません。エンコーダごとの挙動も違います。

以下は目安であって、ルールではありません。

書き出した画像は、必ずページ上に表示されるサイズで比べてください。600 px 幅で表示される画像を 4000 px までズームして判断すると、実際の訪問者には見えない無害な圧縮が悪く見えることがあります。暗いグラデーション、肌の色、商品のテクスチャ、文字を重ねた領域も試してください。単色の青空よりも早く圧縮の欠点が出ます。

現実的な移行プラン

既存のサイトを整理するとき、メディアライブラリを丸ごと変換しに行くのはやめます。効果が測れるところから始めます。

1. アクセスの多いページにある最大級の画像を一覧化する。
2. ファーストビュー内か、LCP 候補かをマークする。
3. 各画像を、実際に表示される最大サイズにリサイズする。
4. 写真をまず WebP に変換する。
5. 最も重いヒーローやギャラリーで AVIF を試す。
6. 古いブラウザ、メール、CMS の互換性が必要なテンプレートには JPEG フォールバックを残す。
7. スクリーンショット、ダイアグラム、厳密なグラフィックは PNG やロスレス WebP のままにする。
8. width、height、srcset、sizes、そして意味のある alt を付ける。
9. 変更の前後で Lighthouse かパフォーマンス監視ツールを走らせる。

「AVIF がベスト」と言い切るより地味ですが、実サイトではこの流れが効きます。

PhotoTools でフォーマットを変換する

PhotoTools はブラウザ内で JPG、PNG、WebP、AVIF、HEIC のファイルを変換できます。画像を放り込み、出力形式を選び、ロッシー出力なら品質を調整し、変換して結果をダウンロードします。商品画像やブログ写真のフォルダを移行するときは、バッチ変換が便利です。

大きなバッチに入る前の簡単なテスト：

• 明るい写真、暗い写真、顔がある写真、細かいディテールの写真を 1 枚ずつ選ぶ。
• WebP と AVIF の版を書き出す。
• 実際の表示サイズで見比べる。
• ファイルサイズの節約を確認する。
• CMS に 1 ファイルアップロードして受け付けられるか確認する。

iPhone の HEIC ファイルは、公開前に JPEG か WebP に変換します。HEIC は撮影／保管の形式としては有用ですが、公開ウェブでそのまま配るのに安全な形式ではありません。

2026 年推奨の出典メモ

本推奨は、最新のブラウザ／パフォーマンスドキュメントと、現実のウェブ公開ワークフローに基づきます。

• MDN の画像ファイルタイプガイド は AVIF、WebP、JPEG、PNG、SVG、ブラウザ対応、フォールバックが妥当な場面を解説。
• Chrome Lighthouse のドキュメント は、AVIF と WebP が古い JPEG／PNG より画像重量を減らせる理由を説明。
• Google の WebP ドキュメント は、ロスレスとロッシーの WebP が PNG／JPEG に対して得られるサイズ節約を掲載。
• web.dev の画像パフォーマンス は、モダン形式と <picture> 要素が画像読み込みと LCP にどう関わるかを整理。

短くまとめると、日常のウェブ形式は WebP、画像の重さが実際にパフォーマンスに効く場所は AVIF を足す、互換性のために JPEG を残し、必要な素材には PNG または SVG を残す、これが 2026 年の答えです。