Pleskウェブサーバ

GzipとBrotli：ホスティングにおけるHTTP圧縮方式の比較

GzipとBrotliの比較 で決定する。 ホスティング 読み込み時間、ファイルサイズ、CPU予算。この比較では、私がどのHTTP圧縮方式を有効にするのか、どのレベルを使うのか、そしてそれがどのようにコアウェブバイタルとコストに直接影響するのかを、実践的な方法で示します。.

中心点

圧縮率Brotliは、特に静的アセットで、Gzipよりも15-25 %多くのバイトを節約します。.
スピードGzipはオンザフライでより速く圧縮し、Brotliはブラウザでより速く解凍することが多い。.
静的／動的圧縮前のファイルにはBrotliを、動的な応答にはGzipを使用する。.
フォールバックBrotliを優先し、互換性のあるフォールバックレベルとしてGzipを使用する。.
SEO/UX小さなファイルは待ち時間を短縮し、ウェブの中核となるバイタルとランキングを強化する。.

HTTP圧縮がホスティングを成功に導く理由

頼りにしているのは HTTP圧縮, なぜなら、各レスポンスが容易になり、その結果、ネットワーク上でかかる時間が短くなるからだ。より短い転送は インタラクティブ, TTFBインプレッションを圧縮し、ローディング・シーケンスを安定させます。特にモバイル接続では、1キロバイト1キロバイトが重要であり、圧縮はこのフットプリントを著しく削減します。さらに、サーバーの帯域幅を節約できるので、トラフィックが多いときには本当に助かります。 コスト が削減される。したがって、パフォーマンスを優先する企業は、サーバー、CDN、エッジのすべてのエッジで、一貫して適切な圧縮方式を有効にしている。.

Gzip：長所、レベル、応用分野

ジージップ はDEFLATEをベースにしており、実際には非常に短い圧縮時間で50-70 %小さいファイルを提供します。動的なHTMLレスポンスには、私はしばしばレベル 6, というのも、スピードと節約の良い比率を提供しているからだ。スループットが高いので、CPUに負担がかからず、レイテンシも低く抑えられる。負荷によっては、オンザフライの時間をさらに短縮するために、高度にダイナミックなコンテンツにはレベル4-5を使うこともある。Gzipは実質的にどこでも使用できるため、予備として不可欠であることに変わりはない。 機能する.

ブロトリ：利点、レベル、限界

ブレッドスティック は、LZ77、ハフマン・コーディング、そして頻繁に使われるウェブ・パターンを含む120KBの辞書を使用する。これはHTML、CSS、JavaScriptをGzipよりも平均的に、特に高いレベルで大幅に縮小します。と比較して、15-25 %バイト少なくなります。 ジージップ, これにより、転送時間が明らかに短縮される。ブラウザでの解凍は非常に速く実行され、レンダーパイプラインを緩和します。オンザフライでは中程度のレベル（4～6など）を使用し、事前圧縮されたアセットでは、ビルドプロセスでレベル8～11を好みます。.

日常的なホスティングにおけるGzipとBrotliの比較

に従って決める。内容とロードプロファイル: 動的は Gzip、静的は Brotli。CSS/JS、フォント、大規模なHTMLテンプレートでは、Brotliによる事前圧縮が著しく価値がある。リクエストごとに変化するコンテンツでは、圧縮時間が重要です。 ジージップ. .最近のスタックでは、Brotliが優先され、Gzipはフォールバックとして、両方が並行して実行される。より深く掘り下げたいのであれば、以下のサイトを参照してください。詳細比較さらに重要な数字と具体的な使用例。.

比較表：主な数値とサポート

次の表は、最も重要なものを分類したものである。基準ホスティングのセットアップについて、どの方法が最適かを示してくれる。ファイルの種類、負荷、互換性に基づいて判断するのに役立ちます。私は圧縮率、サーバーのオーバーヘッド、ブラウザのサポート、知覚速度への影響を評価します。このようにして、オンザフライで使うべきか、ビルドステップとして使うべきかを判断しています。 コンプレス. .Brotliによる予備圧縮は、特に大きな静的バンドルに適している。.

基準	ジージップ	ブレッドスティック	実際の効果
圧縮率	約50-70 %の小型化	通常、Gzipより15-25 %小さい。	より少ないバイト数、より速い伝送
圧縮速度	特にレベル1～6では速い	高いレベルでは遅い（8-11）	動的レスポンスに有利なGzip
減圧	速い	多くの場合、さらに速い	レンダリング開始がよりスムーズに
ブラウザのサポート	ほぼ完成	モダンブラウザで非常に広い	互換性のあるフォールバックレベルとしてのGzip
CPU使用率	低レベルでは低い	高いレベルではより高い	ビルド時間とランタイムを明確に比較する

これらの主要な数字に付け加える。 TTFB と帯域幅を判断材料にしている。CPUのリザーブが厳しい場合は、ライブ圧縮に低いレベルを選択する。CI/CDパイプラインでは、高いBrotliレベルで静的ファイルを事前に圧縮する。こうすることで、短いレスポンスタイムと非常に小さい圧縮率を両立させている。資産. .このミックスは、一貫して優れた充電体験を提供する。.

