WebページのJPEGとWebP：読み込み速度と画質の差を比較する

• JPEGとWebPの基本的な違い
• 圧縮率はどれくらい変わるのか
• Lighthouseで読み込み速度の影響を確認する
• pictureタグで互換性を担保する
  • 静的サイトジェネレーターやCMSでの自動変換
• フォーマット選択の判断フロー
• 実装のつまずきポイントと回避策
  • CMSのメディアライブラリが古いままになりがち
  • quality値の設定に迷う
  • AVIFはもう使えるのか
• FAQ

結論: 写真系はWebP、互換性が不安な場面はpictureタグでJPEGをfallback提供すれば両立できる。

Webページの表示速度は、直接的にユーザーの離脱率と検索順位に影響します。そしてページ重量の半分以上を占めることが多いのが画像ファイルです。「とりあえずJPEGで書き出す」という判断をずっと続けてきた方も多いでしょう。

WebPへの移行はコストが高そうに見えますが、判断そのものはシンプルです。この記事では、公式に示されている削減率、自分の画像で確かめる手順、そしてfallbackの実装までを順に整理します。

§JPEGとWebPの基本的な違い

JPEGは1992年にJoint Photographic Experts Groupが策定した規格で、長らくWebの写真フォーマットの標準として使われてきました。一方、WebPはGoogleが2010年に発表し、2020年代に入ってブラウザ対応が急速に広がったフォーマットです。

2026年6月時点でのブラウザ対応状況は、Can I use「WebP」によると、Chrome・Firefox・Safari・Edgeのすべてで有効です。唯一の例外はInternet Explorerですが、Microsoftは2022年6月にIEのサポートを終了しており、現時点で対応を気にするケースはほぼありません。

§圧縮率はどれくらい変わるのか

Googleの公式ドキュメントでは、WebPの可逆圧縮はPNGより26%小さく、非可逆圧縮は同等のSSIM品質でJPEGより25〜34%小さいとされています。まずはこの範囲を見積もりの基準にするのが確実です。

ただし削減率は画像の内容で変わります。手元の画像でどうなるかは、Squooshで確かめるのが最短です。Squooshはブラウザ上で動作するGoogleのオープンソースツールで、エンコード設定を細かく変えながらリアルタイムで画質を比較できます。

確かめる手順

1. 代表的な画像を3種類選ぶ(写真・UIスクリーンショット・フラットなイラスト)。傾向が大きく違うため、1枚だけで判断しない
2. 左右の比較ビューでJPEGとWebPを同じquality値(まずは80)に揃える
3. 画面下部に出るファイルサイズと削減率を記録する
4. スライダーを動かし、劣化が気になる手前のquality値を探す

写真は輪郭が緩やかなので削減率が出やすく、フラットなイラストや文字を含むUIスクリーンショットは元から軽いぶん差が小さく見えることがあります。自分のサイトで使う画像で測るのが唯一確実な方法です。

§Lighthouseで読み込み速度の影響を確認する

ファイルサイズの差は、実際のページ読み込みにどう反映されるのでしょうか。Chrome DevToolsに内蔵されているLighthouseで計測するのが最も手軽です。

計測の手順は次の通りです。

1. Chrome DevToolsを開く(F12 または Cmd+Option+I)
2. 「Lighthouse」タブを選択
3. 「Performance」にチェックを入れて「Analyze page load」を実行
4. レポートの「Opportunities」セクションに「Serve images in next-gen formats」が出たら改善余地あり

改善幅は回線速度・CDN構成・画像の元サイズで大きく変わるため、一般的な目安を当てにせず、置き換え前後で同じ条件のLighthouseスコアを比べてください。判断材料になるのは差分だけです。

LCPについてはWebフォントとシステムフォントのLCPへの影響でも詳しく扱っていますが、画像とフォントはLCPの主要因として並列に対策を進めると効果的です。

§pictureタグで互換性を担保する

「WebPに移行したいが、古い環境向けのfallbackも残したい」という場合は、<picture>タグを使います。

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="ページのメイン画像" width="1200" height="630">
</picture>

ブラウザはWebPに対応していれば<source>を、対応していなければ<img>のJPEGを読み込みます。記述量は増えますが、一度テンプレートに組み込めば運用上の手間はほぼありません。

§静的サイトジェネレーターやCMSでの自動変換

Next.jsのnext/imageコンポーネント、またはAstroの組み込み画像処理は、アップロードされたJPEGを自動でWebP(あるいはAVIF)に変換してHTMLを出力します。WordPress 6.5以降も同様の自動変換機能を搭載しています。手動でファイルを管理しているプロジェクトほど、ツールへの移行を検討する価値があります。

§フォーマット選択の判断フロー

どのフォーマットをいつ選ぶべきか、以下の基準を参考にしてください。

なお、操作手順を伝える場面では静止画にするか短い録画にするかで扱うファイルの種類自体が変わります。その判断軸と保存形式はスクリーンショットとスクリーンレコードの使い分けにまとめています。

§実装のつまずきポイントと回避策

§CMSのメディアライブラリが古いままになりがち

WebPへの切り替えを決めたあとも、過去にアップロードしたJPEGが残り続けることがあります。一括変換にはcwebpコマンドラインツールやImageMagickが使えます。

# ディレクトリ内のJPEGをまとめてWebPに変換(quality 82)
for f in *.jpg; do cwebp -q 82 "$f" -o "${f%.jpg}.webp"; done

§quality値の設定に迷う

WebPとJPEGのquality値は計算方法が異なるため、同じ数値でも結果は一致しません。数値を横並びで揃えても意味がないので、Squooshで目視確認しながら、劣化が気にならない下限を画像の種類ごとに決めるのが確実です。

§AVIFはもう使えるのか

2026年6月時点でAVIFは主要ブラウザで対応済みですが、エンコード時間がWebPの数倍かかる場合があり、ビルドパイプラインによっては導入ハードルが高めです。高画質・高圧縮を両立したい静的アセットには有効ですが、量産が必要な場面ではWebPが現実的な選択です。

§FAQ

Q. WebPに変換すると画質が落ちますか? A. 非可逆圧縮(lossy)の場合は若干の劣化が生じますが、quality値80以上では人間の目には判別しにくいレベルに抑えられます。可逆圧縮(lossless)オプションを選べば劣化なしに変換できます。

Q. すでに公開しているサイトはどこから手をつければいいですか? A. Lighthouseの「Opportunities」セクションに表示される最大サイズの画像から着手するのが最短です。LCPに直結する上位3〜5件の画像をWebP化するだけで、スコアに変化が出ることが多いです。

Q. <picture>タグを書くのが面倒です。省略する方法はありますか? A. Next.jsのnext/image・Astro・WordPress 6.5以降など、フレームワークやCMSが自動で変換・出力する仕組みを使うのが最も現実的です。手書きが避けられない場合はスニペットをエディタに登録しておくと負担が減ります。

Q. SVGやPNGはこの比較に入らないのですか? A. SVGはベクター形式であり、写真系の画像には不向きです。PNGは可逆圧縮ですが、写真ではWebPのlosslessより容量が大きくなる傾向があります。透過が必要なアイコン・UIパーツに限り、PNGまたはWebP(lossless)が適切です。

Webパフォーマンス関連の記事一覧も合わせて確認すると、全体の改善ポイントが整理しやすくなります。