Pleskウェブサーバ

Brotliの圧縮レベル：パフォーマンスか、それともCPU使用率か？

ブロトリ・コンプレッション これにより、転送サイズの縮小とCPU消費の増加のどちらを優先するかを明確に判断せざるを得ません。ここでは、動的なレスポンスにおいて、レベル4～6を設定することで、多くの場合、時間とサイズの最適なバランスを実現する方法と、事前にパッケージ化されたアセットにおいてレベル9～11が真のメリットをもたらすケースについて解説します。.

中心点

以下の点は、計画や運用において、私にとって簡潔な指針となります：

レベル選択: レベルが高いほどバイト数は節約できますが、CPU負荷と処理時間は増えます。.
ダイナミクス: ライブ圧縮の場合、レベル4～6が最もバランスが良いことが多い。.
静的: 事前にパッケージ化されたアセットは、レベル9～11の恩恵を受けます。.
比較: Brotliはテキストの圧縮率が高い傾向があり、Gzipは圧縮が速い。.
オペレーション: TTFB、CPU使用率、エラー率などの測定値が選択の基準となります。.

なぜ「ブロートリ・レベル」が重要なのか

私が決める 圧縮レベル 直感ではなく、コストとメリットに基づいて判断します。段階が上がるごとに計算負荷は増大しますが、ある時点を過ぎると、それ以上のバイト数の削減効果はごくわずかになります。まさにこの時点でメリットが逆転します。ファイルサイズが数パーセント小さくなるだけで、それ以上のレイテンシやCPU負荷を正当化できるとは限りません。特にライブ圧縮の場合、レベルが高すぎると、データ転送量の削減はごくわずかであるにもかかわらず、応答時間が遅くなってしまいます。そのため、私はレベルを決定する前に、測定結果をもとにレイテンシ、処理時間、スループットを確認するようにしています。.

意図的に圧縮しない場合

すべてのバイトが有意義な時間の節約につながるわけではありません。非常に小さな応答（例えば1～2 KB未満）や、すでに圧縮済みのバイナリ形式の場合、ほとんどメリットがないにもかかわらず、CPUリソースを消費してしまいます。そのため、私は しきい値 MIMEタイプおよびルートごとに：

短いテキストのスニペットや204/304レスポンス：圧縮せずに配信する。.
画像、動画、PDF、アーカイブ：原則として除外する（多くの場合、すでに内部で圧縮されている）。.
ストリーミングに関する重要な回答：レイテンシーの急上昇を防ぐには、Gzipを使用するか、あるいはGzipを一切使用しない方が良い。.

明確な除外設定を行うことで、ワーカーの負荷を軽減し、P95/P99のTTFBを安定させています。.

決定的な違いをもたらすエンコーダパラメータ

品質レベルに加え、影響を与えるのは エンコーダのオプション 時間と理性を実感できる：

モード (generic, text, font): HTML/CSS/JS には「text」を、フォントには「font」を設定します。これにより、エンコーダーがパターンをより正確に認識できるようになります。.
ウィンドウサイズ (lgwin): ウィンドウを大きくすると、長いコンテンツの読みやすさが向上することが多いですが、RAMやCPUの負荷も増えます。私は実用性を重視してデフォルト設定のままにし、特定のテキストブロックの場合にのみサイズを大きくするようにしています。.
ブロックサイズ: ブロックサイズが小さすぎると比率が低下し、大きすぎるとレイテンシが増加する。一律に調整するのではなく、代表的なペイロードを使ってテストを行っている。.
フラッシュ戦略: 積極的なフラッシュ処理はバッファの遅延を低減しますが、圧縮率は低下します。サーバーストリーミングを利用するAPIについては、フラッシュの頻度を控えめに設定しています。.

動的コンテンツ：スイートスポット 4～6

HTML、JSON、またはAPIのレスポンスについては、リアルタイムで圧縮を行い、以下の点に細心の注意を払っています。 応答時間. レベル4～6は、通常、ファイルサイズ、CPU使用率、レイテンシのバランスが最も良好です。これによりTTFBが短縮され、CPU使用率を適正範囲内に抑え、ピーク時の負荷余力を高めることができます。より高いレベルをテストしてみると、ネットワーク上で目立ったメリットがないにもかかわらず、CPU処理時間が長くなるケースがよく見られます。さらに深く掘り下げたい方は、以下のリンクから多くの実践的な詳細情報をご覧いただけます。 CPU負荷とレベル, 、まさにこの妥協点を示しているもの。.

