Brotli, développé par Google et documenté par la RFC 7932, promet un taux de compression supérieur à celui de gzip, l’algorithme historique intégré depuis longtemps à la quasi-totalité des serveurs web. Sur le papier, l’écart favorise systématiquement Brotli. Sur un catalogue WordPress/WooCommerce de plusieurs milliers de fiches produit, la réalité mesurée en conditions réelles nuance sensiblement cette promesse.
La compression HTTP influence directement deux éléments qui comptent pour le référencement technique : le poids des réponses transférées, qui affecte le temps de chargement perçu côté visiteur, et le temps de réponse serveur, qui pèse sur le TTFB et donc indirectement sur le rythme d’exploration que Google est disposé à consacrer au site.
Protocole de mesure
Le test a porté sur un échantillon de cinq cents fiches produit représentatives du catalogue, servies successivement avec gzip niveau 6 (réglage par défaut de la plupart des configurations Nginx), Brotli niveau 5, et Brotli niveau 9, chacune mesurée sur cent requêtes consécutives avec l’outil en ligne de commande curl combiné à son option -w pour extraire les temps précis.
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" \
-H "Accept-Encoding: br" https://exemple.fr/produit/reference-142/
Résultats mesurés
| Configuration | Poids moyen HTML | TTFB moyen | CPU serveur (pic) |
|---|---|---|---|
| gzip niveau 6 | 38,2 Ko | 210 ms | Référence |
| Brotli niveau 5 | 31,7 Ko | 205 ms | +4 % |
| Brotli niveau 9 | 27,1 Ko | 340 ms | +61 % |
Le niveau 5 de Brotli offre un compromis nettement plus favorable que le niveau 9, souvent recommandé par défaut dans les tutoriels génériques trouvés en ligne. Le gain de poids reste substantiel — 17 % de moins que gzip niveau 6 — sans dégrader le TTFB, contrairement au niveau 9, dont le coût de calcul plus élevé a fini par annuler tout l’intérêt de la compression en allongeant le temps de traitement côté serveur.
Ce que cela change pour le budget de crawl
Un TTFB stable, même à poids réduit, n’accélère pas mécaniquement le rythme d’exploration de Googlebot : le budget de crawl dépend davantage de la disponibilité générale du serveur et de la fraîcheur perçue du contenu que du seul poids des réponses HTTP. En revanche, sur un catalogue de plusieurs milliers de pages, un poids de réponse réduit de 17 % représente un volume de données transférées significativement moindre sur l’ensemble des passages du robot, ce qui allège la charge réseau côté hébergement sans bénéfice direct mesurable sur les positions.
Configurer Nginx sans dégrader les performances
La configuration retenue après ces mesures a fixé Brotli au niveau 5 pour les réponses dynamiques HTML, et au niveau 9 uniquement pour les ressources statiques compressées une seule fois à la publication (CSS, JS), où le coût de calcul ne se répète pas à chaque requête :
brotli on;
brotli_comp_level 5;
brotli_types text/html application/xml;
# Pré-compression des assets statiques, niveau élevé, une seule fois
brotli_static on;
Le niveau de compression choisi compte souvent davantage que l’algorithme lui-même. Un Brotli mal réglé peut faire pire qu’un gzip par défaut.
Prévoir un repli vers gzip pour les clients qui ne supportent pas Brotli
Brotli n’est pas universellement supporté : un client HTTP ancien, un robot d’indexation tiers moins récent, ou une intégration interne qui n’envoie pas l’en-tête Accept-Encoding: br doit continuer de recevoir une réponse compressée en gzip, sans erreur ni contenu non compressé. La configuration Nginx retenue conserve le module gzip actif en parallèle, Nginx choisissant automatiquement l’algorithme selon l’en-tête envoyé par le client :
gzip on;
gzip_comp_level 6;
gzip_types text/html application/xml;
brotli on;
brotli_comp_level 5;
brotli_types text/html application/xml;Un test avec curl, sans l’en-tête Accept-Encoding: br cette fois, confirme que le serveur retombe bien sur gzip plutôt que de servir une réponse non compressée par défaut, un oubli de configuration qui annulerait une partie du bénéfice mesuré pour les clients qui ne demandent pas explicitement Brotli.
Notre verdict
Brotli surpasse gzip sur le poids des réponses, à niveau de compression raisonnable. Le gain sur le TTFB, en revanche, reste marginal et peut même s’inverser si le niveau choisi sollicite excessivement le processeur du serveur. Sur un catalogue volumineux, mieux vaut mesurer plusieurs niveaux de compression sur un échantillon réel avant de généraliser un réglage, plutôt que de suivre une recommandation générique trouvée en ligne.
