一言でいうと
WebP（ウェッピー）はGoogleが開発したモダンな画像フォーマットだ。動画圧縮のトリックを拝借して、見た目の画質を完全に保ったまま、JPEGやPNGより圧倒的に小さいファイルサイズに画像をギュッと押しつぶしてくれる。
どんな課題を解決するのか
長い間、インターネットの視覚的な部分は、JPEGとPNGという2つの対立派閥による、緊迫した脆い休戦協定によって支えられていた。（GIFも部屋の隅で騒いでいたが、それについては後で触れよう）。
数百万色を使う写真ならJPEGの出番だ。JPEGは「ロッシー（非可逆圧縮）」であり、ファイルサイズを節約するために「人間の目には見えないだろう」というデータを容赦なく切り捨てる。一方、ロゴやクッキリしたテキスト、あるいは背景を透過させたい場合はPNGを使った。PNGは「ロスレス（可逆圧縮）」で、すべてのピクセルを完璧に保持してくれるが、その代償としてファイルサイズが天文学的にデカくなることがあった。では、アニメーションが欲しいときは？ 1987年生まれの化石フォーマットであり、256色しか使えず、絶望的に非効率なGIFを使うしかなかった。
問題は、一般的なWebページのダウンロード容量のうち、画像が60%以上を占めるまでに肥大化してしまったことだ。ブロードバンド回線のデスクトップPCから、電波の不安定な3G回線のモバイル端末へと世の中がシフトするにつれ、こうしたメタボな画像フォーマットは巨大なお荷物になった。画像の読み込みが遅いせいでユーザーはイライラし、ショッピングカートは放棄され、Web全体がまるで泥沼を歩いているかのように重く感じられていたのだ。
2010年頃、Googleはこの「2大フォーマット体制」はもう限界だと判断した。彼らはちょうどその頃、VP8という動画圧縮フォーマットを開発したOn2 Technologiesという会社を買収していた。そこでGoogleのエンジニアたちに天啓がひらめいた。「動画なんて、要は静止画を高速でパラパラ漫画にしてるだけじゃないか。だったら、最先端のVP8ビデオコーデックから『静止画』の部分だけを引っこ抜いて、独立した画像ファイルとしてパッケージングしたらどうだろう？」
こうしてWebPは誕生した。そのミッションは「すべてを統べる唯一のフォーマット」になること。JPEGを凌駕するロッシー圧縮、PNGを打ち負かすロスレス圧縮、透過（アルファチャンネル）、さらにはGIFにようやく引導を渡せるアニメーション機能までもサポートしていた。
裏側の仕組み
WebPがなぜこれほど効率的なのかを理解するには、その「ズル」の手法を見る必要がある。WebPは実際に画像をピクセルごとに保存しているわけではない。画像を数学的にどう推測するかという「手順書」を保存しているのだ。
ロッシー圧縮：予測コーディング（Predictive Coding）
WebPが「ロッシー」モード（JPEGの代替）で動くとき、VP8ビデオコーデックから直輸入された予測コーディングというトリックを使う。
WebPは画像を16x16または4x4ピクセルの「マクロブロック」に分割する。エンコーダーはブロック内の全ピクセルの色を独立して保存する代わりに、現在処理しているブロックの「すぐ上」と「すぐ左」のブロックを見る。そしてこう考えるのだ。「すでに描画したピクセルの情報から、この次のブロックがどんな見た目になるか予測できないかな？」
ほとんどの写真には（青空や、すべすべの頬、あるいは影のように）連続した色の領域があるため、この予測はかなり高い精度で的中する。そしてWebPは、予測と実際の画像との数学的な差分である**残差（residual）**だけを保存する。
ピクセル全体のデータではなく、このほんのわずかな差分だけを保存することで、WebPはファイルサイズを劇的に縮小しているのだ。
ロスレス圧縮：まったくの別物
ロスレスWebP（PNGの代替）はVP8を使わない。こちらはGoogleがWebPのために特別に設計した、まったく別の技術セットを使用している。以下のようなマルチステージのアプローチを採用している：
- 空間予測（Spatial Prediction）： 兄弟分であるロッシーモードと同様に、隣接するピクセルから対象ピクセルを予測しようとする。
- 色変換（Color Transform）： 色データを分離し、冗長な部分を見つけ出す。
- 緑が王様（Green is King）： 人間の目は緑色に最も敏感であるため、緑（グリーンチャンネル）をベースラインとして使い、その値から赤と青の値を予測する。
- LZ77圧縮： 最後に、最適化されたこれらすべてのデータを、辞書式圧縮アルゴリズムであるLZ77の進化版にかけて圧縮する。
ファイル構造（RIFF）
これらすべての基盤として、WebPはRIFF（Resource Interchange File Format）と呼ばれる軽量なコンテナにラップされている。RIFFはタグ付きのファイル構造で、つまりWebPファイルは複数の「チャンク」として整理されている。これにより、コアとなる画像データを壊すことなく、（カメラのEXIFデータなどの）メタデータやICCカラープロファイルをフォーマットに簡単に追加できるようになっている。
| 機能 (Feature) | JPEG | PNG | GIF | WebP |
|---|---|---|---|---|
| ロッシー圧縮 | Yes | No | No | Yes |
| ロスレス圧縮 | No | Yes | Yes | Yes |
| 透過 (Alpha) | No | Yes | 1-bit | Yes（ロッシー・ロスレス両方） |
| アニメーション | No | No | Yes | Yes |
| 平均的な節約率 | 基準 (Baseline) | 基準 | 基準 | 約25〜34%小さい |
現場のリアルな話
ECサイトの雪崩
ある中規模のオンラインアパレルショップでは、モバイル端末での直帰率が異常に高いことに気づいた。調査してみると、商品カタログのページで15MB近い高解像度JPEGをダウンロードしていることが判明したのだ。モバイルブラウザは、カーディガンの巨大な画像をパースするだけで全精力を使い果たしていた。
エンジニアリングチームは、対応ブラウザに対して自動でWebP画像を配信するパイプラインを実装した。ロッシー圧縮の調整により、生地の質感を伝えるのに必要な視覚的な鮮明さを維持しつつ、ページの合計ペイロード（転送量）を3.5MBまで削減。その結果、ページの読み込み時間は4秒も短縮され、モバイルでのコンバージョン率は18%も跳ね上がった。
ここから得られる教訓： 画像のバイト数と収益は逆相関する。小さいファイルを配信すれば、ユーザーはちゃんと商品を買うまでページにとどまってくれる。
透過ヒーロー画像のジレンマ
あるWebデザイナーが、新作SaaSプロダクトのための美しいランディングページを作り上げた。ヒーローセクションには、CSSで動的に変わるグラデーション背景の上に、精巧なサーバーラックの3Dイラストが浮かんでいる。これを実現するには、サーバーラックの画像を背景透過にする必要があった。
デザイナーはそれをアルファチャンネル付きのPNG-24として書き出した。しかし、3Dレンダリングの複雑な陰影と数百万の色のせいで、そのPNGファイルは2.2MBというヘビー級のサイズになってしまった。読み込み時の体感速度は、まるで2004年にタイムスリップしたかのようだった。
開発者はそのPNGを受け取ると、WebPに変換した。ここで使われたのが、WebPの隠されたスーパーパワーだ。それは**「ロッシーなRGB + ロスレスなアルファチャンネル」**という組み合わせだ。これにより、色はJPEGのように圧縮されつつ、透過部分はピクセル単位で完璧に保持され、エッジがギザギザになることもない。結果として生成されたWebPファイルはたったの210KB。見た目の劣化はゼロのまま、サイズを90%も削減することに成功した。
ここから得られる教訓： リッチで写真のような色彩と、背景透過のどちらかを選ぶ必要はもうない。WebPなら両方同時にこなせる。
ミームだらけのブログ
人気のポップカルチャーブログでは、映画のクリップやリアクションを見せるためにアニメーションGIFを多用していた。1記事に5つのGIFが貼られているだけで20MBものデータをダウンロードさせられ、古いノートPCは、その化石フォーマットのデコードにCPUを酷使してジェットエンジンのような音を立てていた。
彼らはメディアライブラリをアニメーションWebPに移行した。GIFはすべてのフレームを「完全な1枚の画像」として保存するのに対し、アニメーションWebPは動画ライクな圧縮を使い、フレーム間の「差分」だけを保存する。そのため節約効果は絶大だった。5MBのGIFが800KBのWebPになり、CPU使用率は崖から落ちるように激減した。
ここから得られる教訓： GIFフォーマットは博物館行きだ。Webでの短いループアニメーションには、WebP（あるいはガチのMP4やWebM動画）のようなモダンなフォーマットの方が圧倒的に優れている。
よくある間違いと罠
- 二重ロッシーの罠： すでにガンガン圧縮されてノイズだらけのJPEGを、ロッシーなWebPに変換するのは悪手だ。WebPのアルゴリズムは、醜いJPEGのブロックノイズを「画像の一部」として真面目に保存しようとしてしまう。その結果、ファイルサイズが逆に大きくなったり、さらにボヤけた画像になったりする。変換時は必ず、可能な限り高品質なソース（RAWファイル、高解像度PNG、未圧縮のオリジナルJPEGなど）から行おう。
- HTMLの
<picture>要素を忘れる： 今でこそWebPは世界中で約97%のブラウザサポートを誇っているが、何年もの間、Googleだけの身内パーティーだった。AppleのSafariがWebPをサポートし始めたのは2020年後半とかなり遅い。もし本当に大昔のブラウザまでサポートしなければならないなら、<img>タグに.webpを雑に突っ込むだけではダメだ。<picture>要素を使ってフォールバックを提供する必要がある：<picture> <source srcset="image.webp" type="image/webp"> <img src="image.jpg" alt="A reliable fallback"> </picture> - 「WebPが常に最小サイズだ」と思い込む： WebPは素晴らしいが、魔法ではない。非常にシンプルでフラットな色のベクター図形（ミニマルなロゴなど）なら、ほぼ間違いなくSVGの方がファイルサイズが小さく、しかも無限にスケールアップできる。同様に、純粋な圧縮率で言えばAVIFのような次世代フォーマットがWebPを打ち負かすことも多い（ただし、AVIFのエンコードにはより多くの計算リソースが必要になる）。
- サーバーでのエンコード時間を無視する： WebPの圧縮はJPEGよりもはるかに多くのCPUパワーを食う。もしユーザーからリクエストが来たタイミングでオンザフライでWebP画像を生成していると、画像のエンコードにかかるCPU時間のせいで遅延が発生し、せっかくの帯域幅節約のメリットを台無しにしてしまうかもしれない。WebPへの変換は、初回のレンダリング時に動的に行うのではなく、事前に（ビルドプロセス中や画像のアップロード時に）済ませておくべきだ。
なぜ知っておくべきなのか
インターネット向けのプロダクトを作るなら、Webのパフォーマンスはもはや贅沢品ではなく、絶対的な必須条件だ。Googleのような検索エンジンは、表示の遅いWebサイトの検索順位を容赦無く下げる。Core Web Vitals（コアウェブバイタル、特にLCP：Largest Contentful Paint）と呼ばれる指標を重視しているからだ。画面上の「最大のコンテンツ」はたいてい画像なので、その画像を最適化することがSEOを改善する一番の近道になる。
さらに言えば、帯域幅には金がかかる。それはあなたにとっても（AWSのデータ転送量のアウトバウンド課金がべらぼうに高いのは有名だ）、従量制のデータプランを使っている途上国のユーザーにとっても同じだ。
ユーザーがアップロードしたアバター画像、巨大なマーケティング用ランディングページ、フォトギャラリー、あるいはECのカタログなどを扱う際、WebPは2020年代におけるデフォルトかつ実用的な選択肢だ。幅広いブラウザサポート、優れたビジュアル品質、そして劇的なファイルサイズの縮小という、最高のバランスを提供してくれる。
さらに深掘りしたい人へ
- Google Developers: An Image Format for the Web - WebPの生みの親による、極めて技術的で公式なドキュメントとリファレンス。
- MDN Web Docs: Image file type and format guide - WebPと他のWeb画像フォーマットの使い分けに関する、Mozillaの素晴らしい解説。
- RFC 6386: VP8 Data Format and Decoding Guide - ロッシーなWebP圧縮を支える基盤エンジン、VP8ビデオコーデックの基礎となるIETF仕様書。
- CanIUse: WebP image format - 世界のどのブラウザのどのバージョンがWebPをサポートしているかを確認できる、ブラウザ互換性の決定版トラッカー。