Comprimir o mesmo ficheiro de cada vez

O Apache comprime as respostas no momento. Para uma página que é diferente de cada vez, é a única via. Para uma folha de estilos que muda uma vez por mês, significa que o servidor repete o mesmo trabalho para cada visitante, durante semanas, e deita fora o resultado de cada vez. Cache para isso não existe.

Medido a 19 de agosto de 2026 sobre uma ligação já existente, com o style.css (124 kB) e o world.js (102 kB) deste sítio:

	tempo	bytes
sem compressão	2,9 ms	124 755
gzip, no momento	18,1 ms	34 995
brotli, no momento	14,5 ms	32 685
world.js, gzip	47,9 ms	38 283
world.js, brotli	15,9 ms	38 086

Quarenta e oito milissegundos de processador, por pedido, para produzir um resultado idêntico byte a byte. Num Raspberry Pi isso não é um erro de arredondamento.

Comprimir uma vez, para o disco

Um passo de construção escreve o ficheiro comprimido ao lado do original, e uma regra de reescrita serve-o quando o navegador diz que aceita gzip. Servir um ficheiro já pronto custa o que custa servir qualquer ficheiro.

gzip e não brotli, por uma razão aborrecida: nesta máquina não está instalado nenhum executável brotli. Os ficheiros saem cerca de 7 % maiores do que o brotli os faria, e o tempo de servidor é um quinto do que custa o brotli no momento. Essa troca valia a pena ser feita já em vez de esperar por uma resposta mais bonita.

A versão vai no nome do ficheiro

A construção escreve style.css.<mtime>.gz, e o ?v= na marcação é essa mesma hora de modificação. A reescrita só dispara quando existe um ficheiro com o número correspondente.

Este arranjo tem uma propriedade pela qual vale a pena desenhar de propósito: se mudares a folha de estilos e te esqueceres de reconstruir, o número na marcação aponta para um ficheiro que não existe, a reescrita não dispara e o Apache serve normalmente o original. O pior caso é faltar a aceleração. Uma folha de estilos desatualizada não pode sair. Todo o esquema de cache devia ser confrontado com esta pergunta — quando corre mal, fica lento ou fica errado?

A avaria no meio disto tudo

O ficheiro servido já é gzip, portanto não pode ser comprimido segunda vez à saída. Na configuração estava primeiro no-gzip, que trava um dos dois compressores do Apache. O outro, o mod_brotli, empacotava alegremente em brotli o ficheiro gzip acabado, enquanto o cabeçalho da resposta continuava a afirmar gzip.

Os navegadores recebiam conteúdo ilegível. Não foi descoberto a olhar para a página — foi descoberto a somar os bytes e a encontrar um número que não fazia sentido. São precisos os dois, no-gzip e no-brotli, e só um deles é o óbvio.