WebP ロスレスは PNG と比べて実際に何を節約できるのか

要点

WebP ロスレスは、同じピクセルに対して PNG より小さくなることがよくあります。これが、人々が WebP ロスレスを使う実務上の理由です。

ただし、「よくある」という言葉が重要です。WebP ロスレスは、すべての PNG を置き換える魔法の手段ではありません。透明部分を含む画像、スクリーンショット、UI キャプチャ、グラフィックと写真が混在するコンテンツでは、特に大きな削減が出やすい傾向があります。一方で、非常に小さなアセット、高度に最適化されたパレット PNG、単純なアイコンでは、ほとんど削減できない、あるいはまれに大きくなることもあります。

実際のウェブサイトを最適化するなら、問うべきなのは「WebP は PNG より優れているのか？」ではありません。問うべきは「自分の PNG のうち、WebP ロスレスにすることで、互換性やワークフロー上の問題を生まずに意味のあるサイズ削減ができるものはどれか？」です。

これはより狭い問いであり、はるかに答えやすい問いです。

ここでいう「ロスレス」の意味

ロスレスとは、デコード後のピクセルが元のピクセルと完全に一致するという意味です。PNG を WebP ロスレスに変換し、再度デコードした場合、画像のピクセルは同一であるべきです。

ただし、ファイルそのものが同じという意味ではありません。メタデータ、カラープロファイルの扱い、補助的な PNG チャンク、ガンマ情報、タイムスタンプ、ツール固有のチャンクなどは、変換パイプラインによって変更されたり、削除されたり、別の形で表現されたりする場合があります。

この違いは、アーカイブ画像、印刷ワークフロー、科学画像、法的証拠、あるいはファイルコンテナ内の非ピクセル情報が重要なあらゆる状況で問題になります。通常のウェブ配信では、多くのチームが主に気にするのは、見た目のピクセル、透明度、寸法、色の一貫性です。

ユーザーが提供した画像を公開している場合、メタデータはプライバシー上の問題でもあります。この広いテーマについては、オンラインで写真を共有する前に EXIF メタデータを削除する方法で扱いましたが、同じ原則がここにも当てはまります。画像最適化では、何を保持し、何を削除するのかを明確にすべきです。

PNG がよく圧縮できる理由と、その限界

PNG は非常に優れた形式です。ウェブの標準的な選択肢になったのには、十分な理由があります。

• ロスレスである。
• アルファ透明をサポートする。
• 広くサポートされている。
• 予測しやすく、扱いやすい。
• フラットなグラフィック、スクリーンショット、ロゴ、UI アセットに優れている。

PNG の圧縮は、画像の行をフィルタリングし、その後 DEFLATE 圧縮を適用することで機能します。この組み合わせは効果的で、特に近接するピクセルが似ている場合に強力です。

問題は PNG が悪いことではありません。問題は PNG が古いことです。PNG の圧縮モデルでは、新しい形式に比べて使える手法が少なくなっています。優れたエンコーダーで PNG を最適化しても、形式自体が一部のパターンを WebP ロスレスほど効率よく表現できないため、まだ削減できるバイトが残ることがあります。

そこで WebP ロスレスが出てきます。

WebP ロスレスは何が違うのか

WebP ロスレスは、フィルタリングされた行に汎用圧縮レイヤーを載せるのではなく、画像のために設計された圧縮システムを使います。内部では、予測符号化、色変換、パレット、後方参照、エントロピー符号化といった手法を使い、繰り返しや予測可能なピクセルパターンをコンパクトに表現できます。

実装の詳細を暗記する必要はありません。役に立つ考え方は次の通りです。

PNG は行をうまく圧縮する。WebP ロスレスは、画像構造を記述する方法をより多く持っている。

この追加の柔軟性があるため、WebP ロスレスは同じ元画像から、より小さなファイルを作れることが多いのです。

Google は過去に、自社の調査において WebP ロスレス画像は PNG より平均で約 26% 小さいと説明しています。これは方向性を示す目安として扱い、約束として受け取らないでください。あなたの画像は平均ではありません。デザインシステム、スクリーンショット、商品写真、イラスト、書き出されたアセット、CMS へのアップロードには、それぞれ独自の挙動があります。

WebP ロスレスで特に削減しやすい領域

透明画像

PNG はアルファ透明のためによく使われます。WebP ロスレスもアルファをサポートしており、多くの場合それを効率よく圧縮します。

これは次のような用途で有用です。

• 商品の切り抜き
• ステッカーやバッジ
• インターフェースのオーバーレイ
• 透明背景の図解
• 必要以上に大きく書き出されたロゴ

アルファチャンネルに大きく予測しやすい領域、柔らかいエッジ、繰り返し形状が含まれる場合、削減効果は目に見えるものになります。透明な商品画像が大量にあるカタログなら、早い段階で WebP ロスレスを試す価値があります。

スクリーンショットと UI キャプチャ

スクリーンショットには、大きな単色領域、繰り返しのインターフェース部品、テキスト、アイコン、影、そして一部の写真領域が含まれることがよくあります。この混在は、特に寸法が大きい場合、PNG には扱いにくいことがあります。

WebP ロスレスは、こうした画像をうまく扱うことがよくあります。最適化済み PNG で 900 KB のフルページ UI スクリーンショットが、ロスレス WebP では 500〜700 KB になるかもしれません。削減幅がもっと大きいこともあります。小さいこともあります。それでも、このカテゴリは有望です。

こうしたスクリーンショットがドキュメント、マーケティングページ、オンボーディングフロー、事例紹介に表示されるなら、合計での効果は現実的なものになります。

イラストと画像が混在するコンテンツ

現代のウェブグラフィックの多くは、純粋なイラストでも純粋な写真でもありません。商品 UI、グラデーション、小さなアイコン、テキストラベル、埋め込み写真を含むヒーロー画像を考えてみてください。

PNG はそれを完全に保持できますが、ファイルが大きくなることがあります。非可逆 WebP や AVIF は、強く圧縮しすぎるとテキストやエッジの周囲にアーティファクトを生む場合があります。正確なエッジが重要なとき、WebP ロスレスは妥当な中間地点になり得ます。

AVIF や非可逆 WebP を含む画像形式全体の判断フローについては、2026 年の画像形式：AVIF が WebP に勝つとき、勝たないときをご覧ください。

PNG のほうが依然として良い場合

小さなアイコンと単純なアセット

非常に小さいファイルでは、形式そのもののオーバーヘッドが効きます。650 バイトの PNG アイコンは、変換の明らかな候補ではありません。WebP にすると 80 バイト節約できるかもしれませんし、逆に大きくなるかもしれません。

その規模では、運用上の複雑さがメリットを上回ることがあります。ファイルがすでに小さく、レンダリングをブロックせず、長期間キャッシュされるなら、おそらく他に直すべきことがあります。

丁寧に最適化されたパレット PNG

一部の PNG は、限られたパレットを使っているため、人々が想像するよりずっと小さくなっています。優れたインデックスカラー PNG は、単純なグラフィックではなかなか上回れません。

これは特に次のようなものに当てはまります。

• 小さなロゴ
• ピクセルアート
• フラットなアイコン
• 単純な図解
• 色数の少ないグラフィック

WebP と雑な PNG 書き出しを比較するときは注意してください。PNG がデザインツールからそのまま書き出され、不要なメタデータや不十分な圧縮設定を含んでいる場合、WebP は劇的に良く見えるかもしれません。しかしそれは、WebP が十分に最適化された PNG に対して同じ差で勝つという意味ではありません。

公平なテストでは、たまたまアップロードされたファイルではなく、最適化済み PNG と WebP ロスレスを比較します。

本来は非可逆にすべき画像

これは見落とされがちな失敗です。そもそも PNG にすべきではなかった画像を、チームが WebP ロスレスに変換してしまうことがあります。

典型的なのは写真です。フルカラー写真を PNG として保存すると、非常に大きくなることがあります。それを WebP ロスレスに変換すればファイルは小さくなるかもしれませんが、通常は高品質な非可逆 WebP や AVIF よりもまだかなり大きくなります。

ユーザーが違いを知覚できないなら、ロスレスはしばしば間違った目標です。商品写真、編集用画像、背景、ポートレートは通常、適切な品質設定の非可逆形式に属します。

ロスレスは、正確なピクセルが重要な場合に残しておくべきです。UI スクリーンショット、図解、テキストの多いグラフィック、透明画像、生成されたチャート、非可逆圧縮で目に見えて劣化するアセットなどです。

バイト以外に節約できるもの

明らかな節約は転送サイズです。画像ファイルが小さくなれば、通常は帯域幅が減り、ダウンロードが速くなり、低速回線での挙動も改善します。

ただし、副次的な利点もあります。

• 従量制プランの訪問者が使うデータ量の削減
• 画像キャッシュの蓄積の高速化
• CDN 帯域幅の削減
• 大規模運用におけるストレージとバックアップ量の削減
• パフォーマンス予算への圧力の低下

これらの節約は均等には分布しません。2 MB の PNG 1 枚を 900 KB の WebP に変換するほうが、50 個のアイコンをそれぞれ 100 バイトずつ削減するより重要です。

だからこそ、画像最適化は形式への思想ではなく、ページへの影響で優先順位をつけるべきです。Lighthouse が画像配信を指摘した場合、それは判決ではなく手がかりとして読みましょう。慌てずに Lighthouse レポートを読む方法のガイドでは、意味のあるパフォーマンス問題とノイズの多い診断を切り分ける方法を説明しています。

デコードコストとのトレードオフ

小さいファイルだけがパフォーマンス変数ではありません。ブラウザは画像を描画する前にデコードする必要もあります。

PNG のデコードは成熟しており、通常は高速です。WebP のデコードも広くサポートされて効率的ですが、場合によっては CPU コストが高くなることがあります。現代的なデバイスではこれが障害になることはまれですが、低価格帯のスマートフォン、画像の多いページ、ファーストビュー内の大きなアセットでは、測定する価値があります。

実務上の目安はこうです。WebP ロスレスが大きな PNG を 30〜50% 削減するなら、通常はネットワーク上の節約が勝ります。小さな PNG を 3% しか削減しないなら、そのトレードオフは気にする価値がない可能性が高いです。

