Comprimir o mesmo ficheiro de cada vez
Sobre o conteúdo e a sua revisão
Neste artigo
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 servidor pequeno 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 a folha de estilos mudar e a reconstrução for esquecida, 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.