2021年のこと、バーミンガムのWooCommerceクライアントと仕事をしていました。ホームウェアのショップで、約4,000枚の商品写真がすべて巨大なJPEGで、Canon DSLRで撮影されて処理なしでアップロードされていました。最大コンテンフルペイントは7.2秒でした。ひどいものでした。Squoosh CLIを使ってすべてWebPに変換し、Lighthouseを再実行したら、わずか一日で午後のうちにLCPを2.8秒まで下げることができました。クライアントは泣きました。本当に。Squoosh CLI, re-ran Lighthouse, and got LCP down to 2.8 seconds in a single afternoon. The client cried. Genuinely.
しかし、ここが重要なポイントです。翌月に一緒に仕事をしていた別のクライアント、写真ジャーナリズムのポートフォリオサイトでは、その同じやり方はほとんど効果がありませんでした。色の忠実度と印刷品質のエクスポートが実際に重要でした。そこではWebPは間違った選択でした。代わりに激進的なLightroomエクスポート設定を使ったJPEGを使用しましたが、画像がすでに適切なサイズだったため、パフォーマンスギャップはほぼ無視できるレベルでした。
では、これについて適切に話しましょう。「WebPは常により良い」でもなく、「JPEGは理由があってクラシック」でもなく。本当の答えは、どちらの陣営も認めるより状況依存的です。
---
実際のところ何が異なるのか
JPEGは1992年から存在します。離散コサイン変換圧縮を使用しており、これは写真には優れていますが、高い圧縮率では機能し始め、あの見慣れたブロック状のアーティファクトが導入されます。ほとんどのウェブ開発者はこれを知っています。
WebPはGoogleが2010年にリリースし、VP8ビデオコーデックから借用した予測符号化モデルを使用しています。簡潔に言えば、ピクセル間の空間的関係をより巧妙にモデル化するため、より少ないバイト数でより多くの品質を圧縮できます。Googleの独自調査によると、WebP非可逆圧縮画像はPNGより26%小さく、可逆WebPは同等の品質でJPEGより25～34%小さいです。Google's own research, WebP lossless images are 26% smaller than PNGs, and lossy WebP is 25-34% smaller than comparable JPEGs at equivalent quality.
これらの数字は実際の運用でも成立します。ほとんどの場合。
実際にギャップが表れる場所
25～34%の削減は、滑らかなグラデーションを持つ自然な写真、白い背景の商品写真、ライフスタイル画像で実現される傾向があります。高周波数の詳細部分ではギャップが著しく縮まります。布地の質感、密集した植物、多くの反復があるアーキテクチャパターン。ImageMagickを使った並行比較を何度も試してきました。非常に細かい詳細が写っている特定のショットでは、サイズ差は10%未満に低下し、同じ品質設定ではWebPが劣ることさえあります。ImageMagick side-by-side comparisons plenty of times. On certain highly detailed shots, the size difference drops to under 10%, and sometimes WebP even loses at the same quality setting.
---
2026年のブラウザ対応：まだこれは議論の対象ですか？
正直なところ、2018年にJPEGにこだわる本当の理由はブラウザ対応でした。Internet Explorer。Safariの採用が遅い。そういったものすべて。
それは過去のものです。Can I Useはこの時点でのグローバルWebP対応を97%以上としています。Safariは2020年のバージョン14で完全対応を追加しました。IEは廃止され埋葬されました。2026年でWebP画像を受信できない意味のある視聴者セグメントはありません。Can I Use puts global WebP support at over 97% at this point. Safari added full support in version 14 back in 2020. IE is dead and buried. There's no meaningful audience segment that can't receive a WebP image in 2026.
私がまだ遭遇する唯一のエッジケースは、画像をメール添付ファイルとして配信したり、サーバー側で生成したPDFエクスポートに埋め込んだりする場合、古い一部のレンダリングパイプラインはWebPで詰まります。それだけです。ブラウザで配信されるすべてのものについて、対応の議論は終わっています。
---
Core Web Vitals: 画像フォーマットの選択が本当に数字を動かす場所
LCP（Largest Contentful Paint）は、画像フォーマットの影響を最も直接的に受けるCore Web Vitals指標です。最大の可視要素がロードされるまでの時間を測定します。その要素が画像である場合（マーケティングおよびeコマースサイトではほぼ常にそうです）、フォーマット、サイズ、配信方法のすべてが極めて重要になります。
画像フォーマットの選択が実際に違いを生み出した場所の実践的な内訳を示します：
- ヒーロー画像：これらはほぼ常にLCP要素です。1920pxの幅で1.2MB のJPEGのヒーロー画像をWebP品質82に変換すると、視覚的な品質低下なしに380～450KBに圧縮されるのが常です。 These are almost always the LCP element. If your hero is a 1.2MB JPEG at 1920px wide, converting to WebP at quality 82 will routinely get you to 380-450KB without visible quality loss.
- 商品画像グリッド：多くの小さな画像が同時にロードされます。WebPの一貫した25%以上の節約がここで複合します。グリッドが速くなる＝モバイルの総ブロッキングが低下します。 Lots of small images loading simultaneously. WebP's consistent 25%+ savings compound here. Faster grid = lower total blocking on mobile.
- ブログ投稿のインライン画像：本当に低インパクトです。3000語の記事の途中にある200KB のJPEGと140KB のWebPは、LCPを動かしていません。 Genuinely low impact. A 200KB JPEG versus a 140KB WebP in the middle of a 3,000-word article isn't moving your LCP.
- アイコンとロゴ：どちらでもありません。SVGを使用してください。毎回これを言う必要があります。 Neither. Use SVG. I have to say this every single time.
- アーカイブページのサムネイル：WebPがここで勝ちます。特にグリッドで20～30のサムネイルをロードしている場合は、バイト節約が急速に積み重なります。 WebP wins here, especially when you're loading 20-30 thumbnails in a grid. That's where byte savings stack up fast.
Seahawkは昨年fintech プロジェクトに取り組みました。マーケティングサイトはヒーロー カルーセルで14の above-the-fold 画像がローテーションしていました。狂気ですが、クライアントが主張しました。14すべてをJPEGからWebP品質80に変換し、Cloudflare CDN経由で配信すると、モバイルでのLCPが4.1秒から2.3秒に低下しました。カルーセルは依然として悪い考えでしたが、少なくとも速くロードされました。
AVIF の問題
AVIF の問題
WebP について書くたびに誰かが AVIF について聞いてくる。その通りだ。
AVIF は次のステップだ。AV1 ビデオコーデックに基づいており、WebP よりもさらに小さいファイルを生成し（写真では往々にして 20～30% さらに小さい）、HDR コンテンツを適切に処理する。Chrome、Firefox、Safari のブラウザサポートは現在堅牢だ。問題はエンコード速度だ。AVIF はエンコードが遅く、かなり遅い。VPS で 4,000 個の商品画像のバッチ変換を AVIF で実行すると、長時間がかかる。WebP は生成が大幅に高速だ。Browser support is now solid for Chrome, Firefox, and Safari. The problem is encoding speed. AVIF is slow to encode, meaningfully slow. Running a batch conversion of 4,000 product images through AVIF on a VPS will take you a long time. WebP is significantly faster to produce.
現在の考え方：WebP をデフォルトの配信形式として使用する。エンコードオーバーヘッドを正当化する追加の AVIF 圧縮ゲインがあるハイトラフィックサイトを構築している場合は、AVIF をサポートするブラウザに AVIF を提供し、WebP にフォールバックする。<picture> 要素と <source type="image/avif"> でこれを JavaScript なしで処理できる。<picture> element with <source type="image/avif"> handles this without any JavaScript.
AVIF の躊躇で JPEG に留まるな。WebP は今のところ正しい現実的なデフォルトだ。
9 年間で 12,000 以上のサイトを経験した後、これが大まかな考え方だ：
フォーマットを選ぶ実際のワークフロー
9 年間で 12,000 以上のサイトを経験した後、これが大まかな考え方だ：
- 写真またはフォトリアリスティック画像か？WebP ロッシーで品質 80～85 から始める。品質 75 の JPEG と比較する。スクイントテストに合格した小さい方を取る。 Start with WebP lossy at quality 80-85. Compare against JPEG at quality 75. Take the smaller one that passes the squint test.
- グラフィック、ロゴ、イラストで単色フラットカラーですか？可能ならSVG、できなければPNG。WebPロスレスも選択肢ですが、ほとんどの場合最善ではありません。 SVG if possible, PNG if not. WebP lossless is an option but rarely the best one.
- テキスト入りのスクリーンショットですか？PNG。常にPNG。JPEGとWebPはどちらもテキストエッジの周りに見苦しいアーティファクトを導入します。 PNG. Always PNG. JPEG and WebP both introduce artefacts around text edges that look terrible.
- フォーマットネゴシエーションを自動的に行うモダンCDN経由で配信されていますか？Cloudflareを使用してPolishを有効にしている場合、またはCloudinaryやImgixを使用している場合は、正直なところそこまで心配する必要はありません。ブラウザを検出して最適なフォーマットで配信します。ツーリングに任せましょう。 If you're on Cloudflare with Polish enabled, or using Cloudinary, or Imgix, then honestly you don't need to worry much. They'll detect the browser and serve the optimal format. Let the tooling handle it.
- WordPressサイトですか？ShortPixelまたはImagifyをインストールしてアップロード時の変換に設定してください。完了です。これを手動で管理する必要はまったくありません。 Install ShortPixel or Imagify and configure them to convert on upload. Done. You don't need to manually manage this at all.
クオリティ設定について一言
クオリティ80はクオリティ60ではありません。開発者がWebPクオリティを60に設定するのを見かけます「JPEGより優れているから」という理由で、その後クライアントが製品写真がぼやけていると文句を言う理由を不思議に思います。ビジュアルQAを適切に実施してください。私はSquooshをブラウザで実行して、分割ビューツールで元の画像と出力を切り替えながら、すべてのフォーマット決定を検証します。画像タイプごとに3分かかり、クライアントとの議論を避けられます。
---
JPEGがまだ正しい選択肢である場合
十分な人が言っていないから率直に言います：JPEGは廃れていません。
画像がダウンロードされて再編集される場所でサイトを構築している場合（写真ポートフォリオ、ストック画像、プレスアセットライブラリ）、JPEGは今でも理にかなっています。地球上のあらゆる画像編集アプリケーションで汎用的にサポートされています。PhotoshopのようなツールでのWebP出力品質は劇的に改善されていますが、後処理ワークフロー向けのJPEGの周辺生態系は単純に更に成熟しています。
また、画像がすでに最適化されたJPEG（例えば800px幅で100KB以下）であれば、WebPへの変換で得られる削減は15～20KB程度です。ゼロではありませんが、手動で変換を行う場合、エンジニアリング時間に見合う価値はありません。優先順位をつけましょう。
そして印刷する場合はもちろん、WebPはウェブフォーマットです。紙に出力されるものには使わないでください。
---
実際に使うツール
これらは実際に私が使っているツールで、水増しリストではありません：
- [Squoosh](https://squoosh.app/)：ブラウザベース、インストール不要。ワンオフの比較と自動化前の適切な品質設定を見つけるのに最適です。 Browser-based, no install, brilliant for one-off comparisons and finding the right quality setting before automating anything.
- Squoosh CLI：ターミナルからのバッチ変換。プロジェクトレベルのマイグレーションに使用しています。 Batch conversion from the terminal. I use this for project-level migrations.
- ShortPixel：アップロード時の自動変換に最適なWordPressプラグイン。ロッシー設定がデフォルトで合理的です。 Best WordPress plugin for automated conversion on upload. The lossy setting is sensible out of the box.
- Cloudflare Polish：すでにCloudflare Proを使用している場合、これをオンにしてください。エッジで自動的に変換と圧縮を実行します。コード不要。 If you're already on Cloudflare Pro, turn this on. It converts and compresses at the edge automatically. Zero code required.
- Cloudinary：フォーマットネゴシエーション、レスポンシブサイジング、マネージドサービスとしてのCDN配信が必要な大規模編集またはeコマース運用向けの選択肢。 The choice for larger editorial or e-commerce operations where you need format negotiation, responsive sizing, and CDN delivery as a managed service.
- ImageMagick: サーバーサイドワークフロー向けのコマンドライン変換ツール。Squoosh CLIより遅いですが、スクリプト化されたパイプラインではより柔軟です。 Command-line conversion for server-side workflows. Slower than Squoosh CLI but more flexible for scripted pipelines.
---
FAQ
WebPは常にJPEGより小さいですか?
いいえ。このことを言い続ける人がいますが、残念です。非常に詳細で高周波の画像（例：ラフなテクスチャのマクロ撮影、密集した建築写真）では、エンコーダ設定によってサイズの差がほぼ無視できるか、さらに逆転することもあります。仮定するのではなく、特定の画像をテストしてください。
WebPに変換したら、元のJPEGを保持する必要がありますか?
はい。常に元のファイルを保持してください。WebPは配信フォーマットであり、アーカイブフォーマットではありません。WordPressサイトをShortPixelで実行している場合、プラグインはデフォルトで元のファイルを保持します。その設定を変更しないでください。
WebPに変換すると、画像SEOに悪影響を与えますか?
いいえ。GoogleはWebP画像に問題なくインデックスを付与します。alt属性が説明的で、ファイル名が合理的であることを確認してください。フォーマットは画像検索ランキングに影響を与えません。
`<picture>`要素とWebPを直接配信するのではどちらが良いですか?
ユーザーの97%以上がWebPに対応している場合、<img>タグでWebPを直接配信するのは問題ありません。<picture>要素とソースフォールバックは、SafariがWebPに対応していなかった時代には意味がありました。現在は、主に前述のAVIF-WebPフォールバックパターンで有用です。<img> tag is fine. The <picture> element with source fallbacks made sense when Safari was the holdout. Now it's mainly useful for the AVIF-with-WebP-fallback pattern I mentioned earlier.
画像フォーマットはCLS（Cumulative Layout Shift）に影響しますか？
フォーマット自体は影響しません。ただし、画像を変換する際に明示的なwidthとheight属性を設定していない場合、またはCSSでaspect-ratioを使用していない場合は、フォーマットに関係なくレイアウトシフトが発生します。これは、一括フォーマット移行時に見かける最も一般的なミスの1つです。寸法を修正してください。width and height attributes (or using aspect-ratio in CSS), you'll get layout shift regardless of format. This is one of the most common mistakes I see when people do bulk format migrations. Fix your dimensions.
---
フォーマット決定は小さなことに思えますが、そうではありません。午後1時間の画像最適化だけでサイトを「Core Web Vitalsに不合格」から「合格」に変え、eコマースクライアントのコンバージョン率を大幅に向上させるのを見てきました。2026年において、WebPはほぼすべてのブラウザで配信される写真の正しいデフォルトです。ただし、それはデフォルトであり、ルールではありません。なぜその選択をするのかを理解し、自動化する前にテストし、元のファイルを保管してください。