WebP vs JPEG: Which Format Should You Actually Use?

先週の火曜日、私たちのCDN請求書が一日で847ドルも減少するのを見ました。トラフィックが減ったからではなく、実際には新たな記録を達成したからですが、ようやくCTOを説得して、製品画像をJPEGからWebPに変換する許可を得たからです。私はサラ・チェンで、過去11年間、200万人以上の月間ユーザーにサービスを提供するeコマースプラットフォームの画像配信最適化に努めてきました。この間、フォーマット戦争が生じては消えていくのを見てきましたが、エンジニアリング会議でWebP対JPEGについての議論以上に熱いものはありませんでした。

誰も教えてくれないこと：答えは簡単ではなく、「すべてにWebPを使えばいい」と言う人は、スケールでの生産システムの厄介な現実に直面したことがないのです。47の異なるクライアントサイトを移行し、無数のA/Bテストを実行した結果、正しい選択はほとんどの開発者が考慮しない要因によります。

誰も話さない現実のパフォーマンスギャップ

重要な数字から始めましょう。最近行った大規模テストでは、アパレル小売業者のカタログに含まれる230万の製品画像で、WebPファイルは視覚的に同じ品質レベルでJPEGファイルよりも平均26%小さかったです。これがどこにでも見られる主要な数字です。しかし、ベンチマークが示さないものがあります：実際のパフォーマンスの影響は画像の特性によって大きく異なりました。

多くのグラデーションや自然のテクスチャを持つ写真、例えば風景のショットや料理の写真では、WebPは常に28-34%のサイズ削減を実現しました。しかし、鋭いエッジやテキストオーバーレイ、高コントラストのグラフィックスでは、その利点はわずか12-18%に縮小しました。かつて、インフォグラフィックのサムネイルがうまく圧縮されなかった理由をデバッグするのに3日間を費やし、特定のコンテンツタイプに対してJPEGの方が実際には小さいファイルを生成していることを発見しました。

圧縮アルゴリズムの違いは、多くの開発者が気づくよりも重要です。JPEGは離散コサイン変換(DCT)を使用しており、滑らかなグラデーションには優れていますが、鋭い遷移には苦労します。WebPは予測コーディングと算術エンコーディングを採用し、異なる画像タイプに対してより多用途です。実際には、WebPは多様なコンテンツを効率的に扱えますが、特定のシナリオではJPEGが勝つこともできます。

エンコーディング時間の違いも測定しましたが、これはスケールで重要になります。当社の本番サーバー（AWS c5.2xlargeインスタンス）では、2000x2000pxの画像をWebPにエンコードするのに約340msかかるのに対し、JPEGは同等の品質設定で180msです。1日あたり50,000件のユーザーアップロードを処理する際、この違いは実際のインフラコストに累積します。WebPに切り替えたとき、エンコーディング能力を40%増やさなければならず、これは帯域幅の節約を部分的に相殺しました。

ブラウザサポート：会議室の象

WebPに関するあらゆる技術的な議論は最終的にこの壁にぶつかります：ブラウザサポート。そして、この会話はここから面白くなります。というのも、過去2年間で状況が劇的に変化しました。私の最新の監査（2024年1月）によると、WebPは50以上のクライアントサイトにおける分析データに基づき、97.3%のグローバルブラウザサポートを享受しています。これは18ヶ月前の91.2%からの上昇です。

"WebPによる26%の平均ファイルサイズ削減は印象的に聞こえますが、それがコンテンツタイプによって12%から34%まで変動することを考慮すると、そのばらつきが生産予算を破壊するものです。"

しかし、残りの2.7%は実際のユーザーであり、実際のお金を持っています。一つの高級商品のクライアントでは、そのサポートされないセグメントが収益の4.1%を占めていました—古い企業ブラウザや特定のモバイルデバイスを使用する高価値顧客です。私たちは彼らを無視するわけにはいきませんでした。これが、私が構築したすべての生産WebP実装がフォールバック戦略を含む理由です。

