Pleskウェブサーバ

HTTP圧縮のしきい値：ウェブホスティングのための最適な設定

HTTP圧縮のしきい値は、サーバーがコンテンツを圧縮するサイズを決定するため、TTFB、CPU負荷、帯域幅を直接制御します。このガイドでは、動的圧縮と静的圧縮を明確に分けるだけでなく、高速配信のための具体的なしきい値、レベル、ヘッダー設定を紹介します。圧縮.

中心点

最初に最も重要な調整をまとめておくので、的を絞って始めることができ、不必要なCPUサイクルの浪費を避けることができる。私は、ブラウザ、プロキシ、CDNが正しく連携するように、明確なしきい値、適切なレベル、クリーンなヘッダーに依存しています。ダイナミック・レスポンスとビルド・アセットを区別し、ホップあたりの圧縮率を厳密に管理します。適度なレベルのランタイム圧縮でTTFBを最小限に抑え、あらかじめ圧縮されたファイルから最大限のレートを引き出します。定期的にメトリクスをチェックし、実際の負荷、ファイルミックス、レイテンシーに合わせて制限を調整することで、お客様のセットアップが明らかに効率的になるようにします。 より速く の意思表示をします。

しきい値 512～1024B、標準1024B
ブレッドスティック 3-4ダイナミック、9-11スタティック
ジージップ フォールバックとして5-6
マイム テキストリソースのみ
可変およびエンコーディングごとのETag

HTTP圧縮しきい値とは？

閾値は、レスポンスが圧縮されるサイズを決定し、ヘッダーのオーバーヘッドが小さなファイルを人為的に膨らませるのを防ぐ。 損益分岐点-考慮事項非常に小さなレスポンスでは、コンテンツエンコーディングはペイロードを増加させ、同時にCPUコストを増加させます。そのため、私は通常、下限を1024バイトに設定し、小さなレスポンスが多い頻度の高いAPIでは512バイトに設定している。しきい値を小さくすると圧縮率は上がるが、動的コンテンツが大きく変化する場合、TTFBとCPUに負担がかかる。しきい値を大きくすると、計算時間は節約できますが、中程度のサイズのHTML、CSS、JSONファイルで品質が良い場合、可能性が無駄になるリスクがあります。削減利益を得ることができます。

ブロトリ対Gzip：選択とレベル

Brotliは、テキストリソースに対してGzipよりも15-21パーセント良いレートをしばしば達成しますが、リクエストごとにCPUコストがかかります。 クッション. .ランタイム圧縮にはBrotliレベル3-4、プリパックアセットにはレベル9-11を使い、レガシークライアントや変化の激しいコンテンツにはGzipレベル5-6を使う。HTTP/2とHTTP/3は、サーバーのバッファとフラッシュポイントが正しく設定され、ストリームがストールしない限り、優れた圧縮の恩恵を受ける。より深く比較したい場合は、私の GzipとBrotliの比較日常的なホスティングを選択するための、実用的な価値観と考慮事項 容易にする.

閾値を設定する：ガードレールと損益分岐点

1024バイトを基本的な閾値としてスタートする。なぜなら、ヘッダーのオーバーヘッドが明らかに補正され、CPU使用率も妥当なままだからである。集光を残す。非常に低レイテンシーのネットワークと多くの最小限のAPIリプライでは、512バイトが有用である。管理コストがペイロードの削減を上回ることが多いため、512バイト以下に圧縮する価値があることはほとんどない。利用が多いマシンの場合、CPUリザーバーにバッファが戻るまで、一時的にしきい値を上げる。この漸進的な調整により、TTFBは低く保たれ、ペイロードは維持される。 安定性 システム全体の.

特にMIMEタイプを圧縮する