時点では ストリーミング （例：SSEやChunked JSONなど）の場合、Brotliを一部使用しないか、意図的に低いレベルに設定しています。その理由は、Brotliは長いセグメントにわたるコンテキストを活用するため、頻繁なフラッシングを行うとこの利点が失われ、CPU負荷が上昇してしまうからです。そのため、ルートごとに、スループットとレイテンシのどちらが重要か、またマイクロキャッシュが1秒単位のレスポンスを処理できるかどうかを慎重に検討しています。.

静的アセット：事前に圧縮する

CSS、JavaScript、その他のアセットについては、配信前に圧縮を行い、ファイルサイズが大きくなっても構わないとしています。 計算時間 ビルドサーバー上です。レベル9～11が適しています。コストは1回しかかからず、追加で節約できた分は永続的に効果を発揮するからです。これは、繰り返しダウンロードされるケースが多い場合や、通信速度が遅い環境において特に有効です。私は圧縮されたアーティファクトをオリジナルファイルの隣に保存し、クライアントに応じてサーバーが適切なフォーマットを配信するようにしています。重要なのは、デプロイがスムーズに実行されるよう、ビルド時に十分なCPUとRAMを確保しておくことです。.

ビルドには明確な 除外ルール （例：.jpg/.png/.mp4/.zip/.woff2 などは使用しない）、ファイル名によるバージョン管理とキャッシュバスター。これにより、ETag の一貫性を保ち、二重圧縮を防ぐことができます。大規模なバンドルの場合は、アプリケーションが許容する限りファイルを分割します。テーマ別に分類された小規模なアーティファクトはキャッシュされやすく、Brotliの辞書から相対的に大きな恩恵を受けます。.

日常におけるBrotliとGzipの比較

HTML、CSS、JS などのテキスト形式は、Brotli を使用すると通常、圧縮率がやや高くなる傾向がありますが、Gzip は多くの場合、圧縮が速く、圧縮率も低くなります。 CPU が必要です。そのため、アクセスが集中するページでのリアルタイム圧縮については、CPU使用率が急上昇した場合に備えて、Gzipをフォールバックとして用意しています。静的アセットについては、アクセスするたびに転送サイズが小さくなるというメリットがあるため、Brotliを優先しています。古いシステムやプロキシチェーンの場合には、柔軟に対応し、両方のフォーマットに対応しています。直接比較に関する良い入門情報としては、 Brotli 対 Gzip それぞれの特徴的な長所と短所を併せ持っています。.

私にとって重要なのは、 キャパシティ・プランニング: スループット（秒あたりのリクエスト数）を指標とする場合、CPUリソースが限られている状況ではGzipが有利です。一方、帯域幅やCDNのアウトバウンド通信コストが高い場合、アセットに対してはBrotliの導入コストがすぐに回収できます。そのため、私は両方を組み合わせています。静的コンテンツにはBrotliを標準として採用し、ライブ環境ではGzipを弾力的な予備として活用しています。.

CPUリソース、レイテンシ、TTFB

私はまず、明確な定義をする。 CPU予算 リクエストごとに評価し、それに基づいてレベルを設定しています。これにより、圧縮がTTFBに過大な影響を与えたり、ピーク負荷がエラーを引き起こしたりするのを防いでいます。用途ごとに分類し、正確な数値ではなく相対的な影響度を基準にするのが有効です。以下の表は、私がレベルとシナリオをどのように関連付けているかを示しています。これはベンチマークの代わりにはなりませんが、テストを行う上で信頼できる出発点となります。.

ブロトリ・レベル	CPU負荷／所要時間	スペースの節約	こんな人に向いている	ヒント
1-3	ロー	控えめ	リソースが限られた環境でのライブ圧縮	速い, 、しかし節約効果は少ない
4-6	ミディアム	良い	動的なHTML/APIレスポンス	よくスイートスポット TTFBについて
7–8	増加した	上々	混合シナリオ：一部はライブ、一部は事前収録	空気が入っている場合のみ CPU予算
9-11	高い	最大	事前に圧縮された静的アセット	ビルド時間が延び、転送量が減少

コンテンツネゴシエーション、Vary、およびキャッシュキー

