WebPは実際にウェブサイトの画像に対してJPGよりも小さいのか？

同じ538.6 KBの写真を同じスライダーでJPG、WebP、AVIFを比較したところ、JPGが勝ちました。なぜそうなるのか、そして公正な比較が示すものは何かを説明します。

August 9, 2026

すべてのガイドは、WebPは同じ品質でJPGより約30%小さいと述べています。Googleの独自研究がその数値の出所です。私たちは、538.6 KBの3840x2160の写真texture.jpgを使って、独自のコンプレッサーで比較を行い、同じスライダー位置でJPEGが勝ちました：286.1 KB対290.3 KBのWebPです。両方を上回るはずのフォーマットであるAVIFは312.7 KBでした。

何も壊れていませんでした。3つのフォーマットはそのスライダーを異なって読み取り、そのうちの1つは意図的にそうしています。どれがそうかを知れば、結果は期待通りにひっくり返り、すでに使用しているツールに持ち込む価値のある習慣が得られます。

同じスライダーでWebPがJPGよりも大きくなったのはなぜですか？

私たちのコンプレッサーには、多くのツールが共有する特異性があり、ほとんどのツールはそれについて言及していません。出力フォーマットがJPEGで、入力がすでにJPEGだった場合、ソースファイルから量子化テーブルを読み取り、そのファイルが保存された品質を推定し、その推定値に対してスライダーを掛け算します。スライダーが80のとき、スコアが60のソースは48でエンコードされます。WebPとAVIFはそのような扱いを受けないため、80は80のままで、エンコーダーは指示通りに動作します。最初のランは、WebPが文字通り80に対して効果的な48のJPEGでした。圧縮が厳しいファイルは小さくなります。

リスケールはその位置を得ます。すでに損失のあるJPEGを80で再エンコードすると、60で書き込まれた場合にバイトが追加され、詳細は戻ってこないため、スライダーをファイルに残っているものの分数として扱います。より深刻な問題はJPEG自体にあります：仕様は生の量子化テーブルを保存し、品質番号は保存しないため、Photoshopの75、MozJPEGの75、いくつかのPHPスクリプトの75は3つの異なるファイルです。2つのスライダーで数値を一致させて公正なテストと呼ぶことは機能しません。

適切に比較したときのサイズはどのようになりますか？

63のとき、WebPはその538.6 KBのソースから200.6 KBを書き出します。同じ設定のAVIFは186.9 KBに達し、63は私たちのスマートモードがAVIFのために選ぶ数値であり、フォーマットを持ち上げるために選んだ数値ではありません。出力サイズを最初に一致させ、次に両方のファイルをフルサイズで開いて、どちらを受け入れられるかを判断してください。それが価値のある比較です。

では、AVIFを使うべきですか？

バイトではAVIFが勝ちます。忍耐では負けます。3840x2160のフレームをAVIFにエンコードするのに、ブラウザで約10〜11秒かかりましたが、JPEGとWebPは瞬時に戻ってきました。これらすべてはあなたのマシン上で動作するWebAssemblyで行われるため、これはあなたのラップトップがAV1のイントラコーディングを行っていることであり、コストはピクセル数に比例します。知っておくべきもう一つの落とし穴があります：WASMエンコーダーが失敗した場合、ブラウザのキャンバスエンコーダーにフォールバックし、キャンバスはJPEG、PNG、WebPを書き込むことができますが、AVIFのパスはまったくありません。大規模なバッチの場合、GoogleはネイティブなavifencツールをWebAssemblyビルドよりも推奨しており、1タブでの10のAVIFエンコードのコストも測定されています。

JPGをWebPに変換すると何を失いますか？

3つの具体的なことです。最初にメタデータが失われます：圧縮または変換は画像を生のピクセルにデコードし、再エンコードするため、EXIF、GPS座標、ICCプロファイル、埋め込まれたサムネイルはすべて出力から消えます。オリエンテーションは生き残ります。ブラウザがデコード中に適用するためです。キャプチャ日付が必要な場合は、元のファイルを保持してください。そして、損失のあるJPGを損失のあるWebPとして再エンコードすると、最初の損失に重ねられた第2世代の損失となるため、持っている最良のソースから一度だけ行ってください。

クロマが第2の損失です。損失のあるWebPは4:2:0サブサンプリングに固定されており、フォーマット内に4:4:4オプションはどこにもありません。そのため、構文ハイライトされたコードのスクリーンショットや飽和した赤の上にあるロゴは、同じ重さのJPEGよりもWebPで悪化する可能性があります。写真は気にしません。レンダリングが第3の損失です：プログレッシブJPEGは、早い段階で粗いフルフレームを描画し、バイトが到着するにつれてシャープにしますが、WebPにはプログレッシブモードがありません。そのため、大きな画像は十分なデータが到着するまで何も表示しません。弱い接続の上にあるヒーロー画像では、ファイルが小さくてもページの感覚が変わります。

画像に透明性がある場合、WebPはまだ勝ちますか？

JPEGは透明性を持つことができません。JPEGモードにはアルファチャンネルがないため、ロゴや切り抜きの場合、本当の競争はPNG対WebPであり、それぞれのフォーマットのケースはこれらの同じファイルで測定されます。私たちのPNGの数値は、あなたが打ち勝つ必要のある基準を設定します：alpha.pngは900x606で942.4 KBから、ロスレスoxipngでレベル3で383.9 KBに、imagequantがパレットに減少させた後は98.3 KBになり、透明性を維持したままで90%オフです。WebPは、損失のあるファイル内でもアルファをロスレスで保存するため、切り抜きのエッジはどちらの方法でもクリーンに保たれます。最初に切り抜きを作成する場合、私たちの背景除去ツールは常にアルファ付きのPNGを書き込み、そのPNGはその後コンプレッサーに直接入れることができます。

実際にどれをサイトに載せるべきですか？

写真にはWebPを使用してください。すべての現在のブラウザがそれをデコードします、Safariも含まれ、スライダーの数値を比較するのをやめると、実際の節約が得られます。古いソフトウェアで開かなければならないファイルや、大きなヒーローがプログレッシブレンダリングから30 KBよりも多くの利益を得る場合はJPGを保持してください。MDNの画像フォーマットガイドは、全ライブラリを1つのフォーマットにコミットする前に確認するためのリファレンスです。

最初にピクセルを確認してください。3840pxの写真は960pxのコンテンツカラムが表示するよりも4倍広く、どのコーデックもリサイズが無料で引き渡すものを戻すことはできないため、リサイズツールは25/50/75のプリセットを持ち、1クリックで通常はフォーマットの議論を完全に打ち負かします。品質の階段もフォーマットよりも重要です。同じtexture.jpgは60で212.4 KB、30で131 KBに達し、スマートモードは286.1 KB、47%オフに落ち着き、何も尋ねませんでした。

このテストを自分の画像で実行するにはどうすればよいですか？

オープンしてコンプレッサーに写真をドロップし、手動に切り替えます。JPGを選択し、サイズをメモします。同じスライダーでWebPにフォーマットドロップダウンを切り替え、その数値をメモします。次に、2つのファイルが数KB以内に収まるまでWebPスライダーを下げ、フルサイズで横に並べて確認してください。それがあなたに何かを教えてくれる唯一の比較です。バッチは10ファイルと50 MBに制限されています。スライダーを完全にスキップしたい場合は、JPGからWebPはリスケーリングなしでフラットな品質80でエンコードし、WebPからJPGは透明性を白にマットにして逆方向に戻り、PDFの手順書はファイルを大きくする唯一の変換をカバーします。