はじめに

Webサイトのパフォーマンス改善（LCP対策など）で必ず直面するのが「画像の軽量化」です。
「写真はJPEG、ロゴはSVG、最近はWebPがいいらしい」といった定石はあっても、「なぜWebPはこれほど軽いのか？」「内部でどんな計算（予測）をしているのか？」まで説明できるでしょうか。

この記事では、基本の3大フォーマット（JPEG, PNG, SVG）の正体を整理した上で、Googleが生んだWebPの「予測符号化」の凄さを、実際に検証した結果を交えて解説します。

1. 基本の3大フォーマット：名前の由来と役割

まずは、私たちが日々扱っている「基本の3人」を改めて整理しましょう。

正式名称： Scalable Vector Graphics（拡大可能なベクター画像）
特徴： ドットの集まりではなく、「ここに円を描け」というテキストベースの命令（コード）です。無限に拡大してもガビガビにならず、React等でコンポーネント化してCSSで操作できるのが最強の強みです。

WebPがJPEGやPNGより圧倒的に軽い理由は、動画技術から転生した「予測符号化（Predictive Coding）」にあります。

WebPは画像を小さなブロックでスキャンし、「隣のドットが青なら、次も青だろう」と、すでに処理した周囲のピクセルから次の色を予測します。

そして、ここがポイントですが、WebPは「予測した色」を保存するわけではありません。
保存するのは、「予測と、実際の色の『ズレ（差分）』だけ」です。

大きな数字（色の生データ）を保存するより、0に近い小さな数字（差分）を保存する方が、圧倒的にビット数を節約できる。これがWebPが爆速な理由です。

Googleが提供する比較ツール「Squoosh」を使って、風景写真（JPEG）をWebPに変換してみました。

最初はQualityを0にして、94％圧縮。これは目で見てもかなり粗い。
Qualityを50にして、50％圧縮。これは遠目には差分がわからない。十分利用できる。拡大した時に粗さが理解できる程度

驚くべきは、ファイルサイズが半分以下になったにもかかわらず、肉眼では劣化がほぼ判別できない点です。Quality（画質）を50程度まで下げても、WebPの予測ロジックが優秀なため、空のグラデーションなども非常に滑らかに保たれています。

設定項目にある「Effort（努力量）」は、「出力する側がどれだけ必死に予測パターンを総当たりするか」という数値です。

画像の拡張子は、ただのアルファベットではなく「いかに賢くサボって（予測して）データを削るか」という技術の結晶です。

仕組みを理解して使い分けることで、ユーザーのデータ通信量を守り、最高のサイトパフォーマンスを提供していきましょう！