NginxとApacheの設定練習

起動させる ブレッドスティック とGzipをモジュール経由で設定し、適切なMIMEを設定し、サーバーの負荷に応じてレベルを調整します。Nginxでは、on-the-flyと.br/.gz拡張子の事前圧縮ファイル用に別々の設定を使っている。Apacheでは、mod_brotliやmod_deflateなどのモジュールと htaccess キャッシュとVaryヘッダーのルール。ビルドにおける事前圧縮は、サーバーが配信のみを行い、常にパックを行う必要がないようにするために重要であることに変わりはない。ステップ・バイ・ステップのガイドをお探しなら、このガイドから始めてください。 HTTP圧縮の設定.

戦略ダイナミック vs スタティック

時点では ダイナミック 静的リソースについては、私は高レベルでBrotliを使用し、成果物はすでにファイルシステムやCDNに保存している。この戦略は CPU を実行して、バイト数を最大まで減らします。サーバがエンコーディングに基づいて適切な variant を選択するようにします。このようにして、Brotliでモダンブラウザに、Gzipで古いクライアントに確実にサービスを提供しています。.

SEO効果とウェブの核心

ファイルサイズが小さいと レイテンシー そして、コンテンツをより早く表面化させる。ファーストコンテンツフルペイントが改善され、ラージコンテンツフルペイントがより安定していることによく気づきます。これは、接続が弱いモバイル・デバイスでは明らかに顕著です。また、データ転送量も節約できます。 コスト を下げる。これらの利点は、視認性、コンバージョン、ユーザーの満足度という点で実を結ぶ。.

モニタリングとチューニング: 測定可能な速さ

の効果をチェックする。圧縮ラボと現場での測定で。PageSpeedやRUMデータなどのツールは、調整前後のFCP、LCP、TTFB、転送サイズを示してくれる。CPU負荷が高ければレベルを下げ、ファイルが大きすぎればビルド・ステップで増やします。Cache-ControlやETagのようなキャッシュ・ヘッダは、不必要な再パッキングを防ぎ、ビルド・ステップを強化します。 効率性. .トラフィックパターンやアセットサイズは変化するため、定期的なテストが重要であることに変わりはない。.

実践的なセットアップ：WordPress & Co.のハイブリッド・アプローチ.

のために ワードプレス CSS/JS/フォントにはBrotliを、PHPで生成されたHTMLページにはGzipを選択することが多い。CDNは事前に圧縮されたファイルを配信し、Originはダイナミックなレスポンスを素早くパックします。私は、キャッシュをきれいに分離するためにVaryヘッダーに注意を払い、.br/.gzの亜種のために同一のETagsに注意を払う。微調整をしたい場合は、以下を参照してください。圧縮レベルとCPU負荷. .これにより、レンダーチェーンが軽くなり サーバー負荷 計算可能で互換性も高い。.

圧縮しないファイル

すべてがHTTP圧縮の恩恵を受けるわけではありません。いくつかのフォーマットは、すでに内部で最適にパックされていたり、追加の圧縮が邪魔になりがちなバイトレンジのリクエストを必要としたりする。そのため、私は一般的に非圧縮のままにしています：

画像JPEG/JPG、PNG、GIF、WebP、AVIF（すでに高圧縮済み）
ビデオ/オーディオ：MP4、WebM、MOV、MP3、OGG、AAC
アーカイブ/コンテナ：ZIP、7z、RAR、ISO、PDF（圧縮されていることが多い）、DMG
フォントフォーマット： WOFF2 (内部的にBrotliを使用)、WOFFは部分的に圧縮可能、セットアップによってはTTF/OTFをあらかじめパックしておく。
範囲によって頻繁にロードされるバイナリダウンロード

特に以下を圧縮すべきである。 テキスト形式HTML、CSS、JavaScript、JSON、XML、SVG、ウェブマニフェスト、サイトマップ。XMLとしてのSVGは大きな利点があります。一方、WOFF2はそうではありません - ここでは、私は自分自身のコンテンツエンコーディングを保存します。.

HTTP/2/HTTP/3とTLS：圧縮との相互作用

HTTP/2とHTTP/3はトランスポートとマルチプレクシングを加速させるが、次のように置き換わる。ないペイロードの圧縮。ヘッダー圧縮（HPACK/QPACK）はヘッダーのみを処理し、ボディーを処理しない。そのため、ボディーのバイト数が少ないことは明らかな利点です。重要です： ブレッドスティック 実際には、ブラウザはこの情報を HTTPS を提供した。まだ純粋なHTTPを使っている人は、通常Gzipをオプションとしてしか見ない。TLSターミネーションチェーンでは、エッジでの圧縮がクライアントの近くで行われるようにして、レイテンシとイグレスを最小にします。.

バリアント処理：Acceptエンコーディング、キャッシュ、ETags

