Compression Brotli

Un taux de compression supérieur sur les fichiers texte, de l’ordre de quinze à vingt pour cent de mieux selon le contenu.

Sur une feuille de style ou un fichier de script volumineux, la différence se compte en dizaines de kilooctets par visite. Sur une connexion mobile dégradée, elle devient perceptible.

En contrepartie, la compression au plus haut niveau coûte plus de ressources serveur. C’est pourquoi les fichiers statiques sont généralement compressés une fois à l’avance, au niveau maximal, tandis que le HTML généré à la demande l’est à un niveau intermédiaire.

Les fichiers déjà compressés : images, vidéos, polices modernes, archives.

Les recompresser ne gagne rien et coûte du temps de traitement. C’est une erreur de configuration fréquente sur les serveurs mal réglés.

Le levier sur ces fichiers est ailleurs : format adapté et dimension correcte pour les images, comme décrit côté temps de chargement.

Les outils de développement du navigateur affichent l’en-tête d’encodage de chaque réponse. La valeur attendue est br.

Deux pièges expliquent une absence.

Le serveur ne propose Brotli qu’en chiffré. Sur une page en clair, il retombe sur gzip.

Un réseau de diffusion placé devant peut recompresser à sa manière, et la valeur observée dépend alors de lui plutôt que du serveur d’origine.

Modeste et réel. Il agit sur le temps de transfert, pas sur le temps de réponse du serveur, qui reste le plancher décrit côté TTFB.

Sur un site dont les fichiers texte sont légers, le gain est négligeable. Sur un site lourd en scripts, il devient mesurable.

L’ordre de traitement reste le même : réduire le poids réel avant d’optimiser la compression de ce poids.