コンテンツにスキップ 
選択された 圧縮レベル GzipとBrotliはウェブサーバーのCPU負荷を変化させ、どのようにホスティングパフォーマンスに測定可能な影響を与えるか。明確な設定で サーバー負荷 ローディング時間に妥協することなく、目立つ。.
中心点
- CPUコスト ファイルサイズの節約よりも、レベルが高いほど速く増加する。.
- Gzip 4-6 は、動的コンテンツにとって最善の妥協点であることが多い。.
- ブレッドスティック より小さなファイルを提供するが、高レベルではより多くのCPUを必要とする。.
- 前圧縮 は、計算負荷をリクエスト時間からビルドプロセスにシフトする。.
- モニタリング 高価な圧縮パスがすぐに見えるようになる。.
サーバーでの圧縮にCPUコストがかかる理由
HTTP圧縮は、テキスト資産を50～80 %削減することがよくありますが、1キロバイト節約するごとに、次のようなものが追加されます。 計算作業. .最近のブラウザは楽に解凍できるが、ボトルネックはサーバーで、リクエストごとに圧縮する。Brotliはより大きな検索ウィンドウと辞書を使用し、より高いレベルではより大きなスペースを必要とします。 CPU時間 バインドされる。Gzipはより単純に動作するが、高レベルでは驚くほど高価でもある。接続と HTTP圧縮の設定 ピーク負荷を軽減し、応答時間を改善する。.
圧縮しないもの：バイナリ形式と最小サイズ
すべての答えが圧縮の恩恵を受けるわけではない。多くのバイナリ形式は、圧縮することがすでに効率的であるか、あるいはさらに悪いのですが、CPUのオーバーヘッドは依然として発生します。以下のカテゴリーを特に除外し、圧縮が有効になる最小サイズを設定すると、計算時間を大幅に節約できます。.
- すでに圧縮されたメディアJPEG/JPG、PNG、WebP、AVIF、MP4/WEBM、MP3/AAC、PDF（多くの場合）、ZIP/GZ/BR。.
- 小さな答えヘッダーオーバーヘッドとレイテンシーが支配的であるため、〜1〜2KB以下の圧縮はほとんど意味がない。.
- バイナリダウンロードインストーラー、アーカイブ、データブロブ - ここで圧縮を試みても、CPUコストがかかるだけだ。.
そのため、MIMEタイプ（テキスト、JSON、JavaScript、CSS、SVG、XML）の明確なポジティブリストを定義し、MIMEタイプ（テキスト、JSON、JavaScript、CSS、SVG、XML）に対して 最小サイズ. .この2つのレバーは無駄な作業を避け、負荷がかかったときのスループットを安定させる。.
MIMEフィルターとしきい値を適切に設定する
細かく選択するのが現実的だ：私は一貫してテキスト形式を圧縮しているが、非常に動的なエンドポイント（API-JSONなど）と、あまり頻繁に変更されないページ（パーソナライズ度の低いHTMLなど）を区別している。さらに、MIMEタイプごとに 圧縮する最小の長さ を使うことで、短いレスポンスを圧縮せずに残すことができます。この混合により、小さな204/304レスポンスやミニJSONが不必要に圧縮パイプラインを通過するのを防ぐことができます。.
Gzip：ミディアムレベルは、サイズとCPUのベストミックスを提供します。
Gzipは1から9までの9つのレベルを提供し、CPUカーブはレベル6から不釣り合いに増加する。 貯蓄 はファイルサイズとともにわずかに増加するだけである。例えば1MB程度のJavaScriptファイルの場合、圧縮時間はおおよそ50ミリ秒（レベル3）、300ミリ秒（レベル9）程度です。アクセス頻度の高いセットアップでは、この効果は毎秒リクエストの何倍にもなり CPUリソース. .そのため、Gzip 4-6はダイナミックなレスポンスに役立つが、7-9は通常、小さなファイルをいくつか使うだけで、CPUはもっと使う。過剰なGzipレベルを下げると、TTFBが著しく減少する。.
次の表は、私が自信を持って適切なレベルを選択できるように、典型的な傾向をまとめたものである。 ホスティング・パフォーマンス 安定している。.
| アルゴリズム | レベル | サイズ縮小（typ.） | CPU時間（相対） | 代表的な使用例 |
|---|---|---|---|---|
| ジージップ | 1-3 | 50-65 % | 低い | 非常にダイナミックなコンテンツ |
| ジージップ | 4-6 | 60-75 % | ミディアム | 動的応答の標準 |
| ジージップ | 7-9 | 62-77 % | 高い | 特殊なケース。 |
| ブレッドスティック | 3-5 | 65-82 % | ミディアムハイ | サイズを重視したダイナミックなコンテンツ |
| ブレッドスティック | 9-11 | 68-85 % | 非常に高い | 圧縮済みの静的アセット |
ブロトリ：貯蓄率は高いが、高レベルではCPUが高い
Brotli は通常、テキストファイルを Gzip よりも少し小さく圧縮するが、レベルが増えるごとに 計算時間 オン。中程度のレベルでも非常に優れたレートを生成するが、高いレベルではその場での圧縮がすぐに遅くなる。そのため、ダイナミックコンテンツの場合は、ファイルサイズと圧縮率の比率を安定させるために、レベル3～5を使用しています。 レイテンシー を保持する。私はレベル9-11のビルドで静的ファイルを圧縮している。コンパクトな形で違いを見たい場合は、以下を参照してほしい。 Brotli vs Gzip を大々的に並べた。.
収穫の減少：レベルが上がるほど、1CPU秒あたりの利益は少なくなる
圧縮レベルを1から5に上げると、すぐにかなり小さいファイルが得られるが、この範囲からCPU追加1秒あたりの収量は薄くなる。Gzip 5から9へ、またはBrotli 5から9へのジャンプは、しばしば数パーセントのポイントしかもたらさないが、顕著に消耗する。 プロセッサー時間. .生産的な環境では、これはTTFBとスループットに影響を与える。そのため、私はまずプロファイラーでホットパスに注意を払い、ハードウェアを買い足す前に高価な圧縮レベルを下げる。こうして私は スケーラビリティ そしてコストを抑制する。.
静的資産のプレコンプレッション：一度の計算で永続的に効果を発揮
CSS、JS、SVG、ウェブフォントはめったに変更されないので、デプロイ前に高いBrotliレベルで圧縮します。配信では、その場で圧縮せずに.brまたは.gzファイルを使用します。 CPU を消費します。CDNや最新のウェブサーバーは、アクセプトエンコーディングに基づいて正しいタイプを認識し、適切なバリアントを直接配信する。これにより、計算時間をビルドにシフトし、負荷のピークを最小限に抑え、レスポンスタイムを安定させることができる。その結果、常に ロード時間 高負荷時でも。.
高いレベルに意味がある場合
滅多に更新されない、広範囲にリーチする大きな静的アセット（フレームワークバンドルなど）、極めて長い時間キャッシュされるダウンロード、地理的に分散した多くのユーザーがアクセスするコンテンツなどだ。1回限りのビルドの手間はほとんどかかりませんが、追加で節約できるパーセンテージは、帯域幅とCDNのコストを大幅に削減します。前提条件は、これらのファイルが ない はその場で圧縮され、サーバーは事前に生成された .br/.gz バリアントを直接配信します。.
ダイナミックな対応のためのカスタマイズされたレベル
HTML、API-JSON、パーソナライズド・コンテンツの場合、私の設定は圧縮率と圧縮率の比率を安定させることを目指している。 CPU負荷. .私は通常、Gzipをレベル4-6に設定し、Brotliを3-5に保つことで、レイテンシーを予測しやすくしている。プロファイラーが圧縮が優勢であることを示すとすぐに、私はレベルを下げ、TTFBへの影響をチェックする。多くの場合、ページサイズはほとんど変わらない。 応答時間 は目に見えて減少する。この単純なレバーは、インスタンスサイズをアップグレードするよりも役立つことが多い。.
ストリーミングとスモールアンサー：フラッシュ、チャンキング、SSE
ストリーム応答（サーバー送信イベント、長いポーリング応答、HTMLの増分）については、圧縮を考慮に入れています。 バッファ を使用する。あまりにアグレッシブなバッファリングは最初のバイトを遅らせ、あまりに頻繁なフラッシュは圧縮を非効率にする。したがって、サイズよりもレイテンシーが重要な純粋なイベントストリームでは、適度なバッファサイズを選び、圧縮を無効にする。非常に 小解答 ヘッダーとコンテキストの初期化にかかるオーバーヘッドは、メリットよりもコストがかかる。.
GzipとBrotliの組み合わせ：最大限の互換性
私はモダンブラウザ用にBrotliを有効にし、古いクライアントにも確実にサービスを提供できるよう、フォールバックとしてGzipを残している。ネゴシエーションはacceptエンコーディングで行われ、サーバーは可用性に応じて圧縮ファイルを配信する。このようにして、新しいブラウザーと一定の 互換性 を古い環境に適用します。キャッシュ制御とVaryヘッダーも正しく設定すれば、その後のリクエストでの計算作業を避けることができる。この組み合わせにより、非常に 効率的な CPU負荷の低い配信。.
キャッシュとバリ：304、ETag、二重圧縮を避ける
キャッシュが正しく機能するように、私は Vary: Accept-Encoding-ヘッダを一貫させて、圧縮されたものと圧縮されていないものが別々に保存されるようにします。そうしないと、GzipをサポートしていないクライアントにキャッシュがGzipファイルを配信する危険性があります。また、304 レスポンス（Not Modified）が圧縮のトリガーにならないこともチェックします。よくあるエラーは ダブルコンプレッサーアップストリームはすでに圧縮された状態で配信され、エッジサーバーで再度圧縮されます。コンテンツのエンコーディングを制御し、クリーンなルールで重複作業を防ぎます。ETagsとハッシュ付きのファイル名（例：app.abc123.js）はキャッシュの一貫性を促進し、事前圧縮を特に効果的にします。.
多数のプロジェクトが存在するホスティング環境でのチューニング
マルチテナントのセットアップでは、小さな非効率が積み重なって大きな非効率になる。 CPUガズラー. .私は測定から始める：圧縮ルーチンのCPU時間の割合、TTFB、スループット、キャッシュヒットレート。Flamegraphは、GzipやBrotliの消費量が多すぎることをすぐに明らかにします。その後、段階的にレベルを調整し、効果をチェックし、負荷テストで結果を検証する。このサイクルを定期的に繰り返すことで、長期的な 安定性 を保証する。.
測定、テスト、再調整：実際的な手順
まず現状と目標値を文書化し、それから高すぎる圧縮レベルを徐々に下げていく。一般的には、Gzip 7-9を5-6に、Brotli 8-9を4-5に切り替える。次に、TTFB、レイテンシP95、および圧縮率を比較する。 スループット 変更前と変更後。メトリクスの結果、サイズの減少が見られなければ、より好ましいレベルのままにしておく。このルーチンは、システムを高速に保ち スケーラブル.
安全面BREACHリスクを現実的に最小化する
コンプレッションと安全性はリンクしている：安全性は 秘密のトークン (CSRFやセッションの断片など)が圧縮されたレスポンスの中でユーザが管理するデータと一緒に混ざっていると、サイズの変化から結論を導き出す攻撃が理論的には可能です。実際には、機密性の高いコンテンツをそのようなレスポンスに含めないようにしたり、特定のエンドポイントで圧縮を無効にしたり、トークンを切り離したり（個別のクッキー、HTMLへの反映なし）することで、これを回避している。特にクリティカルなパスの場合は、そのリスクを受け入れるよりも、オンザフライ圧縮を使わないほうがいい。.
コストと規模拡大への影響
リクエストあたりのCPU時間が少なくなることで、インスタンスあたりのリクエスト数が増え、ピーク時の余裕が生まれます。これにより、ユーロの運用コストとホスティングコストが削減されます。 ユーザー・エクスペリエンス システムを危険にさらす。同時に、負荷がかかったときにタイムアウトが発生するリスクも減る。私は適切な場所に予算を節約し、キャッシュやより高速なストレージシステムに特別に投資しています。こうすることで、プラットフォームを経済的に保ち 反応性が高い.
HTTP/2/HTTP/3とTLS：分類
HTTP/2とHTTP/3では、ヘッダー圧縮と多重化の恩恵を受けているが、これは本文圧縮の代わりにはならない。特に多くの小さなファイルでは、接続の分割や優先順位付けによってオーバーヘッドは減るが、テキストコンテンツが支配的な要因であることに変わりはない。暗号化は圧縮の後に行われるからだ。したがって、私は引き続き ボディサイズ, 並列性と圧縮レベルを考慮し、新しいプロトコルは代替ではなく補完として使用する。.
ホスティングの選択と設定ハードウェア、サーバー、フォーマット
強力なシングルコア・パフォーマンス、最新のウェブ・サーバー・ビルド、Gzip/Brotliの賢明なデフォルト設定により、チューニングが容易になる。きれいな事前設定を備えたプロバイダーは、時間を節約し、アプリのロジックに余裕を持たせてくれる。テキストアセットに加えて、私はメディアフォーマットにも注意を払い、最新の画像パスを考慮します。 WebP vs AVIF. .こうすることで、全体的なトラフィックを削減し、また、震災の影響を軽減することができる。 CPU 間接的に、より少ないバイトが回線上に送信されるからです。強力なコアによるホスティングは、要求の厳しいプロジェクトに必要なパフォーマンスを提供します。 パフォーマンス, 圧縮、キャッシュ、アプリの負荷のバランスが保たれるように。.
エラーパターンとトラブルシューティングの実際
簡単なチェックで典型的な問題はすぐにわかる。サーバーは コンテンツのエンコーディングgzip/brを2回？それなら通常は二重圧縮です。声 可変-ヘッダーとキャッシュ・キーがあれば、プロキシは圧縮されたレスポンスを互換性のないクライアントに転送することができる。奇妙なTTFBピークの場合、私は 最小サイズ が低すぎるし、小さなレスポンスが圧縮されすぎている。CPUのプロファイルも見る：Flamegraphsで圧縮が支配的な場合は、レベルを下げるか、圧縮前の作業をアウトソースします。また エラーページ 圧縮は多くの場合不要であり、例外的な状況で貴重なCPUをブロックする。.
アクション・プラン
テキストベースのアセットにはすべて圧縮を有効にし、ダイナミックコンテンツにはGzip 4-6とBrotli 3-5を使用しています。 CPU負荷 とファイル・サイズ。私は、リクエスト時間が不必要な計算作業から解放されるように、高いBrotliレベルでビルド内の静的ファイルを圧縮します。その後、TTFB、レイテンシP95、CPUシェアを測定し、圧縮に時間がかかりすぎる場合はレベルを下げます。互換性を最大にするために、私は最新のクライアントにはBrotliを、信頼できる圧縮にはGzipを使う。 フォールバック. .このプロセスにより、ファイルサイズが小さくなり、レスポンスタイムが安定し、サーバーインスタンスあたりの操作に余裕が生まれる。.