私は、text/html、text/css、application/javascript、application/json、image/svg+xmlといったテキストMIMEだけを圧縮している。勝利ドラッグ。image/*、application/pdf、font/woff2などのバイナリコンテンツは、影響が小さいかマイナスなので、そのままにしておく。フォントについては、WOFF2はすでに効率的にエンコードされており、それ以上の圧縮はほとんど意味がないため、WOFF2を直接使用しています。バイナリファイルが誤ってエンコーダーに入ってしまわないように、明示的な許可リストを管理し、ワイルドカードを避けています。こうすることで、圧縮チェーンをクリーンな状態に保ち、次のような事態を防ぐことができる。汚職誤分類によるものである。.

静的と動的：きれいな分離

私は、ビルド・プロセスやCDNエッジで静的アセットをあらかじめ.brや.gzとしてパッケージしておき、サーバーにこれらのバリアントを直接使わせている。 届ける. .ダイナミックなレスポンスに対しては、適度なレベルを設定し、バッファを十分に小さくして、最初のバイトブロックが素早く流れるようにする。二重圧縮が発生しないように、プロキシチェーンの1ホップだけを圧縮することが重要です。CDNがすでに圧縮を行い、Varyで正しく分離していれば、Originで圧縮をオフにすることができます。この分離はCPUを節約し、一定の 応答時間 負荷がかかっても。.

ヘッダーの管理とキャッシュ

私は常に Vary: Accept-Encoding を送信し、キャッシュがバリアントを正しく区別し、ユーザーを遅くしたりアセットを改ざんしたりするミスがないようにしています。 決定的. .静的ファイルの場合、私はコンテントエンコーディング（br/gzip）とコンテント長を使いますが、ダイナミックストリームは転送エンコーディング：chunkedで実行されることがよくあります。ETagsはエンコーディングに固有でなければならず、そうでないとキャッシュが不正なバージョンを配信することになる。さらに、私は圧縮前のアセットに長いキャッシュTTLを設定し、キャッシュ制御でそれらを保護する。コンパクトな出発点をここに示す： HTTP圧縮の設定, の最も重要な構成要素である。 シーケンス を示している。

HTTP/2とHTTP/3：フラッシュとバッファ

HTTP/2とHTTP/3では、重要なHTMLとCSSがレンダリング開始を遅らせないように、初期のフラッシュポイントに注意を払う。遅延. .バッファが大きすぎると、1つのストリームがスケジューリングを支配し、他のコンテンツが待たされるため、マルチプレキシングが遅くなる可能性がある。私は、最初の圧縮ブロックを小さくして素早く送信し、その後、長いファイルのブロックサイズを大きくします。Brotliは、ダイナミック・レスポンスにレベル3-4を使用する限り、適度なオーバーヘッドで良好なレートを示す。これによってインタラクティブ性が高く保たれ、一方で大きなバンドルが効率的になる。 シュリンク.

練習：Apache、Nginx、Caddy

私は適度なレベルと1024バイトのしきい値から始め、やみくもに最大レートを設定するのではなく、TTFBとCPUを系統的にチェックする。 強制する. .Apacheでは、mod_deflateまたはmod_brotliを有効にして、必要なMIMEタイプだけを定義する。Nginxでは、gzip_min_length 1024とBrotliをonに設定し、事前圧縮ファイル用にbrotli_staticと組み合わせています。Caddyはエンコーディングgzip zstd brのシンプルなスイッチを提供している。経験上 CPU負荷と圧縮レベル, というのも、動的応答の割合とコア数の組み合わせは、しばしば限界を超えるからである。 セット.

アパッチ 例 (mod_deflate/mod_brotli)：

の場合
 AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
 SetOutputFilterのDEFLATE
 デフレート圧縮レベル6
 デフレートバッファサイズ 64k


 は次のようになります。
 AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript application/json image/svg+xml
 ブロトリ圧縮品質 4
 BrotliWindowSize 22

Nginx 例

gzip on；
gzip_min_length 1024；
gzip_types text/plain text/css application/json application/javascript image/svg+xml；
gzip_comp_level 5；

brotliオン；
brotli_comp_level 4；
brotli_static on；
brotli_types text/plain text/css application/json application/javascript image/svg+xml；;

モニタリングとトラブルシューティング

私は、TTFB、ワーカーごとのCPU使用率、タイプごとの転送サイズを測定し、圧縮が役立つところと必要なところを確認できるようにしている。危害. .有効化後にTTFBが増加した場合は、レベルを下げるか閾値を上げます。奇妙な影響がある場合は、まず二重圧縮、Varyヘッダーの欠落、MIMEタイプの誤認識をチェックします。また、CDNとWAFのポリシーも確認します。圧縮を使った2つ目のホップは負荷をシフトさせ、最初のバイトまでの時間を悪化させることがよくあるからです。最初のチェックは、WebPageTestやBrowser-DevToolsなどのツールで十分です。監査完全に。.

測定ポイントと推奨値

いくつかの明確なパラメーターにこだわることで、コンフィギュレーションを管理しやすくし、なおかつ高いクオリティを達成できるようにしている。効果を示す。次の表は、有用なしきい値、レベル、およびキャッシュ命令をまとめたものです。HTML、CSS、JS、JSON、SVG、フォントを含む典型的なウェブスタックをカバーしています。負荷、CPUリザーバー、動的レスポンスの割合に応じて、しきい値を調整してください。控えめに開始し、測定し、繰り返しスライダーを小刻みに動かしてください。 ステップ.

リソース	しきい値（バイト）	ダイナミック（レベル）	静的（レベル）	キャッシュのヒント
エッチエムティーエル	1024	Br 3–4 / Gz 5–6	Br 9-11（圧縮前）	ハッシュ名の長いTTL
CSS/JS	1024	まれにダイナミック	Br 9-11（圧縮前）	不変、ハッシュごとのバリアント
JSON (API)	512-1024	Br 3–4 / Gz 5–6	一般的ではない	ヘッダーの一貫性を保つ
エスブイジー	1024	まれにダイナミック	9-11	テストレンジのリクエスト
フォント（WOFF2）	なし	なし	なし	それ以上圧縮しないでください。
画像（PNG/JPEG/WEBP）	なし	なし	なし	個別最適化
PDF	なし	なし	なし	エンコードを避ける

文脈におけるZstd：意味があるとき、ないとき

私がZstdを単独で評価するのは、その点が優れているからだ。 スループット率 をうまく圧縮している。しかし、ブラウザ環境では、サポートは異質であり、そのため私は通常Zstdをエンドユーザー向けのエンコーディングとして展開することはありません。内部サービス間やCDNバックボーン・ルートでは、ZstdはOrigin CDNのトラフィックを効率的に保つのに非常に役立ちます。エッジでは、私はBrotli（テキスト用）とフォールバックとしてのGzipに固執しています。Caddyでは、私はZstdをオプションで有効にしたままにしておきます。交渉互換性とパフォーマンスのバランスをとるため、Gzipの前にBrotliを使う。.

範囲リクエスト、ダウンロード、圧縮済みファイル

大容量のダウンロード（PDFやCSVなど）は別にチェックしています。バイナリ・データの場合、私は通常、コンテンツ・エンコーディングをオフにして、IDを配信します(アイデンティティ)の範囲リクエストが正しく動作し、ダウンロードの再開が安定するようにします。.br/.gz variant を持つ静的テキストファイルでは、クライアントからのリクエストに応じてサーバが正しい variant を選択し、コンテントの長さ、コンテントエンコーディング、ETag が一貫していることを保証します。圧縮された variant の部分的なリクエストでは圧縮長さ - スタックがこれをロバストに処理しない場合、レンジリクエストに対して非圧縮バージョンを提供する。これはエッジケースを緩和し、誤った再起動を防ぐ。.

セキュリティ：圧縮とデータ漏洩

私は、次のような圧縮関連のサイドチャンネルを考慮に入れている。 ブリーチ. .レスポンスに、攻撃者がコントロールできる入力に近い、秘密に依存するコンテンツ（トークン、セッションID）が反映されている場合、私は選択的に圧縮を無効にするか、秘密を切り離す（パディング、非圧縮の別フィールドへの分離）。ログインと支払いのパスについては、ヘッダやルールを使って圧縮をオフにするのが理にかなっています。セットされたクッキーヘッダを持つクッキーは重要ではありません。回答-ペイロード。そのため、パスやMIME、特定のテンプレートをターゲットにしたフィルターを用意し、ヒューリスティックを簡単に適用できるようにしている。.

CDNとプロキシチェーン：1ホップにつき1回の圧縮

私は圧縮が行われるホップを明確に定義している：圧縮が行われるホップは エッジ (CDN)かOriginのどちらかであり、両方ではありません。CDNが圧縮する場合、Originのコンテンツエンコーディングを省略し、Edgeが正しいバリアントをビルドするようにVary: Accept-Encodingを送信します。Originが事前に圧縮されたアセット（.br/.gz）を配信する必要がある場合は、EdgeがこれらのファイルをCDNに送信するように設定します。透明を設定し、再度変換しないようにします。中間プロキシによる変換を厳密に防ぎたい場合（コンプライアンスのためなど）、私はCache-Control: no-transformを設定する。デバッグのために、どのホップで圧縮そして、ホップごとにメトリクスを分けておく。.

ストリーミング、SSE、gRPC、WebSocket

サーバー送信イベント（SSE）や同様のストリームでは、私は高レベルを避け 大きい そうしないとレイテンシーが著しく増加する。gRPCは独自のメッセージ圧縮を使用し、HTTP/2を介して実行されます - ここでは、重複を防ぐために追加のHTTPコンテンツエンコーディングを避けています。同じことがWebSocketにも当てはまります。メッセージごとのdeflateは便利ですが、私は本当にテキストが多いチャンネルにのみスイッチを入れ、そのチャンネルを監視しています。 CPU-まさに効果的だ。.

アプリケーションサーバー：アプリレイヤー設定

私はエッジ／リバースプロキシでスレッショルドをコントロールする方が好きだが、フレームワーク圧縮の場合は、互いに何も働かないように一貫した値を設定する。.

Node.js/Express私は1024バイトのしきい値と適度なレベルを設定しました。静的ハンドラーはあらかじめ圧縮された静的アセットを直接提供し、私はテキストMIMEの動的ルートだけを圧縮します。.
御出でなさい各ハンドラーでMIMEの許可リストを明確に選択し、1KB以下の圧縮はスキップしている。長いストリームの場合は、最初のペイントに負荷をかけないように、書き込みフラッシュを小さくしている。遅延.
Java/Tomcat私はcompressionMinSize 1024を使い、MIMEリストを明示的に管理している。.

トムキャット 例（server.xml Connector）：

のようになります。

重要：アップストリームプロキシ（Nginx、Caddy）がすでに圧縮している場合は、アプリレイヤーの圧縮を無効にして、次のようにします。 重複作業 そして、ただ一人の層に責任を負わせる。.

適応しきい値と負荷制御

私は硬直した価値観ではなく、方針で考える。CPUの負荷が高いときは しきい値 一時的に（例えば1024バイトから2048バイトに）変更したり、ダイナミック・レスポンスのためにブロトリ・レベルを（例えば4から2に）下げたりします。負荷が下がったら、また値を上げる。これは、機能フラグ、Env変数、または単純なリロードで制御できる。CPUの少ないノードでは、私は最も重要なMIME（HTML/JSON）の圧縮を予約し、CSS/JSはほとんどストレージ/CDNから事前に圧縮されます。これは 優先順位付け TTFBをピークに傾けることなく安定させる。.

テストプレイブック：クイック検証

いくつかの再現可能なステップで効果を確認する：

交渉: curl -I -H „Accept-Encoding: br“ https://example.com - Content-Encoding、Vary、Content-Lengthをチェックする。.
フォールバック: curl -I -H „Accept-Encoding: gzip“ - 予想される gzip?ETagがBrotliと違う？
圧縮なしcurl -I -H „Accept-Encoding: identity“ - サイズの違いと TTFB を比較する。.
レンジcurl -I -H „Range: bytes=0-1023“ - サーバーはサブレンジを正しく受け入れ、Content-Rangeが適合するか？
デブツールズネットワーク上」のサイズと「リソースサイズ」を比較し、実際のサイズを決定する。貯蓄をご覧いただきたい。.

簡単にまとめると

しきい値を1024バイトに設定し、TTFBとCPUをチェックし、設定を微調整する。調整の後に。動的コンテンツにはBrotli 3-4を、事前圧縮されたアセットには9-11を使用し、Gzip 5-6は予備として残しておく。テキストMIMEのみを圧縮し、事前に圧縮したファイルを直接配信することで、ビルド資産を軽量で耐久性のあるものに保つ。キャッシュが正しく動作するように、Vary: Accept-Encoding、Content-Encoding、エンコーディング固有のETagsに注意しましょう。HTTP圧縮のしきい値を適切に設定することで、マシンに不要な計算作業を強いることなく、配信を大幅に高速化できます。 ブロック.