なぜ「たかが圧縮」でサイトの命運が変わるのか？ ― HTTP圧縮ネゴシエーションの深淵
ネットワークエンジニアとして現場を渡り歩いていると、いまだに「通信速度のボトルネックは回線品質だ」と決めつけている若手に出会うことがある。だが、現代のWebインフラにおいて、遅延の最大の要因は「詰め込める情報を、どれだけ贅肉を削ぎ落として送れるか」という、究極の最適化にある。
今回は、HTTP通信における「圧縮ネゴシエーション」、つまり `Accept-Encoding` と `Content-Encoding` の駆け引きについて、実務の現場で必ず知っておくべき勘所を解説しよう。
—
1. 圧縮のダンス：ネゴシエーションの仕組み
通信は常に「希望」と「結果」のやり取りだ。クライアントが「私はこれなら解凍できるよ」と伝え、サーバーが「じゃあ、これで送るね」と応える。このシンプルな対話が、巨大なJSONやHTMLを軽量化し、ユーザーの体感速度を劇的に変える。
クライアントからの意思表示：`Accept-Encoding`
ブラウザやAPIクライアントは、リクエストヘッダーにこのフィールドを含めることで、対応可能な圧縮アルゴリズムを提示する。
GET /api/v1/resource HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br
- gzip: DEFLATEアルゴリズムに基づいた、最も一般的で枯れた圧縮形式。
- deflate: zlibライブラリなどで使われる形式だが、gzipと混同される歴史的経緯があるため、現在ではgzipが推奨される。
- br (Brotli): Googleが開発した現代の最適解。gzipより圧縮率が高く、静的コンテンツ配信には欠かせない。
サーバーからの回答：`Content-Encoding`
サーバーはこれを受け取り、選んだアルゴリズムを `Content-Encoding` ヘッダーでクライアントに通知する。
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
[ここに圧縮されたバイナリデータが続く…]
ここでのポイントは、「サーバーが解凍できない形式を無理に押し付けてはいけない」ということだ。ネゴシエーションを無視した強引な圧縮は、クライアント側で「解凍できない」という致命的なエラー（文字化けやパース失敗）を引き起こす。
—
2. 実務で遭遇する「落とし穴」を回避する
設定ファイルをいじっていて、「なぜか圧縮が効かない」「Chromeのデベロッパーツールでエラーが出る」という事態に陥ったことはないだろうか。よくある原因を挙げておく。
ケースA：プロキシサーバーによる書き換え
中間にあるロードバランサーやCDNが、`Accept-Encoding` を勝手に書き換えてしまうことがある。特に古いプロキシは `br` を解釈できず、クライアントの意図を無視して `gzip` に強制変換したり、最悪の場合は圧縮ヘッダーを剥ぎ取ることがある。
ケースB：MIMEタイプの不一致
NginxやApacheの設定で「テキスト系しか圧縮しない」というルールを忘れていると、JSON APIのレスポンスが非圧縮のまま垂れ流されることになる。
Nginxの設定例（gzip.conf）:
圧縮を有効化
gzip on;
圧縮レベル（1〜9。6がコスパ最強）
gzip_comp_level 6;
圧縮対象のMIMEタイプ（application/jsonを忘れがち！）
gzip_types text/plain text/css application/json application/javascript text/xml;
プロキシ経由でも圧縮を適用
gzip_proxied any;
—
3. 実践：クライアント側でのデバッグと検証
開発現場で「圧縮が正しく機能しているか？」を確認するのはエンジニアの基本動作だ。curlやFetch APIを使って、ヘッドレスに検証しよう。
curlでヘッダーを叩く（基本中の基本）
`-I` オプションでヘッダーのみを確認するのが定石だが、圧縮を確認するなら内容をバイナリとして取得する必要がある。
圧縮されたデータを取得し、サイズを比較する
curl -H “Accept-Encoding: gzip” -I https://api.example.com/data
戻り値に Content-Encoding: gzip が含まれているか、ここを凝視する
PythonでAPIの挙動をテストする
自動テストに組み込むなら、`requests`ライブラリを使うのが最も確実だ。
import requests
url = “https://api.example.com/data”
headers = {“Accept-Encoding”: “gzip”}
response = requests.get(url, headers=headers)
圧縮されているかチェック
if response.headers.get(“Content-Encoding”) == “gzip”:
print(“成功: 通信は圧縮されています”)
else:
print(“警告: 圧縮が適用されていません”)
—
最後に：シニアからのアドバイス
圧縮は「万能薬」ではない。極端に小さいデータ（数バイトのレスポンスなど）を圧縮しようとすると、圧縮のオーバーヘッドでかえってデータサイズが肥大化することすらある。また、CPUリソースが逼迫しているサーバーでは、圧縮処理そのものがレスポンス遅延の原因になる場合もある。
「計測できないものは改善できない」。
まずはブラウザのネットワークタブを開き、転送サイズ（Transfer size）と実際のサイズ（Resource size）を比較してみることだ。この小さな差分を意識し続けられるエンジニアこそが、真にスケーラブルなインフラを構築できる。
パケットは嘘をつかない。君の書いた一行のヘッダーが、世界中のユーザーの通信を、ほんの数ミリ秒だけ速くする。その積み重ねが、Webの未来を作るんだ。
コメント