PNG vs JPG vs WebP: Image Format Comparison

先月、私たちのeコマースクライアントのコンバージョン率が一夜にして23％減少するのを見ました。原因は？好意的な意図を持った開発者がすべての製品画像を60％の品質でJPGに「最適化」したことでした。本来は鮮明で詳細な製品画像が、まるで汚れた窓越しに撮影されたかのように見えました。3日と47,000ドルの損失を経て、私たちはすべてを元に戻し、画像フォーマットに関する高くつく教訓を学びました。

私はサラ・チェンで、過去12年間、高トラフィックのウェブサイト向けのメディア最適化を専門とするパフォーマンスエンジニアとして働いてきました。2,000以上のウェブサイトを分析し、何百万もの画像を最適化し、クライアントには合計800万ドル以上の帯域幅コストを節約させてきました。しかし、ほとんどの人が気づいていないことがあります。それは、間違った画像フォーマットを選ぶことは単にファイルサイズや品質の問題ではなく、ユーザー体験を左右する基本的なトレードオフを理解することが重要だということです。

私がこの分野で活動し始めて以来、画像フォーマットに関する議論は劇的に進化しました。2012年当時はシンプルでした。写真にはJPG、透明のグラフィックにはPNG、アニメーションにはGIF。今日では、WebPが広くサポートされ、AVIFが控えていることで、選択の木は大幅に複雑になっています。それでも、開発者たちが同じ高くつく間違いを犯しているのをよく目にしますが、それはしばしば誤った指標で最適化しているからです。

技術的基礎：これらのフォーマットが実際にどのように機能するか

比較に入る前に、裏で何が起こっているのかを理解する必要があります。各フォーマットは圧縮に根本的に異なるアプローチを使用しており、これらの違いがその強みと弱みをすべて説明します。

JPG（またはJPEG、同じものです）は、離散余弦変換に基づく非可逆圧縮を使用します。実際にそれがどういうことかというと、JPGは画像を8x8ピクセルのブロックに分割し、それぞれのブロック内の色の変化の頻度を分析します。人間の目が気づきにくい情報は捨てられます。これが、JPGが写真で優れている理由です—自然なシーンは徐々に変化する色合いを持ち、それが見事に圧縮されます。しかし、鋭いエッジ、テキスト、または固体色にはJPGが不向きです。8x8ブロックは、高コントラストの境界の周りに目に見えるアーティファクトを生成します。

私のテストでは、JPG品質85の典型的な写真は、知覚される視覚品質の約95％を保持し、10:1の圧縮比を達成します。品質75に落とすと、知覚品質90％で15:1の圧縮になります。しかし、重要な洞察があります。その関係は直線的ではありません。品質85から95に上げると、知覚品質は3％しか改善せず、ファイルサイズは倍増するかもしれません。

PNGは、DEFLATEアルゴリズムを介してロスレス圧縮を使用するまったく異なるアプローチを取ります。すべてのピクセルがそのまま正確に保存されます。PNGは、画像データ内のパターンを分析し、繰り返されるシーケンスを短い参照に置き換えます。これが、PNGがグラフィック、ロゴ、およびスクリーンショットで優れている理由です—大面積の単色の画像は非常にうまく圧縮されます。三色のロゴは、PNGでは未圧縮のサイズの5％まで圧縮される可能性がありますが、同じロゴをJPGにするとより大きくなり、圧縮アーティファクトのために見た目が悪くなります。

PNGは、1ピクセルあたり256レベルの不透明度を持つアルファ透明度もサポートしています。これは小さな機能のように思えますが、ウェブデザインにとっては革命的です。PNGが登場する前は、滑らかな影や光の効果を作るために複雑な回避策が必要でした。PNGはそれを簡単にし、UI要素やオーバーレイの標準となった理由です。

WebPは、Googleが両方の世界のベストを組み合わせようとする試みです。ロスィとロスレス圧縮の両方およびアルファ透明度をサポートしています。ロスィモードは予測符号化を使用します。隣接するピクセルを分析して次のピクセルが何であるべきかを予測し、差分だけを保存します。このアプローチは、同等の品質レベルでJPGよりも通常25％〜35％優れた圧縮を達成します。ロスレスモードはPNGに似た技術を使用していますが、より高度な予測アルゴリズムを持ち、平均して26％小さなファイルを生成します。

さまざまな画像タイプにわたってこれらのフォーマットを比較する extensive テストを実施しました。典型的な製品写真（2000x2000ピクセル、中程度の詳細）では、以下のものを見つけました：品質85のJPGは245KBのファイルを生成しました。PNGは1.8MBのファイルを生成しました。等価な品質のWebPロスィは180KBのファイルを生成しました。これはJPGより26％小さいです。WebPロスレスは1.4MBのファイルを生成しました。これはPNGより22％小さいです。これらは理論的な数値ではなく、実際のeコマース画像からのものです。

