【ITニュース解説】Brotli and Gzip Compression: Shrink Text Assets Without Breaking PageSpeed Scores

ウェブサイトの表示速度は、ユーザー体験にとって非常に重要だ。インターネットを通じてデータがやり取りされる際、データ量が多いとページの読み込みに時間がかかってしまうため、このデータ量をいかに効率良く削減するかが重要になる。そこで利用されるのが「HTTP圧縮」という技術だ。これは、ウェブページを構成するファイル、特にHTML、CSS、JavaScriptといったテキストデータを小さくすることで、より速くウェブサイトを表示させるためのものだ。現在、この圧縮技術の主要なものとして「Brotli」と「Gzip」の二つが広く使われている。これらの圧縮技術を適切に利用することで、ウェブページの読み込み速度を向上させ、GoogleのPageSpeed Insightsのようなツールで計測されるパフォーマンススコアも改善できる。

HTTP圧縮は、ウェブサーバーがブラウザにファイルを送信する前に、その内容を縮小する仕組みで動作する。具体的には、ブラウザはサーバーに対して、どの圧縮形式に対応しているか（例えばBrotliを示すbrやGzipを示すgzip）を「Accept-Encoding」という情報で伝える。サーバーはその情報を受け取り、対応する圧縮形式の中から適切なものを選んでデータを圧縮し、その際に「Content-Encoding」という情報で、どの圧縮形式で送ったかをブラウザに伝える。ブラウザは圧縮されたデータを受け取ると、ページを表示する前にそのデータを解凍する。この一連のプロセスにより、ネットワーク上を流れるデータ量、つまり「転送サイズ」は大幅に減少するが、ブラウザが実際に処理するデータ量、すなわち「解凍後のサイズ」は変わらない。転送サイズの減少は、特にページの表示に必要なCSSやJavaScriptのような重要なファイルのダウンロード時間を短縮し、結果としてLCP（Largest Contentful Paint）のようなCore Web Vitalsの指標改善に貢献する可能性がある。ただし、この圧縮はデータ転送の最適化であり、サーバー側の処理速度や画像自体のサイズが原因の遅延を直接解決するものではない点に留意が必要だ。

BrotliとGzipは、どちらもテキストデータを圧縮する技術だが、それぞれ異なる特性を持つ。Brotliは比較的新しい圧縮アルゴリズムで、HTML、CSS、JavaScriptといったウェブコンテンツにおいて、Gzipよりも高い圧縮率を達成できることが多い。これは、より小さなファイルサイズで同じ内容を転送できることを意味する。しかし、Brotliは圧縮処理にGzipよりも高いCPU負荷がかかる傾向がある。一方、Gzipは古くから広く利用されており、ほとんどのブラウザとサーバーでサポートされている汎用性の高い技術だ。圧縮時のCPU負荷も、Brotliの非常に高い品質設定と比較すると低い。そのため、現代のウェブサイトでは、Brotliを優先的に利用し、Brotliが利用できない環境や古いブラウザのためにGzipをフォールバックとして用意しておくのが一般的なアプローチとなる。静的なファイル（頻繁に内容が変わらないファイル）については、ウェブサイトのビルド時にあらかじめBrotliとGzipの両方で圧縮しておき、リクエスト時にブラウザが対応する適切な形式のファイルを配信することで、サーバーのCPU負荷を削減できる。動的に生成されるHTMLなどには、サーバーやCDN（コンテンツデリバリーネットワーク）で中程度の圧縮品質設定を適用するのがバランスの良い選択肢となる。Zstandardという別の圧縮形式も一部のCDNで利用可能だが、現状ではBrotliとGzipが標準的な組み合わせと考えられている。

圧縮の恩恵を受けるのは、主にその内容がテキストで構成されており、かつまだ圧縮されていないファイルだ。具体的には、text/html（HTML）、text/css（CSS）、text/javascriptやapplication/javascript（JavaScript）、application/json（JSON）、image/svg+xml（SVG画像）などがこれに該当する。これらのファイルは圧縮によってファイルサイズが大きく減少し、転送速度の向上に大きく寄与する。一方で、JPEG、PNG、WebP、AVIFのような画像ファイルやMP4などの動画ファイルは、すでに独自のアルゴリズムで圧縮されているため、BrotliやGzipでさらに圧縮してもファイルサイズがほとんど減ることはなく、むしろ余計なCPUリソースを消費し、処理遅延の原因となることがある。フォントファイルの中にはWOFF2のように設計段階で既に圧縮されているものもあり、これらをさらに圧縮する意味は薄い。ウェブサイト全体のファイルを一律に圧縮しようとする設定は、このような非効率な圧縮を引き起こし、かえってパフォーマンスを悪化させる可能性があるため、圧縮対象のMIMEタイプを厳密に指定することが重要である。