クライアントが確実に最適な選択肢を受け取れるようにするため、私は コンテンツ交渉 クリーンだ：

Vary: Accept-Encoding 必須です。そうしないと、キャッシュが後続のクライアントに誤った形式のデータを配信してしまいます。.
元のファイルの横に、事前圧縮済みの .br ファイルを保存する。サーバーは正しく処理する コンテンツ・エンコーディング：br そして、それに合う コンテンツタイプ.
CDNに関しては、以下の点を確認しています。 キャッシュ・キー „「Accept-Encoding」を考慮し、BrotliとGzipを別々にキャッシュする。.
ETag/Last-Modified については一貫した方針を貫きます。不一致を防ぐため、圧縮済みと非圧縮のアーティファクトにはそれぞれ個別のバリデータが割り当てられます。.

また、プロキシや古いHTTP/1.1クライアントがどのように反応するかもテストしています。不確実な点がある場合は、安定性を優先し、Gzipを有効にしたままにするか、圧縮なしの状態で配信するようにしています。.

キャッシュ、辞書、および事前圧縮

私は以下の方法でサーバーの負荷を軽減しています。 キャッシング 内容が許す限り、圧縮されたレスポンスを使用する。テキストに繰り返しパターンが見られる場合は、ディクショナリを検討する価値があります。これにより、効率が向上し、リクエストあたりの処理時間が短縮されます。プリコンプレッションを使用する場合は、サーバーが再エンコードを行わずに配信できるよう、キャッシュヘッダーを適切に設定し、ファイル名には .br などの拡張子をつけるようにしています。動的コンテンツについては、エッジキャッシュや有効期間が数秒のマイクロキャッシュを検討し、ホットパスの負荷を大幅に軽減します。これにより、CPU使用量を予測可能な範囲に抑え、安定した応答時間を確保します。.

辞書多くのレスポンスに類似したトークン（名前空間やJSONキーなど）が含まれている場合に、これを意図的に活用しています。辞書は小さく保ち、ダウンタイムなしで交換できるようバージョン管理を行っています。動的なAPIの場合、利益率は低くなりますが、トラフィックが均一であればその価値は十分にあります。.

構成：Nginx、Apache、CDN

私はBrotliを、特定の MIMEタイプ また、ほとんどメリットのないバイナリ形式はブロックしています。Nginxでは、ファイルサイズやパスに応じてmapを使って異なるレベルを設定し、ホットルートの負荷を軽減しています。Apacheでも、フィルターチェーンと明確な例外設定を用いて同様の処理を行っています。 CDNでは、クライアントが確実に適切なフォーマットを受け取れるよう、事前圧縮とVaryヘッダーを活用しています。セットアップの確かな手引きとして、以下のガイドが役立ちます。 HTTP圧縮実用的な選択肢を盛り込んで。.

さらに、次のように定義します。 最小サイズ (min_length) 以上になると圧縮が有効になるため、リバースプロキシが再度圧縮を行わないよう注意してください。二重エンコーディングは、Content-Lengthヘッダーの不備やクライアントエラーから即座に判別できます。 部分コンテンツ（範囲指定リクエスト） 私は元のファイルを用意しています。圧縮されたファイルは、ここでは限定的な用途にしか適しておらず、キャッシュの動作を混乱させる可能性があります。.

モニタリングとベンチマーク

私はその変化を一つひとつ測定しています。 レベル 管理されたベンチマークと運用指標を用いて評価します。重要な指標は、TTFB、スループット、ワーカーあたりのCPU負荷、および負荷時のエラー率です。動的なルーティングについては、外れ値がユーザー体験に大きな影響を与えるため、p95/p99値をテストしています。また、移行前後のトラフィック構成やアセットサイズを比較し、予期せぬ影響がないかを確認します。数値が数日間安定して維持されて初めて、そのプロファイルを新しいベースラインとして認定します。.

私の 試験項目 要約すると：

代表的なペイロード（小／中／大）と実際のヘッダーを使用する。.
ウォームアップを行い、その後、安定した負荷状態で測定ウィンドウを動作させる。.
競合するシステム要因（GC、I/O、TLSオフロード）を個別に監視する。.
常に「同条件同士」で比較すること：シード値が同一、データセットが同一であること。.

セキュリティとエッジケース

