gzip vs Brotli : ce que vaut vraiment la différence, et pourquoi un tiers des sites publics n'envoient toujours rien de compressé

  • vuetelemetry
  • Guides
  • 7 min de lecture

Brotli compresse mieux le texte que gzip, avec un écart réel mais plus faible que ne le laisse croire le discours commercial. Le constat le plus important est ailleurs : sur 336 organismes publics mesurés, 107 de ceux qui ont répondu envoient leur page d'accueil sans aucune compression.

La comparaison est généralement présentée comme un choix, et pour un nouveau déploiement c'en est un. Pour la plupart des sites existants, ce n'en est pas un, parce que la vraie question est de savoir si quoi que ce soit est compressé.

Ce que nous avons mesuré, et ce que cela coûte

Un concasseur industriel à mâchoires jaune et noir photographié en contre-plongée dans un hall d'usine, sa lourde mâchoire d'acier et son volant d'entraînement occupant le cadre.
Un concasseur industriel à mâchoires jaune et noir photographié en contre-plongée dans un hall d'usine, sa lourde mâchoire d'acier et son volant d'entraînement occupant le cadre.

Nous avons mesuré 336 organismes publics portugais le 6 septembre 2026, une requête chacun, en ne lisant que les en-têtes de réponse et la taille du HTML transmis. 291 ont répondu. 107 d'entre eux, soit 36,8 %, envoyaient leur page d'accueil sans aucun encodage de contenu.

Le coût n'a rien de théorique. Parmi les sites qui compressent, la page d'accueil médiane pèse 29 312 octets transmis. Parmi ceux qui ne compressent pas, la médiane est de 109 705 octets. C'est 3,7 fois plus de données pour le même type de page, et dix-huit des sites non compressés dépassent 200 Ko de HTML à eux seuls, le plus lourd atteignant 536 245 octets.

La comparaison elle-même

Passons à la comparaison elle-même. gzip est pris en charge partout depuis les années 1990 et reste le choix par défaut sûr. Brotli, normalisé en 2016, est pris en charge par tous les navigateurs actuels en HTTPS et produit généralement un résultat plus petit sur le texte, le gain portant surtout sur le HTML, le CSS et le JavaScript plutôt que sur les formats déjà compressés.

  • curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding
  • Aucune ligne content-encoding : rien n'est compressé
  • content-encoding: br signifie que Brotli a été négocié, gzip signifie le repli
  • Testez en HTTPS : les navigateurs ne proposent pas Brotli en HTTP simple
  • Limitez la compression aux types texte ; images et vidéos n'y gagnent rien

La façon honnête d'énoncer l'écart est que Brotli gagne sur le texte et que la marge varie avec le contenu et le niveau de compression choisi. Quiconque vous cite un pourcentage universel unique vous cite un banc d'essai, pas votre site. Mesurez le vôtre : cela prend une requête.

Les niveaux comptent plus que l'algorithme

Le réglage du niveau compte plus que le choix de l'algorithme, et c'est là que se trouvent la plupart des erreurs de configuration. Brotli propose les niveaux 0 à 11. Le niveau 11 est assez lent pour que son usage sur des réponses générées à la volée coûte plus de temps serveur qu'il n'en fait gagner au transfert. L'organisation habituelle est un niveau élevé pour les ressources statiques compressées une fois à la construction, et un niveau modéré pour tout ce qui est généré à chaque requête.

gzip a la même structure avec les niveaux 1 à 9, et le même piège : le niveau maximal est rarement le bon pour du contenu dynamique.

Négociation, HTTPS, et ce qu'il ne faut pas compresser

La négociation de contenu décide lequel est utilisé, et ce n'est pas votre seul choix. Le navigateur envoie `Accept-Encoding: gzip, deflate, br` et le serveur choisit. Configurer les deux signifie que les clients modernes reçoivent Brotli et que tout le reste se replie sur gzip, et c'est pourquoi ce n'est pas vraiment un choix exclusif.

Un détail pratique qui piège souvent : les navigateurs ne proposent Brotli qu'en HTTPS. Un site testé en HTTP simple semblera ne pas prendre en charge Brotli alors qu'il le fait.

Compresser des formats déjà compressés est du travail perdu. JPEG, PNG, WebP, MP4 et la plupart des formats de police ne gagnent rien et coûtent du processeur. Limitez la compression aux types MIME texte, ce qui est le réglage par défaut de la plupart des configurations raisonnables et la première chose à vérifier dans les autres.

**Compresser des formats déjà compressés est du travail perdu.** JPEG, PNG, WebP, MP4 et la plupart des formats de police ne gagnent rien et coûtent du processeur. Limitez la compression aux types MIME texte, ce qui est le réglage par défaut de la plupart des configurations raisonnables et la première chose à vérifier dans les autres.

- vuetelemetry

Vérifier votre site en une requête

Vérifier votre propre site tient en une commande, et c'est celle que nous avons lancée 336 fois :

FAQ

Brotli est-il toujours meilleur que gzip ?

Sur le texte, Brotli produit en général un résultat plus petit que gzip à réglages comparables, et l'écart dépend du contenu et du niveau choisi. Il n'est pas meilleur sur les formats déjà compressés comme le JPEG ou le MP4, où aucun des deux algorithmes n'aide. Configurer les deux est la réponse normale, puisque le navigateur négocie celui qu'il reçoit.

Comment vérifier si mon site compresse quelque chose ?

Envoyez une requête avec un en-tête Accept-Encoding et lisez la réponse : curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding. Si aucune ligne content-encoding ne revient, rien n'est compressé.

Pourquoi mon site n'utilise-t-il pas Brotli alors que le serveur le prend en charge ?

La raison la plus fréquente est que vous avez testé en HTTP simple. Les navigateurs n'annoncent Brotli qu'en HTTPS, donc un test en HTTP fait passer un serveur correctement configuré pour un serveur qui ne le prend pas en charge. La deuxième raison la plus fréquente est que le module de compression est activé mais limité à une liste de types MIME qui n'inclut pas votre type de contenu.

Faut-il utiliser le niveau de compression maximal ?

Pour les ressources statiques compressées une fois à la construction, un niveau élevé est raisonnable puisque le coût est payé une seule fois. Pour les réponses générées à chaque requête, les niveaux les plus élevés peuvent coûter plus de temps serveur que le transfert qu'ils économisent. Un niveau modéré pour le contenu dynamique et un niveau élevé pour les fichiers statiques est l'organisation habituelle.

Combien coûte réellement l'absence de compression ?

Dans notre mesure de 291 organismes publics ayant répondu le 6 septembre 2026, la page d'accueil médiane pesait 29 312 octets transmis quand la compression était active et 109 705 octets quand elle ne l'était pas, un facteur de 3,7 pour des pages comparables. Dix-huit sites non compressés dépassaient 200 Ko de HTML à eux seuls.

Stack liée