Comment fonctionne réellement la compression HTTP
Sur le web, la compression est une négociation discrète qui a lieu à chaque requête. Le navigateur annonce ce qu’il sait décompresser dans un en-tête Accept-Encoding — les navigateurs modernes envoient gzip et br. Le serveur en choisit un, compresse le corps de la réponse et l’étiquette avec Content-Encoding pour que le navigateur sache comment le décompresser. Ni le code de votre application ni votre HTML ne changent ; la conversion se fait entièrement en transit.
Le bénéfice est important parce que le texte se compresse extrêmement bien. Une page HTML de 100 Ko voyage couramment à 20 Ko avec Gzip ; un bundle JavaScript fond souvent des trois quarts. Pour les visiteurs sur des connexions lentes ou mobiles, cette différence est la partie visible de votre temps de chargement — c’est pourquoi la compression est cette rare optimisation quasi gratuite et presque toujours juste pour le texte.
Ce que Brotli améliore vraiment
L’avantage de Brotli tient à deux choix de conception : un format plus intelligent, et un dictionnaire intégré de chaînes qui apparaissent constamment sur le web — balises HTML, noms de propriétés CSS, tokens JavaScript courants. Le texte web est exactement ce pour quoi il a été réglé, et sur ce terrain Brotli produit généralement des fichiers 15-20 % plus petits que Gzip aux niveaux de compression que les serveurs utilisent en temps réel.
Gardons toutefois le cadre honnête : ces 15-20 % s’ajoutent à la réduction de 70-80 % que Gzip réalise déjà. Si une page voyage à 20 Ko en gzip, Brotli la ramène à environ 16-17 Ko. Cela vaut la peine — le gain se cumule sur chaque ressource et chaque visiteur — mais c’est un raffinement, pas une révolution. Si vous lisez des graphiques de benchmark annonçant des écarts spectaculaires, vérifiez s’ils comparent le niveau le plus lent et le plus poussé de Brotli au réglage par défaut de Gzip ; à ces réglages, Brotli est trop lent pour tourner à chaque requête et sert plutôt à précompresser des fichiers statiques.
La compatibilité a cessé d’être un sujet depuis des années : pratiquement tous les navigateurs actuels envoient br dans leur Accept-Encoding, et la négociation fait que le rare vieux client qui ne le fait pas reçoit simplement du Gzip. Il n’existe aucun scénario perdant pour le visiteur.
Ce qui ne doit jamais être compressé
La règle miroir compte tout autant : compresser des octets déjà compressés gaspille du CPU et rend souvent les fichiers légèrement plus gros. Images (JPEG, PNG, WebP, AVIF), vidéo et audio, polices en WOFF2, archives ZIP, PDF avec images intégrées — leurs formats ont déjà éliminé la redondance. Il ne reste rien à trouver pour Gzip ou Brotli.
C’est pourquoi la compression se configure par type de contenu, et pourquoi une règle globale « tout compresser » est une erreur petite mais réelle. La répartition pratique : types texte activés (HTML, CSS, JS, JSON, XML, SVG), médias binaires désactivés. Le SVG est le seul format d’image qui appartient à la colonne texte — c’est du XML, et il se compresse admirablement.
Où l’exécuter : en périphérie, pas sur votre serveur applicatif
La compression coûte du CPU à chaque réponse, et plus elle s’exécute en aval, moins elle s’exécute souvent. Quand la périphérie compresse, une page mise en cache est compressée une seule fois et c’est la copie compressée qui est servie depuis le cache des milliers de fois — votre origine ne dépense rien, et la périphérie stocke chaque variante que le client peut accepter.
Sur cdn.com.tr, c’est un réglage par règle de diffusion : chaque règle porte une liste de compression (gzip, zip, brotli) que vous activez dans le panneau, à côté des options de cache et d’optimisation de la même règle. Activer Brotli est une case à cocher, pas une migration de serveur — et comme le réglage vit sur la règle, vous pouvez compresser vos pages agressivement tout en laissant tranquille la règle de vos médias déjà compressés, exactement la répartition défendue à la section précédente.
Vérifiez ce que vous envoyez réellement
Les suppositions sur la compression se révèlent fausses assez souvent pour que la vérification mérite ses trente secondes. Demandez une page deux fois avec des offres Accept-Encoding différentes et lisez le Content-Encoding qui revient. Pendant que vous y êtes, comparez les tailles transférées — la différence est votre économie, mesurée plutôt que supposée.
Une réserve quand vous testez à travers un CDN : la périphérie peut avoir mis en cache la variante d’une requête antérieure ; utilisez donc une chaîne de requête « cache-busting » pour observer un comportement frais, et rappelez-vous qu’une copie compressée en cache qui répond instantanément est précisément l’objectif.
Deux requêtes, deux offres — lisez ce qui revient
# what does the server send when offered brotli?
curl -sI -H 'Accept-Encoding: br' https://example.com/ | grep -i content-encoding
# and when offered only gzip?
curl -sI -H 'Accept-Encoding: gzip' https://example.com/ | grep -i content-encoding
# compare actual transferred bytes (compressed vs uncompressed)
curl -so /dev/null -H 'Accept-Encoding: br' -w 'brotli: %{size_download} bytes\n' https://example.com/
curl -so /dev/null -H 'Accept-Encoding: identity' -w 'plain: %{size_download} bytes\n' https://example.com/Questions fréquentes
Dois-je activer Brotli et Gzip ensemble ?
Oui — c’est la configuration normale. La négociation choisit Brotli pour les navigateurs qui proposent br et retombe sur Gzip pour les autres. Activer les deux est une amélioration stricte par rapport à l’un ou l’autre seul.
La compression ralentit-elle mon serveur ?
Elle coûte du CPU, mais aux niveaux utilisés à chaque requête, ce coût est faible face à la bande passante économisée — et quand la périphérie compresse le contenu mis en cache, votre origine ne paie rien du tout : la copie compressée est créée une fois et servie depuis le cache.
Pourquoi mon trafic CDN d’images n’affiche-t-il aucune compression ?
Parce que c’est le comportement correct : JPEG, PNG, WebP et AVIF sont des formats déjà compressés, et les recompresser gaspille du CPU pour un gain nul (parfois négatif). La compression est faite pour le texte. Si vous voulez des images plus légères, le levier est le format et le dimensionnement — la conversion WebP/AVIF — pas le Content-Encoding.
Dois-je modifier le code de mon site pour utiliser Brotli ?
Non. La compression se négocie entre le navigateur et le serveur ou la périphérie à chaque requête ; vos HTML, CSS et JavaScript restent intacts. Sur cdn.com.tr, c’est une option sur la règle de diffusion, et la périphérie s’occupe du reste.