Web圧縮は gzip / Brotli から zstd へ進むのか ― Content-Encoding: zstd とHTTP圧縮の現在地

HTTP のレスポンス圧縮は、クライアントとサーバーの交渉です。ブラウザはリクエストで Accept-Encoding を送り、自分が展開できる content coding を並べます。サーバーはその中から使える方式を選び、レスポンスの Content-Encoding に書きます。

GET /app.js HTTP/2
Accept-Encoding: gzip, deflate, br, zstd

HTTP/2 200
Content-Type: application/javascript
Content-Encoding: br

重要なのは、Accept-Encoding に zstd があっても、サーバーが必ず zstd を返すわけではないことです。サーバー側の対応、ファイル種別、CPU負荷、キャッシュ戦略、CDN設定によって gzip や Brotli、あるいは無圧縮が選ばれます。

3 つの方式は「どれが絶対に上」ではなく、得意な場所が違います。

gzip は DEFLATE 系の古典的な圧縮で、互換性の面では今でも強い。Brotli は Web 配信で広く使われ、特に事前圧縮した静的アセットで有利です。zstd はデータ基盤、パッケージ配布、ストレージ圧縮などで実績を重ね、HTTP content coding として Web 側にも入ってきました。

Zstandard は Meta/Facebook 由来の可逆圧縮方式で、RFC 8878 として形式と application/zstd メディアタイプが定義されています。さらに HTTP の content coding としての zstd は IANA の HTTP Content Coding Registry に登録されています。

2024 年には RFC 9659 が公開され、HTTP の zstd content coding で使う Window_Size について、相互運用性のための 8MB 制限が明確化されました。これは「zstd がまだ曖昧だから危ない」という話ではなく、ブラウザやユーザーエージェントで安全に扱うため、Web利用時の制約をそろえる動きです。

したがって、技術的な評価としては「zstd は確立済み。ただし HTTP 配信の既定選択肢としては、ブラウザ・CDN・サーバーの採用状況を見ながら広がっている」と見るのが正確です。

zstd は、LZ77 系の辞書参照と高速なエントロピー符号化を組み合わせ、圧縮レベルを広く調整できる設計です。圧縮率を上げたいときは重めのレベルを使い、速度を優先したいときは軽いレベルを使えます。特に展開速度が速いことが、配信・ログ・パッケージ・ストレージの世界で評価されてきました。

Web 配信では、ユーザーのブラウザで展開する時間も重要です。圧縮率だけを追ってファイルサイズを少し小さくしても、展開が遅ければ体感は悪くなります。zstd は「小ささ」と「展開の速さ」のバランスがよく、動的レスポンスやAPIレスポンスの圧縮候補として魅力があります。

ただし、圧縮方式の優劣はコンテンツで変わります。HTML、CSS、JavaScript、JSON、ログのようなテキストは圧縮効果が出やすい一方、JPEG、PNG、AVIF、WebP、ZIP、PDF など、すでに内部で圧縮済みの形式は再圧縮してもほとんど小さくならず、むしろサイズやCPU負荷が増えることがあります。

zstd が有望でも、Brotli を今すぐ置き換えるとは限りません。Web の静的アセットでは、ビルド時やCDN側で Brotli を高めの品質で事前圧縮し、配信時にはCPUを使わずに返す運用がすでに普及しています。

一方、zstd は展開速度や動的圧縮での扱いやすさが魅力です。たとえば、キャッシュ前提の静的 JS/CSS は Brotli、頻繁に変わる JSON API やログ系レスポンスは zstd、古いクライアント向けには gzip、というように使い分ける未来が自然です。

圧縮方式は宗教戦争にしないほうがよい分野です。実際のレスポンス、CPU負荷、キャッシュヒット率、利用者のブラウザ比率で決めるべきです。

よくある混乱が、Content-Type と Content-Encoding の混同です。Content-Type: application/json は中身が JSON であることを表します。Content-Encoding: zstd は、その JSON 表現が zstd で圧縮されていることを表します。

Content-Type: application/json
Content-Encoding: zstd

ブラウザやHTTPクライアントは、まず Content-Encoding を見て展開し、その後に Content-Type に従って JSON として扱います。つまり .zst ファイルをダウンロードする話と、HTTPレスポンスが zstd で圧縮されている話は、関係はあるものの同じではありません。

HTTP圧縮を運用するときに重要なのがキャッシュです。同じ URL でも、あるクライアントには br、別のクライアントには gzip、新しいクライアントには zstd を返す可能性があります。そのため、キャッシュは Accept-Encoding の違いを区別する必要があります。

Vary: Accept-Encoding

CDNやリバースプロキシがこの違いを正しく扱わないと、zstd に対応していないクライアントへ zstd 圧縮済みレスポンスを返す、といった事故が起こります。多くのCDNは圧縮方式を抽象化してくれますが、自前でNginxやアプリケーションサーバーを設定する場合は、キャッシュキーと Vary を必ず確認します。

2026年時点の実務判断としては、まず gzip はフォールバックとして残し、Brotli は静的アセットで使い、zstd は対応クライアントと配信基盤を見ながら段階導入するのが堅実です。

• HTML / CSS / JS: gzip + Brotli を基本に、zstd 対応CDNなら追加検討
• JSON API: 動的圧縮のCPUとレスポンスサイズを測って zstd を検討
• 画像・動画・ZIP: 原則として再圧縮しない
• 古いクライアント: gzip を残す
• キャッシュ配信: Vary: Accept-Encoding とキャッシュキーを確認

「zstd対応」と書かれたサービスでも、静的ファイルのみ、特定プランのみ、オリジンからの圧縮済みファイルのみ、という場合があります。仕様上可能かどうかと、自分の配信経路で有効になるかは別問題です。

zstd は、圧縮技術としてはすでに確立しています。RFC 8878 で形式が定義され、HTTP content coding として IANA に登録され、RFC 9659 でHTTP利用時のウィンドウサイズ制約も明確化されました。ブラウザの Accept-Encoding に zstd が入る流れも、実験ではなく現実のWeb配信に向けた動きです。

ただし、gzip と Brotli が不要になったわけではありません。2026年時点では、gzip は互換性の最後の安全網、Brotli は静的Webアセットの本命、zstd は高速展開と動的圧縮で伸びる次の選択肢、という整理が現実的です。

導入するなら、理論値ではなく自分のサイトの HTML、CSS、JavaScript、JSON API を使って測ること。圧縮後サイズ、CPU時間、キャッシュヒット率、ブラウザ比率を並べて見るのが、いちばん間違いにくい判断です。