クリーン コンテンツネゴシエーション はキャッシュのヒット率を決定する。私は一貫してVaryヘッダーを Accept‑Encoding, プロキシとCDNが正しくバリアントを分離するように。プリパックされたアセットについては 最終更新日 そして、表現ごとに別々のETagsを割り当てる（.br/.gz/identical）。CDNはキャッシュキーにacceptエンコーディングを追加する。二重圧縮を避けることが重要です：ファイルがすでに.brとして存在する場合、サーバーはそれを再びgzip圧縮してはならない。バイト範囲（ビデオなど）については、非圧縮のバリアントを提供します。なぜなら、範囲は符号化された表現を参照し、そうでなければキャッシュに一貫性がなくなる可能性があるからです。.

微調整：しきい値、レベル、CPUバジェット

一緒に仕事をしている 最小サイズ, 非常に小さなファイルが不必要にパックされないようにするためである（通常、しきい値1～2KB）。ダイナミックなレスポンスに対しては、Gzipレベル4-6かBrotli4-6を選び、ビルドの成果物に対しては、ビルド時間が妥当である限り、Brotli9-11を選ぶ。これまでの経験則

小さなHTMLスニペットとAPIレスポンス：Gzip 4-5またはBrotli 4-5
大きなバンドル（JS/CSS > 50 KB）：事前にBrotli 8-11
ライブの交通量が非常に多い：待ち行列やTTFBのピークを避けるためにレベルを下げる。

CPUのピークに注意することが重要だ。圧縮パイプラインが詰まると、知覚されるTTFBが悪化する。その時はライブレベルを下げ、節約分をビルドに回します。.

安全性：リスクのない圧縮

TLSによるトランスポート圧縮は安全だが、コンテンツ圧縮に対するサイドチャネル攻撃は何年も前から知られている（キーワード ブリーチ).実用的には、これは秘密のトークンを含むページが そして 同時に、ユーザーの入力を反映するエンドポイントについては、慎重に圧縮するか、まったく圧縮しないようにしている。例えば、CSRFトークンを含むフォームページを反映パラメータから分離したり、エコーコンテンツを最小化したり、これらのエンドポイントの圧縮を無効にしたりします。静的アセットはこの影響を受けません - 私は積極的に圧縮し続けます。.

CDN、サーバーレス、オブジェクトストレージ：責任の明確化

時点では CDNの設定 私はエッジ圧縮を有効にしておき、圧縮前のアーティファクトもアップロードする。正しいメタデータは重要だ： コンテンツタイプ そして コンテンツエンコーディング が正しくないと、CDN は間違った variant を提供したり、二重に圧縮したりします。で サーバーレス-機能では、コールドスタートとCPUスパイクを避けるために、ライブレベルを控えめ（Gzip 4-5またはBrotli 4）に保っています。オブジェクトストレージ（Originなど）には、.br/.gzを生ファイルの隣に保存します。ビルドパイプラインは、ETagsが安定するように、すべてのバリアントを決定論的に生成します。.

チェックとデバッグ：効果の確認方法

私は定期的にブラウザのDevToolsで配信を検証している：ネットワーク・ビューで コンテンツエンコーディング, 送信されたバイト数と、サーバーがキャッシュから応答しているかどうか。また可変-ヘッダと、Brotliが本当にHTTPSクライアントに配信されているかどうかを確認した。APIレスポンスについては、圧縮と非圧縮のサイズを比較し、負荷時のTTFBを観察しています。次のことに気づくだろうか。 エラーパターン 私が問題に遭遇した場合、たいていはVaryヘッダーの欠落（キャッシュポイズニング）、二重圧縮（br+gz）、コンテンツタイプとエンコーディングのペアの設定が正しくない、小さなファイルの不必要な圧縮が原因です。私はレベルをさらに上げる前に、まずこれらのケースを修正します。.

費用対効果を簡単に計算

圧縮は時間を節約するだけではない。 退出量. .例えば、毎月1TBのテキスト・トラフィックを配信し、Gzipと比較してBrotliで平均20 %を節約した場合、送信トラフィックを約200GB削減できます。料金プランにもよりますが、この節約効果はかなり大きくなります。コンピュート側では、ライブレベルを上げるとCPU時間がかかります。そのため、私はイグレス・コストとCPU予算のバランスをとり、高価なレベルは一度しか発生しないビルドに移動させます。.

エッジケース：ストリーミング、プロキシ、小さなファイル

時点では サーバー送信イベント またはストリーム応答では、チャンクが遅延なく流れるように、Gzipを低レベルにするか、圧縮を無効にすることを好む。古いプロキシでは Accept‑Encoding 堅牢なフォールバックとしてGzipを有効にしている。ヘッダーのオーバーヘッドとレイテンシーがしばしば利得を中和してしまうからだ。.

要約：賢い組み合わせが功を奏す

をセットした。 ブレッドスティック できれば静的ファイルで、信頼できるフォールバックレベルとしてGzipを用意しておく。ダイナミックなレスポンスには高速レベルを、ビルドには最大限の節約を目指している。このようにして、短いTTFBと非常に小さな転送を組み合わせ、コアとなるウェブのバイタルを持続的に強化しています。クリーンなコンフィギュレーション、事前圧縮、モニタリングにより、スタックは高速なまま維持される。厩舎. .このミックスをコンスタントに使えば、ローディング時間の短縮にすぐに気づくだろう。.