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

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

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

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

実のところ編集部もそうでした。最初はWebPへの移行コストを過大に見積もっていましたが、実際に計測してみると、移行の判断は思ったよりシンプルで、効果は確実に出ることがわかりました。この記事ではその実測プロセスと判断基準を共有します。

§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のサポートを終了しており、現時点で対応を気にするケースはほぼありません。

§圧縮率の実測：同じ画像でどれだけ差が出るか

実際に3種類の画像(風景写真・UIスクリーンショット・イラスト)で変換テストを行いました。変換にはSquooshを使用しています。Squooshはブラウザ上で動作するGoogleのオープンソースツールで、エンコード設定を細かく変えながらリアルタイムで画質を比較できます。

いずれもvisual diffでは人間の目に判別できる劣化は確認できませんでした。Googleの公式発表では「WebPはJPEGより25〜34%小さい」とされており、この実測値は概ねその範囲に収まっています。

余談ですが、Squooshのスライダーを動かしながら「これ以上圧縮したら気になるな」という閾値を探す作業は、思ったより没入感があります。デザイナーの方と一緒にやるとなおさら議論が深まります。

§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」が出たら改善余地あり

Lighthouseが報告するLCP(Largest Contentful Paint)の改善幅は、ページ内の最大画像をWebPに置き換えた場合、0.3〜0.8秒程度の短縮が見込まれることが多い印象です(回線速度・CDN構成によって変動します)。

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のquality 80はJPEGのquality 80より実際の画質が高い(同じ数値でも計算方法が異なるため)という点は注意が必要です。WebPではquality 75〜82が、JPEGのquality 85相当の見た目に近い、と実測上は感じています。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パフォーマンス関連の記事一覧や画像最適化タグも合わせて確認すると、全体の改善ポイントが整理しやすくなります。