同じファイルを毎回圧縮する

Apache はレスポンスをその場で圧縮します。毎回中身が違うページなら、それしか手がありません。月に一度しか変わらないスタイルシートにとっては、サーバーが訪問者ごとに同じ作業をやり直し、何週間も続け、そのたびに結果を捨てるということです。そのためのキャッシュはありません。

2026 年 8 月 19 日、確立済みの接続の上で、このサイト自身の style.css（124 kB）と world.js（102 kB）を使って実測：

	時間	バイト
圧縮なし	2.9 ms	124,755
gzip、その場で	18.1 ms	34,995
brotli、その場で	14.5 ms	32,685
world.js、gzip	47.9 ms	38,283
world.js、brotli	15.9 ms	38,086

一リクエストあたり四十八ミリ秒の計算時間を、一バイトも違わない同じ結果を作るために使う。Raspberry Pi では、これは丸め誤差ではありません。

一度だけ圧縮して、ディスクに置く

ビルド手順が圧縮済みファイルを元のファイルの隣に書き、書き換えルールがブラウザの「gzip を受け付ける」という申告に応じてそれを返します。出来上がったファイルを返す費用は、どのファイルを返す費用とも同じです。

brotli ではなく gzip なのは、退屈な理由です。この機械には brotli のコマンドが入っていません。ファイルは brotli より 7 % ほど大きくなりますが、サーバー時間はその場の brotli の五分の一です。この交換は、もっと格好いい答えを待つより今やる価値がありました。

版はファイル名の中に

ビルドは style.css.<mtime>.gz を書き、マークアップの ?v= は同じ更新時刻です。書き換えは、その数字に一致するファイルが存在するときにだけ働きます。

この組み方には、狙って設計する価値のある性質があります。スタイルシートを変えて再ビルドを忘れると、マークアップの数字は存在しないファイルを指し、書き換えは働かず、Apache は普通に元のファイルを返します。最悪でも速度向上がなくなるだけです。古いスタイルシートが出てくることはありません。どんなキャッシュの仕組みも、この問いに当ててみるべきです — 壊れたとき、遅くなるのか、間違うのか。

その途中にあった不具合

返されるファイルはすでに gzip なので、出口でもう一度圧縮してはいけません。設定には最初 no-gzip だけが書かれていて、これは Apache の二つある圧縮器のうち一つを止めます。もう一方の mod_brotli は、出来上がった gzip ファイルを機嫌よく brotli で包み直し、その間もレスポンスヘッダーは gzip だと言い続けていました。

ブラウザには読めない中身が届きました。見つかったのはページを眺めてではありません — バイト数を足し合わせて、辻褄の合わない数字に出くわして見つかりました。必要なのは no-gzip と no-brotli の両方で、そのうち分かりやすいほうは片方だけです。