Content-Encodingは、HTTPレスポンスのボディに適用された圧縮方式や符号化を表すヘッダで、Content-Encoding: gzipやContent-Encoding: brのような形で送られます。クライアントはリクエストでAccept-Encodingヘッダに対応可能な圧縮方式を列挙し、サーバはそのうち最適なものを選んで圧縮したボディを返します。現代の主要な圧縮方式はgzip（1990年代から普及）、deflate（gzipに近い旧式）、br（Brotli、2015年Google発）、zstd（Zstandard、2016年Meta発）の4つで、テキスト系コンテンツのサイズを50〜90%削減する効果があり、Web全体の帯域節約とパフォーマンス向上に大きく寄与しています。
この記事の目次
- 主要4方式の特徴
- 圧縮の歴史的経緯
- 実装現場での扱い
- Transfer-Encoding・圧縮なしとの比較
- まとめ
主要4方式の特徴
gzipはDEFLATEアルゴリズム（LZ77＋ハフマン符号）にチェックサムとメタデータを足したフォーマットで、RFC 1952（1996年）として標準化されました。30年近くにわたって使われてきた最も枯れた方式で、HTTP対応ブラウザ・サーバ・CDNがほぼ確実に対応しているため、互換性で迷ったらgzipを選んでおけば確実です。deflateはgzipから一部のヘッダを省いた形式で、現代ではほぼgzipと同義ですが、実装互換の都合で扱いが微妙な歴史的経緯があり、新規採用は推奨されません。
Brotli（圧縮方式br）はGoogleが2015年に公開した方式で、RFC 7932として標準化されています。辞書を内蔵することでHTMLや一般的なテキストパターンの圧縮率がgzipより15〜25%高くなり、特に静的アセットの配信で広く採用されています。Chrome・Firefox・Safari・Edgeなど主要ブラウザはbrを標準でサポートしており、HTTPS接続のときに優先的に使われます。Zstandard（zstd）はFacebook（現Meta）が2016年に公開した方式で、RFC 8478として標準化されました。圧縮率はbrとほぼ同等ですが、圧縮・解凍速度が大幅に高速で、特に動的コンテンツの圧縮で力を発揮し、Chrome 123以降でWebでも使われ始めています。
圧縮の歴史的経緯
Web上での圧縮は、1996年5月のgzip形式の標準化（RFC 1952）と1996年のHTTP/1.0（RFC 1945）でのContent-Encodingヘッダ定義から本格的に始まりました。1999年のRFC 2616（HTTP/1.1）でgzipやdeflateの利用が標準化され、Webサーバ・ブラウザ双方で広くサポートされるようになりました。テキスト系コンテンツの増大に伴い、帯域節約とページロード時間短縮の効果が顕著になり、現代Webパフォーマンスの基本ツールとして定着しました。
2015年7月にRFC 7932としてBrotliが標準化され、その後数年でChrome・Firefox・Safari・Edgeの主要ブラウザがHTTPS接続で対応しました。Cloudflare・Fastly・AWS CloudFrontなど主要CDNもBrotli対応を進め、現代の静的アセット配信では「brがあればbr、なければgzip」という選択が当たり前になっています。2016年8月にFacebookがZstandardを公開し、2018年10月にRFC 8478として標準化、2024年3月にはChrome 123からWebでの利用が解禁され、徐々に普及が進んでいます。コンテンツ配信の進化に合わせて、より高性能な圧縮方式が継続的に追加されてきた歴史です。
実装現場での扱い
Content-Encodingで圧縮するのは、HTML・CSS・JavaScript・JSON・XML・SVGなどテキスト系のコンテンツが中心です。これらは50〜90%程度の圧縮率が得られ、効果が極めて大きい一方、JPEG・PNG・WebP・MP4などの既に圧縮済みのバイナリ形式を再圧縮しても効果がないどころか、CPU時間とサイズの両方で逆効果になります。Nginx・ApacheなどのWebサーバでは、gzipやBrotliの対象MIMEタイプを設定でフィルタするのが標準です。
静的アセット配信では、ビルド時に.gzや.brファイルを事前に生成しておき、リクエスト時にCPU負荷ゼロでそのまま返す「事前圧縮配信」がベストプラクティスです。Webpack・Vite・Rollupなど主要バンドラーはこの方式を標準でサポートしています。Accept-Encodingにはq値（quality value）で優先順位を付けられ、Accept-Encoding: br;q=1.0, gzip;q=0.8のように指定して優先度を伝えます。また、Content-Encodingを使う際にはVary: Accept-Encodingヘッダの設定が重要で、これがないとCDNが「圧縮版を非対応クライアントに返す」事故が起こり得ます。Vary設定はキャッシュ整合性を保つ必須要素です。
Transfer-Encoding・圧縮なしとの比較
Transfer-Encodingは「ホップ単位（中継機間）の転送形式」を表すヘッダで、Content-Encodingが「ボディそのものの永続的な符号化」を表すのと役割が異なります。Transfer-Encodingで指定できるのはchunked転送（ボディを分割送信する形式）が中心で、HTTP/1.1での動的レスポンスストリーミングに使われます。両者は組み合わせ可能で、Content-Encoding: gzipとTransfer-Encoding: chunkedを同時に使うこともよくあります。
圧縮を使わない選択肢もあり、CPU負荷が極めて高くなる超高頻度APIや、既に小さいレスポンス（数十バイトの単純なヘルスチェック等）では圧縮しない方が合理的です。TLSレベルの圧縮（TLS Compression）はかつて使われましたが、CRIME攻撃（2012年）などのセキュリティ脆弱性が見つかったため非推奨となり、現代の主要TLS実装では無効化されています。そのため現代Webにおける圧縮はHTTPレイヤーのContent-Encoding一本に絞られており、gzip/br/zstdをAccept-Encodingで合意して使い分けるのが標準的なアプローチです。
まとめ
Content-EncodingはHTTPボディの圧縮方式を示すヘッダで、RFC 9110（2022年）で定義されています。gzip（RFC 1952、1996年）、Brotli（RFC 7932、2015年）、Zstandard（RFC 8478、2018年）が主要方式で、テキスト系コンテンツのサイズを大幅に削減できます。Accept-Encodingで合意・Vary: Accept-Encodingでキャッシュ整合性確保・事前圧縮配信といった運用パターンが定着し、現代Webパフォーマンスを支える基盤ヘッダとして機能しています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント