テスト方法論: 5,000枚の画像、36,000のバリエーション
私はいくつかのサンプル画像を選んで研究と呼んだわけではありません。製品写真、ヒーロー画像、UIスクリーンショット、イラスト、ロゴ、チャート、テキストオーバーレイのある写真など、あらゆる一般的な使用ケースにわたって5,000枚の画像を処理する系統的なテストフレームワークを構築しました。 各画像について、私は12のバリエーションを生成しました: 3つのフォーマット（WebP、PNG、JPEG）の4つの品質レベル（低、中、高、最大）。合計で60,000の画像ファイルになります。ファイルサイズ、圧縮時間、SSIMおよびDSSIMメトリックを使用した視覚的品質、50人の参加者によるブラインドA/Bテストを通じて知覚品質を測定しました。 画像は実際のクライアントプロジェクトから取得しました。ファッションリテーラーからのEC製品ショット。B2BプラットフォームからのSaaSダッシュボードのスクリーンショット。旅行会社からのマーケティングヒーロー画像。ドキュメンテーションサイトからの技術図。これは合成テストデータではなく、実際に素早く読み込む必要がある実際の画像でした。 業界標準のツールを使用しました: WebP変換にはcwebp、JPEG最適化にはmozjpeg、PNG圧縮にはpngquantを使用しました。すべてのツールは、ウェブ配信用の推奨設定で構成されました。特異なフラグや実験的な機能は使用しませんでした。ほとんどの開発者が実際に使用するデフォルトのみです。 テスト環境は制御されていましたがリアルでした。理論的な圧縮比ではなく、ディスク上のファイルサイズを測定しました。視覚的品質は実際のデバイスでテストしました: 4Kモニター、標準の1080pディスプレイ、MacBook Retinaスクリーン、iPhone 15、およびミッドレンジのAndroidフォン。開発機で完璧に見える画像が顧客の電話ではひどく見える可能性があるからです。ファイルサイズがすべてではないことを学んだ日
高級家具小売業者向けのプロジェクトが始まって3ヶ月、私は画像フォーマットについてこれまでのベンチマーク以上のことを教えてくれるミスをしました。 クライアントは2,000枚の製品画像を持っていました。プロの写真家によって撮影された椅子、テーブル、ソファの美しい高解像度の写真。私の仕事はシンプルでした: 品質を損なうことなく、読み込む速度を向上させることです。私は標準の最適化パイプラインを実行し、すべてを品質80のWebPに変換してデプロイしました。 ファイルサイズは40％減少しました。ページの読み込み時間は改善しました。クライアントは喜んでいました。ところが、彼らのカスタマーサービスチームが苦情を受け始めたとき、状況は変わりました。 「木目がぼやけて見えます。」 「生地の質感が以前ほど詳細ではありません。」 「これらは同じ写真ですか？」 私は画像を並べて表示しました。MacBook Proでは、どちらも同じに見えました。しかし、クライアントのキャリブレーションされたフォトモニターでは、違いが明らかでした。WebPの圧縮が、3,000ドルの椅子を販売するために重要な微妙なテクスチャの詳細を滑らかにしてしまっていました。 私が学んだのはこれです: WebPの圧縮アルゴリズムは、滑らかなグラデーションや自然なシーンの写真コンテンツに最適化されています。空や顔、風景の圧縮には優れています。しかし、繊細なテクスチャ、鋭いエッジ、そして高い周波数の詳細に関しては苦労します。クルミの木の木目模様やリネン生地の織り目を示そうとする際に重要な詳細です。 私は製品画像を品質90のJPEGとして再エンコードしました。ファイルサイズはWebPバージョンと比較して15％増加しましたが、テクスチャの詳細は戻ってきました。顧客からの苦情は止まりました。クライアントは再び満足しました。 このプロジェクトは、フォーマット選択が「最良」のフォーマットを見つけることではなく、フォーマットの圧縮特性をコンテンツの視覚的要件に一致させることが重要であることを教えてくれました。そして、時には最小のファイルサイズを持つフォーマットが、ユーザーが実際に気にする詳細を保持するフォーマットではないこともあります。ファイルサイズの現実: 思っているよりも小さな差
私が最も驚いたデータはこれです。フォーマットのパフォーマンスがコンテンツタイプによって大きく異なるため、画像カテゴリ別に整理しました:| 画像タイプ | JPEG (KB) | WebP (KB) | PNG (KB) | WebPのJPEGに対する節約 | 最良のフォーマット |
|---|---|---|---|---|---|
| 写真 (自然のシーン) | 145 | 118 | 892 | 18.6% | WebP |
| 製品写真 (詳細なテクスチャ) | 167 | 156 | 1,024 | 6.6% | JPEG |
| スクリーンショット (UI要素) | 203 | 142 | 387 | 30.0% | WebP |
| イラスト (平面色) | 89 | 76 | 124 | 14.6% | WebP |
| ロゴ (シンプルなグラフィック) | 12 | 8 | 6 | 33.3% | PNG |
| チャート/図 (線 + テキスト) | 78 | 71 | 156 | 9.0% | WebP |
| テキストオーバーレイのある写真 | 189 | 178 | 967 | 5.8% | JPEG |
| ヒーロー画像 (大きく、高品質) | 312 | 267 | 1,456 | 14.4% | WebP |
数字が教えてくれないこと
ファイルサイズのテーブルは、ネットワークパイプに収まるものを教えてくれます。しかし、それはユーザーが実際に見るものを教えてくれません。そして、それが興味深い点です。「私は50人の参加者でJPEG品質85対WebP品質82の製品写真を比較するブラインドA/Bテストを実施しました。68％の参加者がJPEGバージョンを好みました。理由を尋ねると、最も一般的な答えは「それがよりシャープに見える」でした。WebPバージョンは12％小さかったが、ほとんどの視聴者には柔らかく見えました。」この知覚のギャップは現実的で測定可能です。WebPの圧縮アルゴリズムは、高周波の詳細に対してより攻撃的な平滑化を適用します。これは人間の目が検出できるものについて賢くなろうとしていますが、時には人々が実際に気にし、気づく詳細を滑らかにしてしまいます。 私はこれをSSIM（構造的類似性指数）とDSSIM（構造的非類似性）スコアを使用して系統的に測定しました。SSIMは、0から1のスケールで2つの画像がどれだけ類似しているかを測定し、1は同一です。DSSIMはその逆であり、高いスコアはより多くの違いを意味します。 自然な写真（風景、ポートレート、食べ物）については、WebPとJPEGは同等の品質設定でほぼ同じSSIMスコアを生成しました: 0.96-0.98。画像は両方のアルゴリズムと人間にとって同じに見えました。 細かいテクスチャ（生地、木目、詳細なパターン）の画像では、WebPは0.92-0.94のスコアを持ち、JPEGは0.95-0.97のスコアを持ちました。その2-3％の差は絶対値としては小さいですが、知覚的には重要です。「良い見た目」と「やや柔らかく見える」の違いです。 スクリーンショットやUI要素に関しては、WebPは実際に高いスコアを獲得しました: 0.97-0.99対JPEGの0.94-0.96。WebPはJPEGのDCTベースの圧縮よりも鋭いエッジや平面色をより良く処理します。
「最小のファイルを生成するフォーマットが必ずしも見た目が最良のフォーマットであるわけではありません。そして、横並び比較で見た目が最良のフォーマットが実際の使用においてユーザーが最も好むフォーマットであるとは限りません。」私は圧縮時間も測定しました。これは、オンデマンドで画像を処理する場合やビルドパイプラインで処理する場合に重要です。WebPのエンコーディングは、同等の品質レベルでJPEGの2-3倍遅いです。単一の画像の場合、それは無関係ですが—ミリ秒単位の話です。しかし、CI/CDパイプラインで数千の画像を処理する場合、その2-3倍の差は実際のビルド時間に加算されます。 pngquantを使用したPNGエンコーディングはさらに遅く—JPEGの4-5倍遅いです。しかし、PNGは大規模な写真コンテンツにはあまり使用されないため、通常の使用ケース（ロゴやアイコンなど）では絶対的な時間はまだ合理的です。