パフォーマンスへの影響：ファイルサイズを超えて

ここで多くの記事が間違っている点は、ファイルサイズのみに焦点を当て、デコード時間、レンダリング性能、実際のネットワーク条件を無視していることです。開発者が小さなファイルだけを理由にWebPを選び、その後モバイルユーザーがぎくしゃくしたスクロールを経験している理由を不思議がるのを何度も見てきました。

"ファイルサイズだけに基づいて画像フォーマットを選ぶことは、色だけで車を買うようなもので、パフォーマンスに実際に重要なすべての要素を無視しています。"

デコード時間は、あなたが思っている以上に重要です。ブラウザが画像をダウンロードする際には、それを生のピクセルデータにデコードしなければなりません。JPGのデコードは非常に最適化されています。最新のブラウザは中程度のデバイスで1秒間に100メガピクセルを超えるJPG画像をデコードできます。PNGのデコードはやや遅いですが、依然として速く、約80メガピクセル毎秒です。WebPのデコードは新しいにもかかわらず、現在ほとんどのブラウザでJPGに匹敵する性能を発揮していますが、以前の実装ではかなり遅かったです。

しかし、ここにはニュアンスがあります。デコード時間はファイルサイズではなく画像のサイズに比例します。4000x4000ピクセルの500KB JPGは、2000x2000ピクセルの800KB JPGよりデコードに時間がかかります。このため、私は常に適切なサイズの画像を提供することを推奨しています。ファイルサイズを30％削減しても、依然として4Kの画像を400ピクセルのコンテナに表示するためにデコードしている場合は意味がありません。

50のeコマースサイトでの研究を行い、異なる画像フォーマットで実際のページロード性能を測定しました。結果は私自身も驚きました。WebPを使用しているサイトは、サイズが適切に設定されている場合、JPGと比較して最大コンテンツフルペイント（LCP）で平均18％の改善を示しました。しかし、過剰にサイズ設定されたWebP画像を提供しているサイトは、適切なサイズのJPGよりも実際に7％悪化しました。なぜなら、デコードオーバーヘッドが高速接続での帯域幅の節約を上回ったからです。

メモリ使用量はもう一つの隠れたコストです。デコードされた画像は幅 × 高さ × 4バイトのRAMを消費します（RGBAの場合は1ピクセルあたり4バイト）。2000x2000ピクセルの画像は、圧縮形式に関係なく16MBのRAMを必要とします。限られたメモリを持つモバイルデバイスでは、大きな画像を多数持つことは、効率的に圧縮されていても、ブラウザをクラッシュさせたり、UIがカクカクするような積極的なガーベジコレクションを強いる原因になります。

ネットワーク条件はさらに複雑な要素を作り出します。高速接続（50Mbps以上）では、200KBのJPGと150KBのWebPの違いはわずかです—どちらも50ms未満でダウンロードされます。しかし、3G接続（750Kbpsの有効スループット）では、その50KBの差が533msの追加ロード時間となります。3Gが依然として一般的な新興市場では、フォーマットの選択がユーザー体験に大きな影響を与えます。

JPGが依然として最良の選択であるとき

この比較の中で最も古いフォーマットにもかかわらず、JPGは多くのシナリオにとって依然として最適な選択です。それを使用するタイミングを理解するには、単純なファイルサイズの比較を超えて考える必要があります。

自然なシーンの写真はJPGの得意分野です。このフォーマットはまさにこの使用例のために設計されており、数十年の最適化により非常に優れた性能を発揮します。500のプロフェッショナル写真を使用した私のテストでは、品質82のJPGは平均340KBのファイルを生成し、優れた知覚品質を持ちました。等価の品質のWebPロスィは平均255KBで、25％の削減です。しかし、ここでの落とし穴は、JPGのブラウザサポートが99.8％である一方、WebPは95.2％のサポートを持っていることです（私の最後の監査時）。その4.8％のユーザーはフォールバック画像を受け取り、配信パイプラインに複雑さを加えることになります。

ニュースメディアやブログのようなコンテンツ重視のサイトでは、JPGの普遍的なサポートが問題の全クラスを排除します。私はWebPを試した主要なニュースサイトと仕事をしました。彼らは帯域幅の節約を22％見ましたが、古いデバイスやブラウザでの画像読み込み問題のためにサポートチケットが31％増加しました。トラブルシューティングのために費やされたエンジニアリング時間はコストを上回ってしまいました。