先に要点
- WebP は Google が 2010 年に発表した VP8 動画コーデックを画像化したフォーマット。JPEG 比で 25〜35%、PNG 比で 26% 前後の圧縮率を実現し、Web パフォーマンス改善の定番手段として広く採用されている。
- 2026 年時点で Chrome / Edge / Firefox / Safari / iOS / Android の全主要環境が対応済み。caniuse のグローバルサポートは 97% 超で、事実上の標準として扱える。
- 特徴は 非可逆(lossy) と可逆(lossless) の両対応 + 透過(alpha) + アニメーション。「JPEG の代替(写真)」 と 「PNG の代替(透過・ロゴ)」 と 「GIF の代替(短いアニメ)」 を 1 つでカバーできるオールラウンダー。
- AVIF はさらに 20〜30% 軽いが、AVIF のエンコードは WebP より 10〜100 倍遅い。リクエスト時のオンザフライ変換や CPU 制約のある環境では WebP のほうが現実的。
- 判断軸: 「軽量化を始めたい初手なら WebP」「写真系で限界まで削りたい静的アセットなら AVIF」「編集互換最優先なら JPEG / PNG」。CDN(Cloudflare Polish / Vercel Image Optimization / CloudFront + Lambda@Edge)で自動変換すれば、ソースは JPEG / PNG のまま運用できる。
「サイトの表示速度を改善したい」「画像サイズが大きくてモバイル UX が悪い」── そういう場面で最初に検討するのが WebP です。Google が 2010 年に発表してから 15 年以上経ち、2026 年時点では 主要ブラウザがすべて対応する事実上の標準に育っています。
ざっくり言うと、WebP は 「JPEG / PNG / GIF を一つでカバーできるオールラウンダー」で、JPEG より 25〜35% 軽く、PNG より 26% 前後軽くなります。後発の AVIF はさらに圧縮率が高いものの、WebP は エンコード速度・編集ツール互換・運用の安定性で優位があります。
この記事では、WebP の 仕組み・JPEG / PNG / GIF / AVIF との違い・quality 設定の体感・対応状況・実装方法・移行戦略 を実務目線で整理します。AVIF との比較は AVIF とは — WebP / JPEG との違い も併読してください。
WebP とは — まず一言で
WebP は 「Google が動画コーデック VP8 をベースに作った Web 配信向け画像フォーマット」です。拡張子は .webp、MIME タイプは image/webp を持ちます。
由来と歴史
Google が 2010 年に発表。動画コーデック VP8(WebM プロジェクト由来)のキーフレーム圧縮を画像 1 枚に応用したフォーマット。Web に最適化された配信用フォーマットとして設計された。
圧縮の強さ
JPEG 比で 25〜35%、PNG 比で 26% 前後(Google 公式数値)。写真系では同じ SSIM(構造的類似度)で JPEG より 約 32% 小さいという測定結果があり、サイト全体の画像トラフィックを 20〜35% 削減できる事例が多い。
機能セット
非可逆(lossy) と可逆(lossless) の両対応、透過(alpha チャンネル)、アニメーションをサポート。「JPEG / PNG / GIF を 1 つで置き換えられる」 のが最大の特徴。
ライセンス
BSD ライセンスベースで ロイヤリティフリー。商用 / 非商用を問わず自由に利用できる。VP8 の特許プールも解放済み。
JPEG / PNG / GIF / AVIF との比較
主要画像フォーマットを 1 表で並べます。
| 項目 | WebP | JPEG | PNG | GIF | AVIF |
|---|---|---|---|---|---|
| 登場年 | 2010 | 1992 | 1996 | 1987 | 2019 |
| 圧縮率(JPEG 比) | 25〜35% 軽い | 基準 | — | — | 約 50% 軽い |
| 非可逆 / 可逆 | 両対応 | 非可逆のみ | 可逆のみ | 可逆(色数制限あり) | 両対応 |
| 透過(alpha) | ○ (256 段階) | × | ○ (256 段階) | △ (1 ビット) | ○ |
| アニメーション | ○ | × | × | ○ | ○ |
| 色数 | フルカラー | フルカラー | フルカラー | 256 色まで | フルカラー + HDR |
| ブラウザ対応 | 主要ブラウザ全対応 | 全対応 | 全対応 | 全対応 | 主要ブラウザ全対応(2024〜) |
| エンコード速度 | 速い〜中 | 速い | 中 | 速い | 遅い(WebP の 10〜100 倍) |
「WebP は GIF / JPEG / PNG の全機能を一つでカバー + 全部より軽い」 という位置づけ。AVIF はさらに軽いが、エンコード負荷が桁違いに重く、運用とのバランスで WebP が選ばれることも多い。エンコード時間の違いがなぜ実務で効くのかは、後述の「WebP を選ぶべき具体シーン」で掘り下げます。
WebP quality と JPEG quality は「同じ数字でも別物」
実務で一番混乱するのが quality 値の読み替えです。WebP も JPEG も 0〜100 の quality を取りますが、同じ数字でも体感画質とファイルサイズが噛み合いません。「JPEG では 85 で配信していたから WebP も 85 でいいだろう」 と機械的に置き換えると、削減効果を取りこぼします。
Google の WebP Compression Study と複数のベンチマークを総合すると、WebP quality 75 がおおむね JPEG quality 80〜85 と同等以上の見た目になり、同じ SSIM(構造的類似度)で比較すると WebP は JPEG より平均 25〜34% 小さくなります。つまり 「WebP では quality を 5〜10 下げてもよい」 のが基本姿勢です。
| 狙う見た目 | JPEG quality | 同等になる WebP quality | サイズの目安(1200px 写真 1 枚) |
|---|---|---|---|
| サムネ・一覧画像 | 70 前後 | 60〜65 | JPEG 約 60KB → WebP 約 40KB |
| 記事内の標準的な写真 | 80〜85 | 72〜78 | JPEG 約 180KB → WebP 約 120KB |
| ヒーロー画像・LP(高画質) | 90 前後 | 82〜88 | JPEG 約 320KB → WebP 約 220KB |
※サイズは写真の内容(ノイズ量・グラデーション・テクスチャ)で大きく変わるため、あくまで桁感の目安です。空や肌などのなだらかな面が多い写真ほど WebP の削減幅は大きく、細かいテクスチャが詰まった画像ほど差は縮みます。
体感差を一言でまとめると、「WebP quality 75 の写真は、JPEG quality 85 と並べてもほとんどの人が違いに気づかないが、ファイルは 3 割前後軽い」。逆に WebP quality を 50 以下まで下げると、JPEG のブロックノイズとは違う「のっぺりした塗り(バンディング・テクスチャの溶け)」が出る のが WebP 特有の劣化です。JPEG の劣化が「四角いブロック」なのに対し、WebP は「細部が平滑化されて消える」方向に崩れるため、髪の毛・芝・砂利などの細密テクスチャがある写真は quality を 5 ほど高めに振る と安全です。
実際に自分の手元で確認するなら、cwebp で quality を振って書き出し、サイズを並べて比べるのが確実です。
ポイントは 「JPEG の quality 表とは別の感覚で WebP を設定する」 こと。JPEG の数字をそのまま流用せず、上の対応表を起点に quality を 5〜10 下げてから自分の代表画像で見比べる のが、削減効果を最大化しつつ事故を避ける運用です。
2026 年の対応状況
WebP は サポートがほぼ完了している成熟したフォーマット。
ブラウザ
Chrome 32+(2014)/ Edge 18+ / Firefox 65+(2019)/ Safari 14+(2020、iOS 14+) がすべて対応。Internet Explorer のみ非対応だが、IE は 2022 年にサポート終了済み。
OS のサムネ表示
macOS 11+ / Windows 10+(Microsoft Store のコーデック追加で対応)/ iOS 14+ / Android 4+ がプレビュー可能。古い Windows 10 デフォルトでは WebP プレビュー不可 なケースもあり、ユーザー環境に若干注意。
編集ツール
Photoshop は 2022 年から正式対応、Figma / Canva / Affinity / GIMP / Krita もすべて対応。主要画像編集ソフトはほぼ全対応で、編集時の互換性問題はほぼ無い。
CDN / 画像最適化サービス
Cloudflare Polish / Vercel Image Optimization / AWS CloudFront / Cloudinary / imgix が 自動変換に対応。「元データは JPEG / PNG、CDN が Accept ヘッダを見て WebP を返す」 のが現代の運用標準。
実装方法 — picture 要素 / 拡張子切り替え
WebP を導入する方法は大きく 3 通りあります。
picture 要素を使う方法は HTML 側で完結し、CDN なしでも導入できます。Next.js のような現代フレームワークでは Image コンポーネントが自動でやってくれます。「nginx 自動切り替え」 は元コードを変えずにサーバ側で対応する場合に有効です。
変換ツールと cwebp の主要オプション
WebP への変換は AVIF より 速くて簡単です。Google 公式の libwebp に含まれる cwebp コマンドが基本で、覚えるべきオプションは多くありません。
| オプション | 意味 | 既定値 / 範囲 | 効果 |
|---|---|---|---|
-q |
品質 | 既定 75 / 0〜100 | 非可逆では低いほど小さく低画質。可逆では低いほど高速・大きい |
-m |
圧縮メソッド | 既定 4 / 0〜6 | 高いほど時間をかけて解析し、同画質でより小さくなる |
-lossless |
可逆モード | — | PNG 代替。図表・ロゴ・スクショ向け |
-near_lossless |
準可逆の前処理 | 既定 100 / 0〜100 | 60 前後で視覚劣化ほぼ無しにさらに圧縮 |
-mt |
マルチスレッド | — | サイズは変えずエンコードを高速化 |
コマンドライン (cwebp)
cwebp input.jpg -q 75 -o output.webp が基本形。最後まで削りたいときは -m 6 を足す。大量変換は find . -name "*.jpg" -exec cwebp -q 75 {} -o {}.webp \; のようにループ。
画像処理ライブラリ
Sharp(Node.js) は sharp(input).webp({ quality: 80 }).toFile(out) と書ける。Pillow(Python) は Image.open(input).save(out, "WebP", quality=80) で出力。ImageMagick も対応。
CDN オンザフライ変換
Cloudflare Polish / Vercel Image Optimization / Cloudinary / imgix が Accept ヘッダを見て WebP / JPEG を自動配信。元画像 1 枚を置くだけで運用ゼロ。
Web ベース変換ツール
Squoosh / CloudConvert / Convertio などのオンライン変換。少数の画像を試したいとき / quality を比較したいときに便利。
WebP を選ぶべき具体シーン — AVIF との使い分け
「とにかく軽い方が良いなら AVIF では?」という疑問が当然出ます。圧縮率だけ見れば AVIF が上ですが、WebP のほうが正解になる具体的な状況が 2 つあります。AVIF 記事との違いはここに集約されます。
1. エンコード時間の制約があるとき(オンザフライ変換・CI 時間・CPU 予算)
最大の論点は エンコード速度です。AVIF は同等品質を出すのに WebP の 10〜100 倍の時間がかかります。これは「ベンチで遅い」程度の話ではなく、運用形態によっては致命的になります。
リクエスト時に変換する場合
ユーザーがアップした画像をサムネ化して即返す、サイズ違いを動的生成する、といった リクエスト時オンザフライ変換では、AVIF のエンコード時間がそのままレスポンス遅延になる。WebP なら 1 枚数十ミリ秒だが、AVIF は秒単位になり得る。動的生成・リアルタイム変換は WebP が現実解。
逆に言えば、静的アセットを事前生成してキャッシュ配信する構成なら、エンコードが遅くても 1 回きりなので AVIF が有利です。「変換が 1 回で済むか、毎回走るか」が WebP / AVIF の分岐点になります。
2. 編集互換・後工程の互換が必要なとき
もう一つは ツールチェーンの互換性です。WebP は登場から 15 年が経ち、Photoshop / GIMP / Figma / Canva / Affinity がすべて読み書き対応、CMS プラグインやサムネ生成系のライブラリも枯れています。
中間素材として扱うとき
制作フローの途中で デザイナーが開いて手直しする 画像なら、対応の厚い WebP のほうが事故が少ない。AVIF はまだ「読めるが書けない」「特定バージョンで挙動が違う」ツールが残る。
古い OS のサムネ・プレビュー
WebP は macOS 11+ / Windows 10+(コーデック追加)/ iOS 14+ で OS プレビューが効く環境が広い。社内配布や顧客への画像受け渡しで「開けない」苦情が出にくい。
サードパーティ連携
外部 API・広告配信・印刷入稿など 自分が制御できない後工程に画像を渡す場合、対応の枯れた WebP のほうが受理されやすい。AVIF は弾かれることがまだある。
まとめると、WebP は「速く・広く・確実に」、AVIF は「事前生成した静的アセットを限界まで軽く」。両者は競合ではなく、後述の picture 三段構えで併用するのが定石です。
エンコード設定の目安
WebP は 品質 (quality) パラメータで圧縮率をコントロールします(前章の JPEG 読み替え表とあわせて参照してください)。
| 用途 | quality | 備考 |
|---|---|---|
| サムネ・小さい画像 | 60〜70 | サイズ最小化重視、画質劣化が目立ちにくい |
| 記事内の写真 | 75〜80 | JPEG quality 85 相当の画質感 |
| ヒーロー画像・LP | 85〜90 | 高画質、ファイルサイズ大きめ |
| ロスレス(透過 PNG 代替) | -lossless |
PNG 代替、図表・ロゴ・スクリーンショット |
繰り返しになりますが、JPEG の quality 値とは 体感の対応が違う(WebP の quality 75 ≈ JPEG quality 85)ので、自分のサイトで 品質を見比べてから決める のが安全です。
移行戦略 — JPEG / PNG → WebP
既存サイトを WebP 対応にする時のステップを整理します。
「まず CDN オンザフライ変換を試して、効果が出るなら本格的にビルドパイプライン化」 という流れが、AVIF と同じく現代的なアプローチです。
ハマりやすいポイント
実装で踏みやすい落とし穴を、現象 → 原因 → 確認 → 回避 の形で整理します。
Accept ヘッダのキャッシュ事故
現象: WebP 未対応環境で画像が壊れる/ダウンロードされる。原因: CDN が Accept を Vary に含めず、WebP レスポンスがキャッシュ共有された。確認: レスポンスヘッダに Vary: Accept があるか見る。回避: Cloudflare / CloudFront は自動だが、自前リバースプロキシでは必ず明示する。
MIME タイプが返らない
現象: WebP がブラウザでダウンロード扱いになる。原因: 古いサーバ設定で application/octet-stream が返る。確認: curl -I で Content-Type を見る。回避: サーバに image/webp のマッピングを追加。
ダウンロード提供用の画像
ユーザーが画像をダウンロードして OS 標準アプリで開く想定の場合、WebP より JPEG / PNG のほうが安全。「プレビューは WebP、ダウンロード用は JPEG」 のように分けるケースも。
PNG ロスレスより大きくなる場合
現象: 図表・スクショを WebP lossless にしたら PNG より大きい。原因: 色数が少なく規則性の高い画像では PNG が有利なことがある。確認: 変換後に両者のサイズを比較。回避: 小さい方を採用してから本番置き換え。
WebP を使うべきか / 使わないべきか
判断の目安を整理します。
WebP に関するよくある質問
Q. WebP と AVIF、どっち使うべき?
A. 「事前生成できる静的アセットなら AVIF を優先 + WebP フォールバック、リクエスト時変換や CPU 制約があるなら WebP」。AVIF はさらに 20〜30% 軽い反面、エンコードが WebP の 10〜100 倍遅いので、変換が毎回走る構成では WebP が現実的です。picture で 「AVIF → WebP → JPEG」 と並べると、対応ブラウザから順に軽いフォーマットを使ってくれます。詳しくは AVIF とは。
Q. WebP quality 75 は JPEG だと何くらい?
A. 「JPEG quality 80〜85 相当の見た目で、ファイルは 3 割前後軽い」。同じ SSIM で比べると WebP は JPEG より 25〜34% 小さくなります。JPEG の数字をそのまま流用せず、WebP では quality を 5〜10 下げてから代表画像で見比べる のがコツです。
Q. WebP は SEO に有利ですか?
A. 「画像の軽量化が LCP 改善に繋がり、間接的に SEO に効く」のがメイン効果。Core Web Vitals は検索ランキング要素なので、画像を軽くしてページ表示を速くすれば順位にプラス。「WebP というフォーマット自体を Google が優先する」 ことはありません。
Q. WordPress や CMS で使えますか?
A. 「使える(プラグイン経由)」。WordPress は 5.8 以降が WebP アップロードをサポート。Smush / Imagify / ShortPixel / EWWW Image Optimizer などのプラグインが自動で WebP に変換してくれます。「オリジナルは JPEG / PNG のまま、配信時に WebP を自動生成」 が定番。
Q. WebP を使うとサイトデザインが崩れることは?
A. 「ほぼ無い」。表示品質は JPEG / PNG と遜色なし。ただし quality を 50 以下まで下げると、JPEG のブロックノイズとは違う「細部が平滑化されて消える」劣化(髪・芝・砂利などが溶ける)が出ます。75 以上を目安にし、細密テクスチャの写真は気持ち高めに振ると安全です。
Q. アニメーション WebP は GIF の完全代替になりますか?
A. 「ファイルサイズで圧倒、ループ動作も同じ」。GIF の 50〜80% のサイズで同じアニメーションを配信できます。Retina 向けの @2x / @3x でも軽い。ただし SNS 投稿用では GIF が好まれる場面もあるので、用途に応じて使い分けを。
Q. WebP の透過は本当に PNG と同等?
A. 「256 段階の alpha チャンネルで PNG と同等」。透過 PNG を WebP lossless に変換しても見た目は変わらず、ファイルサイズだけが 20〜30% 削減されます。透過が必要な UI 画像は積極的に WebP に変える価値あり。
Q. WebP のエンコードを速くするには?
A. 「-mt でマルチスレッド化し、急ぐなら -m を下げる」。-mt はサイズを変えずに高速化、-m(既定 4)を下げると速くなる代わりに同画質でやや大きくなります。大量変換の CI では -mt 併用が基本。逆に最後まで削りたい静的アセットは -m 6 を使います。
まとめ
WebP は 「Web 表示速度改善の定番手段」として、2026 年時点で完全に成熟したフォーマットです。「JPEG 比 25〜35%、PNG 比 26% 前後の圧縮率」 を 「主要ブラウザ全対応 + 編集ツール全対応 + ロイヤリティフリー」 で享受できる、導入リスクが極めて低い選択肢。
quality は JPEG の数字をそのまま流用せず 5〜10 下げてから見比べる、エンコードが毎回走る構成や CPU 制約がある場面では AVIF より WebP を選ぶ──この 2 点を押さえれば失敗しません。picture 要素で JPEG / PNG にフォールバックすれば未対応環境(極小)を安全にカバーでき、CDN(Cloudflare / Vercel / Cloudinary)に任せれば 運用負荷ほぼゼロで導入できます。さらに削減したい静的アセットには AVIF を併用し、「AVIF → WebP → JPEG」 の三段構えで全ブラウザを最適配信するのが現代の標準です。
参考リンク
- Google: WebP 公式
- Google: WebP Compression Study
- Google: cwebp コマンドリファレンス
- caniuse: WebP image format
- MDN: WebP 画像フォーマット
- libwebp: WebP のリファレンス実装