Compresser le même fichier à chaque fois

Apache compresse les réponses à la volée. Pour une page différente à chaque fois, c'est la seule option. Pour une feuille de style qui change une fois par mois, cela veut dire que le serveur refait le même travail pour chaque visiteur, pendant des semaines, et jette le résultat à chaque fois. Il n'existe aucun cache pour cela.

Mesuré le 19 août 2026 sur une connexion déjà établie, avec les style.css (124 ko) et world.js (102 ko) de ce site :

	temps	octets
sans compression	2,9 ms	124 755
gzip, à la volée	18,1 ms	34 995
brotli, à la volée	14,5 ms	32 685
world.js, gzip	47,9 ms	38 283
world.js, brotli	15,9 ms	38 086

Quarante-huit millisecondes de calcul, par requête, pour produire un résultat identique octet pour octet. Sur un Raspberry Pi, ce n'est pas une erreur d'arrondi.

Compresser une fois, sur le disque

Une étape de construction écrit le fichier compressé à côté de l'original, et une règle de réécriture le sert quand le navigateur annonce qu'il accepte gzip. Servir un fichier tout prêt coûte ce que coûte servir n'importe quel fichier.

gzip plutôt que brotli, pour une raison ennuyeuse : il n'y a aucun binaire brotli installé sur cette machine. Les fichiers sortent environ 7 % plus gros que ce que brotli produirait, et le temps serveur est le cinquième de ce que coûte brotli à la volée. Cet échange valait la peine d'être fait maintenant plutôt que d'attendre une réponse plus élégante.

La version est dans le nom du fichier

La construction écrit style.css.<mtime>.gz, et le ?v= du balisage est cette même date de modification. La réécriture ne se déclenche que si un fichier portant le bon nombre existe.

Cet arrangement a une propriété qu'il vaut la peine de concevoir exprès : si vous modifiez la feuille de style et oubliez de reconstruire, le nombre dans le balisage pointe vers un fichier qui n'existe pas, la réécriture ne se déclenche pas et Apache sert normalement l'original. Le pire des cas, c'est que l'accélération manque. Une feuille de style périmée ne peut pas sortir. Tout dispositif de cache devrait être confronté à cette question — quand ça tourne mal, est-ce que ça devient lent ou est-ce que ça devient faux ?

Le défaut au milieu de tout ça

Le fichier servi est déjà en gzip, il ne doit donc pas être compressé une seconde fois en sortie. La configuration portait d'abord no-gzip, ce qui arrête l'un des deux compresseurs d'Apache. L'autre, mod_brotli, recompressait joyeusement en brotli le fichier gzip terminé, pendant que l'en-tête de réponse continuait d'annoncer gzip.

Les navigateurs recevaient un contenu illisible. Ce n'est pas en regardant la page que cela a été trouvé — c'est en additionnant les octets et en tombant sur un nombre qui n'avait aucun sens. Les deux sont nécessaires, no-gzip et no-brotli, et un seul des deux est l'évident.