パフォーマンス改善には、このようなしきい値判断が多くあります。すべてのバイトを同じ強度で最適化しようとしないでください。

シンプルなテスト方法

1 枚の画像ではなく、代表的なまとまりを使いましょう。

実際のサイトから例を集めたフォルダを作ります。

• ロゴとアイコン
• スクリーンショット
• 商品の切り抜き
• 図解
• CMS にアップロードされた PNG
• ソーシャルプレビュー画像
• 大きなヒーローグラフィック

次に、3 つを比較します。

1. アップロードされた元の PNG
2. 最適化済み PNG
3. WebP ロスレス版

コマンドラインのワークフローでは、oxipng、pngcrush、zopflipng、cwebp -lossless などのツールがよく使われます。具体的なツールよりも、同じ条件で比較する規律のほうが重要です。

追跡する項目は次の通りです。

• ファイルサイズ
• デコード後のピクセル一致
• 対象ブラウザでの視覚的レンダリング
• 透明度の正しさ
• 色の見え方
• ビルド時間
• CMS やデザインワークフロー上の摩擦

簡単なスプレッドシートで十分です。元のファイルサイズ、最適化済み PNG サイズ、WebP ロスレスサイズ、削減率、画像が表示されるページを追加します。

そして、削減された総バイト数で並べ替えます。その並び順が、たいてい次に何をすべきかを教えてくれます。

配信：古いクライアントを不用意に壊さない

WebP のサポートは、現代的なブラウザ全体でかなり広がっています。ほとんどの公開ウェブサイトでは、安全に使えます。それでも、埋め込み WebView、メールクライアント、レガシーなエンタープライズブラウザ、ネイティブアプリ、特殊なクローラーが混在している場合は、PNG を完全に置き換える前にテストしてください。

保守的なパターンは、PNG をフォールバックとして残し、対応している環境には WebP を配信することです。

<picture>
  <source srcset="diagram.webp" type="image/webp">
  <img src="diagram.png" alt="Diagram showing the checkout flow">
</picture>

この方法は退屈ですが、退屈であることは良いことです。WebP に対応しているユーザーは小さいファイルを受け取ります。それ以外のユーザーは PNG を受け取ります。

ビルドシステムがアセットにフィンガープリントを付け、CDN が適切にキャッシュしているなら、これは維持が難しいものではありません。CMS で代替形式の扱いが面倒な場合は、メディアライブラリ全体を 1 回のスプリントで変換しようとするのではなく、最も大きく、最も繰り返し使われる画像から始めましょう。

プライバシーとローカル処理

画像変換は、ビルドパイプラインやサーバー側のメディアサービスで行われることがよくあります。多くのチームにとって、それで問題ありません。ただし、機密性の高いスクリーンショット、顧客のアップロード、社内文書を扱う場合は、ファイルがどこで処理されるかを意識してください。

ブラウザ側の画像ツールは、多くの単純な変換、プレビュー、メタデータ確認に十分なレベルになっています。限界はありますが、ローカル処理はプライベートな画像の不要なアップロードを減らせます。このトレードオフについては、ブラウザで画像を処理することがプライバシー上の利点になる理由で扱いました。

社内アセットについて重要なのは、ポリシーを明確にすることです。画像がデバイスの外に出るのか、変換後の版がどこに保存されるのか、メタデータが保持されるのかを把握しておきましょう。

実用的な経験則

次の 3 つがすべて当てはまる場合、WebP ロスレスを使います。

• 元画像が現在 PNG である。
• 正確なピクセルまたはきれいな透明度が重要である。
• 最適化済み PNG と比較したうえで、WebP ロスレスが意味のある量を削減する。

次の場合は PNG のままにします。

• ファイルが非常に小さい。
• PNG がすでにパレット最適化されており、競争力がある。
• 互換性上の制約が特殊である。
• 運用上の複雑さが、削減できるバイトに見合わない。

次の場合は非可逆 WebP または AVIF を使います。

• 画像が写真である。
• 正確なピクセルが重要ではない。
• 品質設定によって、目に見える損傷なしにサイズを大きく削減できる。

最良の画像戦略が、あらゆる場所で 1 つの形式になることはほとんどありません。少数のルールを一貫して適用することです。

<!-- tool-cta:start -->

💡 お試しください: 同じPNGをImage Converterに通してロスレスのWebP版を生成し、ファイルサイズを直接比較してください。

<!-- tool-cta:end -->

では、WebP ロスレスは実際に何を節約するのか

PNG が圧縮手法を使い切ったところで、バイトを節約します。ときには控えめな 10% です。ときには大きな透明画像をほぼ半分にします。実際のサイト全体では、削減効果は通常、一部のアセットに集中します。

重要なのはそこです。WebP ロスレスは、PNG からの道徳的なアップグレードではありません。透明度を持ち、現代的なブラウザで広くサポートされる、より小さなロスレスウェブ画像を作るための実用的な選択肢です。

数字が正当化するところで使いましょう。そうでないところでは、PNG をそのままにしておきましょう。