HTML5のpicture要素は最もクリーンな解決策を提供します。サポートされているブラウザにはWebPを提供し、それ以外にはJPEGを提供します。構文は次のようになります：画像をpictureタグで囲み、最初のソースとしてWebPを指定し、imgタグでJPEGのフォールバックを提供します。ブラウザは自動的にサポートされている最初のフォーマットを選択します。このアプローチは最小限のオーバーヘッドを追加し（通常は2-3msの解析時間）、普遍的な互換性を確保します。

しかし、これによりストレージ要件が倍増し、画像処理パイプラインが複雑化します。すべての画像の2つのバージョンを生成、保存、配信することになります。数百万のアセットを持つクライアントにとって、これは重要なインフラの変更を意味しました。一人の小売クライアントは、未使用のバリアントを削除するインテリジェントクリーンアップポリシーを実装する前に、S3ストレージコストが89%増加したのを目の当たりにしました。

CDNキャッシュに関する考慮事項もあります。デュアルフォーマットでは、キャッシュ効率が分割される可能性があります。もし95%のユーザーがWebPをリクエストし、5%のユーザーがJPEGをリクエストする場合、各画像のために二つの別個のキャッシュエントリを維持することになります。これによりキャッシュヒット率が低下し、オリジンサーバーへの負荷が増加します。私はこの問題によって、トラフィックスパイク時にキャッシュが両方のフォーマットに対して効率的に温まらなかったため、予期しないパフォーマンスの低下が引き起こされるのを見てきました。

品質の認識：ユーザーが実際に気づくこと

私はこれまでに23件の異なるユーザー認識テストを行ってきましたが、その結果は一貫して人々を驚かせます。ユーザーが同等のファイルサイズでWebPとJPEG画像を比較するブラインドA/Bテストでは、67%の参加者がどのフォーマットがどれかを特定できませんでした。さらに重要なのは、71%がeコマース目的で両方のフォーマットを「許容できる品質」と評価したことです。

しかし、ここにニュアンスがあります：非常に高い圧縮率では、アーティファクトが目に見えて異なります。JPEGはユーザーが「ピクセル化」または「ぼやけている」と表現する8x8ピクセルのブロック状アーティファクトを生成します。WebPは「ぼやけた」または「ろうそくのような」と表現される異なるアーティファクトを生成し、ファイルサイズが小さくても一部のユーザーにはより不快に感じられることもあります。ある記憶に残るテストでは、ユーザーはポートレート写真に対してより圧縮されたWebPよりも少し大きなJPEGを好み、顔が「より自然に見える」と述べました。

私が広範なテストを通じて見つけた品質のスイートスポット：写真コンテンツについてはWebPの品質設定を75-85（0-100スケールで）に設定することを目指します。これにより、通常、JPEGの品質85-90で25-30%小さいファイルが生成され、ほとんどのユーザーには品質の違いは感じられません。テキストを含むグラフィックコンテンツでは、鋭いエッジの周りのぼやけた効果を避けるために、WebPの品質を88-92に引き上げます。

色精度は特定の業種にとって重要な考慮事項でもあります。ファッションや化粧品のクライアントは色の忠実度にこだわります—オンラインで見たリップスティックが店頭で少し異なると、返品やクレームが発生します。私のテストでは、両方のフォーマットは適切に構成されていれば色空間を十分に扱えますが、WebPの非可逆圧縮は、非常に彩度の高い部分に微妙な色の変化を導入する可能性があります。色の精度がビジネス上重要なヒーロー画像や製品ショットについては、視覚的なQAを常に推奨しています。

モバイルパフォーマンスの話が複雑になる

モバイルデバイスは私のeコマースクライアントのトラフィックの73%を占めているため、モバイルパフォーマンスが最適化の決定に大きく影響します。WebPはここでは明白な勝者であるべきです—小さいファイルはセルラー接続での読み込みが速くなります。一般的には、これは真実です。4G接続では、WebP画像は私のフィールドテストで平均して18-24%速く読み込まれることが分かりました。