BrotliやGzipの圧縮をウェブサイトに導入する方法はいくつかある。ウェブサーバー（NginxやApacheなど）に適切なモジュールを組み込み、圧縮を有効にする設定を記述するのが一般的な方法だ。この際、圧縮対象のMIMEタイプを正確に指定し、BrotliとGzipの両方をサポートするように設定することが求められる。例えばNginxでは、ngx_brotliモジュールを使用して、動的なコンテンツには中程度の圧縮レベルを設定し、Gzipも有効にしておくことで、Brotli非対応のクライアントにも圧縮を提供できる。アプリケーションレベルのミドルウェアで圧縮を制御することも可能だが、サーバーの手前にあるリバースプロキシやCDNで処理する方が効率的な場合も多い。CDNを利用している場合、多くのCDNが自動的にBrotliとGzipでの圧縮を提供してくれる。しかし、CDNの管理画面で設定を有効にするだけでなく、実際に配信されているレスポンスヘッダー（Content-EncodingやContent-Type）を確認することが重要だ。また、キャッシュを効率的に利用するために、サーバーやCDNは「Vary: Accept-Encoding」ヘッダーを返す必要がある。これは、ブラウザや中間キャッシュサーバーに、クライアントが要求する圧縮方式によって異なるコンテンツが提供される可能性があることを伝え、適切なキャッシュを行うよう促すものだ。

GoogleのPageSpeed InsightsやLighthouseの「テキスト圧縮を有効にする」という監査は、ウェブサイト上の特定のテキストリソースが圧縮されずに配信されている場合に指摘される。この監査をクリアするためには、単に「圧縮を有効にする」という設定を行うだけでなく、監査が指摘する具体的なURL（HTMLドキュメント、CSSファイル、JavaScriptファイルなど）が、実際にContent-Encoding: brまたはContent-Encoding: gzipヘッダー付きで配信されていることを確認する必要がある。これを確認するには、ブラウザの開発者ツールやcurlコマンドを使って、それぞれのURLのレスポンスヘッダーを調べるのが有効だ。そして、圧縮が有効になっていないMIMEタイプのファイルに圧縮を適用する。ただし、この監査の目的は、単にチェックマークを付けることではなく、ページの全体的なパフォーマンスを向上させることにある。そのため、圧縮設定を変更した後は、必ずPageSpeed Insightsを再実行し、パフォーマンススコア（特にTime to First ByteやLCP）が悪化していないかを確認する必要がある。転送サイズが減っても、動的な圧縮にCPUリソースを使いすぎてTime to First Byteが上がってしまうような場合は、圧縮品質を下げるか、静的ファイルは事前圧縮を利用するなど、設定を見直す必要がある。

圧縮設定でパフォーマンスを損ねてしまう間違いも少なくない。最も典型的なのは「二重圧縮」だ。これは、オリジンサーバーでGzip圧縮したファイルを、さらにCDNがBrotli圧縮するといった形で、同じデータを何度も圧縮してしまう状況を指す。結果としてファイルサイズが大きくなったり、解凍エラーが発生したりすることがある。各レスポンスタイプに対しては一つの圧縮レイヤーを設定し、その責任の所在を明確にすることが重要だ。また、JPEG画像など、すでに圧縮済みのバイナリファイルを圧縮対象に含めてしまう「間違ったMIMEタイプ指定」もよくある失敗だ。これはCPUリソースの無駄遣いになるだけで、ファイルサイズはほとんど減少しない。動的に生成されるHTMLに対して、Brotliの圧縮品質を最高レベルに設定するのも問題になりやすい。これはCPU負荷が非常に高くなり、Time to First Byteが不必要に長くなる原因となるため、高い圧縮品質はビルド時にオフラインで事前圧縮する静的ファイルにのみ適用すべきだ。「Vary: Accept-Encoding」ヘッダーの欠落も、キャッシュの混同を引き起こし、Brotli対応のクライアントにGzipされたコンテンツが送られるなど、予期せぬ挙動につながることがある。さらに、CDNのチェックボックスをONにしただけで、ウェブサイトが利用しているサードパーティのスクリプトやスタイルシートが圧縮されると期待するのも誤解だ。それらのリソースはそれぞれのホストで圧縮設定がされていなければ、依然として圧縮されないまま配信される。最後に、圧縮はLCP改善のための一つの手段であって、すべてのLCPの問題を解決する万能薬ではない。LCP要素が大きな画像であれば、画像自体の最適化が圧縮よりもはるかに重要になる。

圧縮設定は一度行ったら終わりではなく、デプロイ後や設定変更後には必ずライブURLでその効果を確認する習慣が重要だ。ウェブサイトのHTMLドキュメント、および表示に不可欠なCSSやJavaScriptファイルのContent-Encodingが、意図通りbrまたはgzipになっているか、そして転送サイズが内容サイズよりも大幅に小さくなっているかを確認する。LCPに影響する画像ファイルが誤って圧縮レイヤーによって再エンコードされていないかもチェックするべきだ。PageSpeed InsightsやLighthouseでの変更前後のスコア比較も必須となる。CDNルールやホストの設定変更、あるいは大規模なテーマやプラグインのアップデートがあった際にも、圧縮設定が意図せず変更されていないか再確認することが求められる。このような継続的な検証と監視を行うことで、圧縮によるパフォーマンス改善効果を確実に維持し、予期せぬ問題の発生を早期に発見できる。