圧縮処理により、反射された応答に秘密のトークンが含まれる場合、サイドチャネル攻撃が発生しやすくなる可能性があります。私は 圧縮を無効にする 機密性の高いエンドポイント（ログインフロー、HTML内のCSRFトークンなど）では、これらを個別のルートに分離します。やむを得ない場合は、データに依存する長さのばらつきを最小限に抑えるため、コンテキストを削減します（例：より中立的なテンプレートの使用など）。.

実務上のその他の落とし穴：

損傷した遺物 ビルドの失敗による問題：デプロイ前にチェックサムを確認し、正しい拡張子（.br）とMIMEタイプを設定してください。.
互換性のないプロキシ: 原因不明の 206/Content-Encoding エラーが発生した場合は、Gzip へのフォールバックを有効にする。.
タイムアウト レベルが高い場合：レベルを下げるか、ワーカー／CPUの割り当てを増やす。.
Varyヘッダーの欠落: CDNキャッシュ内で「誤った」応答を引き起こし、特定のブラウザでは表示エラーとして現れる。.

プロジェクトのフェーズごとの優先順位

初期段階では、レベルを低～中程度に抑えて、反復そしてデプロイの速度を維持します。トラフィックが増加し次第、静的アセットの最適化をさらに積極的に行い、動的レスポンスについては「スイートスポット」で安定させます。トラフィックのピークが予想される場合は、安易にレベルを引き上げるよりも、ワーカーとキャッシュの容量を拡張することを優先します。国際的なユーザー層を対象とする場合は、ネットワーク上では1ミリ秒でも重要であるため、プリコンプレッションとエッジキャッシングに投資します。これにより、リソースを無駄にすることなく、プラットフォームの信頼性を維持できます。.

WordPressとホスティングの実践

WordPress Stacks では、Brotli をサーバー側で設定しており、経由してではなく プラグイン PHPパス内に配置することで、CPUのオーバーヘッドを回避しています。ビルドパイプラインでアセットを事前に圧縮させ、デプロイ後のキャッシュ無効化と組み合わせています。オブジェクトキャッシュとページキャッシュにより、動的圧縮の負荷をさらに軽減しています。フォールバックパスについては、Gzipを有効にしておき、特殊なクライアントに対しても適切なレスポンスが返されるようにしています。導入を検討している方は、この実践ガイドを参考にし、テレメトリのデータが許す範囲で段階的にレベルアップしていくとよいでしょう。.

マルチサイト構成やヘッドレステーマについては、私は pro‑Route さまざまなプロファイルを用意しています：APIルートはレベル4～5、HTMLレンダリングパスは5～6、静的バンドルは厳密に事前生成で10～11です。重要なのは、キャッシュキーとパージロジックを新しいアーティファクト名に適切に紐付けることで、古い.brファイルが流通し続けないようにすることです。.

トラブルシューティングとよくある落とし穴

何かがカクカクする場合は、体系的に対処します：

二重圧縮: アップストリーム（アプリサーバー）がすでに圧縮を行っており、エッジサーバーが再度エンコードしていないかを確認する。解決策：処理を担当する場所を1か所に限定する。.
Content-Length の誤り: Transfer-Encoding: chunked の場合、固定長を送信しないこと。そうしないと、ブラウザが処理を中断してしまう。.
原本の欠落: レンジリクエスト、旧クライアント、およびデバッグ用には、必ず非圧縮のファイルを用意してください。.
難易度が高すぎる: 症状としては、p99-TTFBの上昇、散発的な5xxエラー、およびCPUの飽和が見られる。対処法：レベルを下げるか、キャッシュを強化する。.
資産構成を変更しました: フレームワークの更新に伴い、トークンの出現頻度が変化し、比率が突然悪化する可能性があります。ベンチマークを再実施し、辞書を調整してください。.

簡単にまとめると

私はレベル選びを慎重に行い、それを厳しい条件と結びつけています指標. 。動的コンテンツについては、TTFBが重要であり、CPU使用率の急上昇はコスト高につながるため、通常はレベル4～6を設定しています。静的アセットについては、1％の削減が数倍の効果をもたらすため、事前にレベル9～11で圧縮しています。 Brotliは多くの場合、最適な圧縮率を実現し、Gzipは速度面での優位性とフォールバックとしての役割で優れています。決定的なのは、自社のテレメトリデータです。測定と反復改善を重ねることで、トラフィック、ハードウェア、ユーザー体験に最適なプロファイルを迅速に見つけることができます。.