Votre site envoie peut-être trois fois plus d'octets que nécessaire
Un fichier HTML, une feuille CSS ou un bundle JavaScript sont du texte, et le texte se compresse remarquablement bien : 300 ko peuvent voyager en 60 ko sans perdre un seul caractère. Pourtant, beaucoup de sites servent encore leurs ressources brutes, ou se contentent d'un gzip configuré il y a dix ans et jamais revu. Résultat : un LCP qui traîne et un PageSpeed qui affiche l'alerte « Activer la compression de texte ».
Dans cet article, vous allez découvrir :
- •Ce que la compression HTTP réduit vraiment (et pourquoi vos images n'y gagnent rien)
- •La différence concrète entre Brotli et gzip, sans jargon inutile
- •Les gains à attendre, en ordre de grandeur, sur un site Next.js ou WordPress typique
- •La méthode en 30 secondes pour vérifier que la compression est active sur votre site
- •Ce que Vercel, Cloudflare et les serveurs classiques font (ou ne font pas) par défaut, et le lien avec le cache navigateur
Une ligne de configuration, zéro changement de code, jusqu'à 80 % d'octets en moins sur chaque fichier texte : la compression HTTP est l'optimisation au meilleur rapport effort/gain du web.
La compression HTTP, c'est quoi exactement ?
La compression HTTP est un mécanisme par lequel le serveur compresse une réponse avant de l'envoyer, et le navigateur la décompresse à la réception. Le contenu est strictement identique à l'arrivée ; seul le volume transféré sur le réseau change.
Tout repose sur deux en-têtes HTTP. Le navigateur annonce ce qu'il sait décompresser avec Accept-Encoding: gzip, deflate, br. Le serveur choisit un algorithme parmi ceux proposés et le déclare dans sa réponse avec Content-Encoding: br (Brotli) ou Content-Encoding: gzip. S'il n'y a pas d'en-tête Content-Encoding, la réponse est partie en clair.
Ce qu'elle compresse : tout ce qui est du texte
La compression HTTP agit sur les ressources textuelles, c'est-à-dire tout ce qui contient beaucoup de répétitions et de motifs prévisibles :
- •HTML : balises répétées, attributs, classes CSS dupliquées sur chaque élément
- •CSS : sélecteurs, propriétés, valeurs qui reviennent des centaines de fois
- •JavaScript : noms de fonctions, mots-clés du langage, code de framework
- •JSON : réponses d'API, données hydratées par Next.js dans la page
- •SVG : les icônes et illustrations vectorielles sont du XML, donc du texte
Sur ces formats, les taux de réduction se situent couramment entre 60 et 80 %. Un bundle JavaScript de framework, très répétitif, est souvent celui qui gagne le plus.
Ce qu'elle ne compresse pas : les formats déjà compressés
Une image JPEG, WebP ou AVIF, une vidéo MP4, un PDF ou une police WOFF2 ont déjà subi une compression spécialisée, bien plus efficace que gzip ou Brotli sur ce type de données. Les recompresser ne fait rien gagner, consomme du CPU et peut même produire un fichier plus gros. C'est pourquoi les serveurs et CDN sérieux n'appliquent la compression qu'à une liste de types MIME texte.
Le poids des images se traite ailleurs : formats modernes, redimensionnement, chargement différé. Nous détaillons ces leviers dans notre guide sur la vitesse de chargement et les Core Web Vitals, qui classe les actions par impact.
Brotli vs gzip : les différences qui comptent
Brotli et gzip sont deux algorithmes de compression sans perte utilisés pour la compression HTTP ; Brotli produit des fichiers plus petits que gzip sur le texte web, au prix d'une compression plus lente aux niveaux élevés. Les deux sont supportés par la totalité des navigateurs actuels.
| Critère | gzip | Brotli |
|---|---|---|
| Année et origine | 1992, algorithme DEFLATE | 2015, Google, standardisé dans la RFC 7932 |
| En-tête Content-Encoding | gzip | br |
| Niveaux de compression | 1 à 9 | 0 à 11 |
| Dictionnaire intégré | Non | Oui, environ 120 ko de motifs web courants |
| Taille finale sur du texte web | Référence | Typiquement 15 à 25 % plus petit que gzip |
| Vitesse de compression | Rapide à tous les niveaux | Rapide jusqu'au niveau 5, lente au-delà |
| Vitesse de décompression | Très rapide | Très rapide, comparable à gzip |
| Support navigateur | Universel | Universel depuis 2017 (Chrome, Firefox, Safari, Edge) |
| Contrainte | Aucune | Nécessite HTTPS |
gzip : le standard historique, encore parfaitement valable
gzip repose sur DEFLATE, qui combine LZ77 (remplacer les séquences répétées par des références) et le codage de Huffman (coder court les symboles fréquents). Il est partout : chaque serveur, chaque proxy, chaque langage sait le produire et le lire.
Position ferme : un site qui sert du gzip correctement configuré n'est pas un site mal optimisé. Le passage à Brotli est un gain incrémental, pas une révolution. Le vrai problème, c'est l'absence totale de compression, encore fréquente sur des hébergements mutualisés mal réglés.
Brotli : un dictionnaire qui connaît déjà le web
La force de Brotli tient à son dictionnaire statique intégré : des milliers de fragments fréquents sur le web, balises HTML, propriétés CSS, mots-clés JavaScript, mots courants en plusieurs langues. Quand Brotli rencontre <div class="container">, il n'a pas besoin de l'apprendre, il le référence directement.
Brotli dispose aussi d'une fenêtre de recherche bien plus large que gzip (jusqu'à 16 Mo contre 32 ko), ce qui lui permet de repérer des répétitions éloignées dans un gros bundle. La spécification complète est publique dans la RFC 7932 de l'IETF.
Compression statique ou dynamique : la nuance qui change tout
Le niveau 11 de Brotli donne les fichiers les plus petits, mais il est lent : impossible de l'appliquer à la volée sur chaque requête sans faire grimper le TTFB. La bonne pratique distingue deux cas :
- •Ressources statiques (CSS, JS, SVG) : compresser une seule fois au build, au niveau maximal, et servir le fichier
.brpré-compressé. - •Réponses dynamiques (HTML généré à la demande, JSON d'API) : compresser à la volée à un niveau modéré, Brotli 4 ou 5, ou gzip 6. Le temps de réponse reste court pour une perte de gain marginale.
Les gains réels, en ordre de grandeur
Les chiffres ci-dessous sont des ordres de grandeur sur des ressources web typiques ; le résultat exact dépend du contenu, un fichier très répétitif se compressant mieux qu'un fichier déjà minifié.
| Ressource | Non compressé | gzip (niveau 6) | Brotli (niveau 11) |
|---|---|---|---|
| Page HTML d'un blog | 80 ko | 15 à 20 ko | 12 à 16 ko |
| Feuille CSS d'un site vitrine | 150 ko | 25 à 35 ko | 20 à 28 ko |
| Bundle JavaScript de framework | 500 ko | 140 à 170 ko | 115 à 140 ko |
| Réponse JSON d'une API | 200 ko | 25 à 40 ko | 20 à 32 ko |
| Image WebP de 300 ko | 300 ko | 300 ko | 300 ko |
L'effet sur les Core Web Vitals
La compression influence directement le LCP et le FCP : le HTML arrive plus vite, le CSS critique se télécharge plus tôt, le navigateur peut commencer à peindre. Elle n'a aucun effet sur le CLS, et presque aucun sur l'INP : un bundle de 500 ko compressé en 120 ko pèse toujours 500 ko une fois décompressé dans le moteur JavaScript.
Pour comprendre comment chaque métrique se mesure et quels seuils Google retient, notre guide complet sur les Core Web Vitals détaille les trois indicateurs et leurs leviers respectifs.
Vérifier que la compression est active sur votre site
Méthode 1 : les outils de développement du navigateur
- 1.Ouvrez votre site dans Chrome ou Firefox, puis les outils de développement (F12 ou Cmd+Option+I sur Mac).
- 2.Allez dans l'onglet Réseau (Network) et rechargez la page.
- 3.Cliquez sur la première ligne, le document HTML, puis sur l'onglet En-têtes (Headers).
- 4.Dans la section des en-têtes de réponse, cherchez
content-encoding. Vous devez lirebrougzip. - 5.Répétez sur un fichier
.csset un fichier.js.
Méthode 2 : une commande curl
Pour vérifier depuis un terminal, sans navigateur :
curl -sI -H "Accept-Encoding: br, gzip" https://votre-site.fr/ | grep -i content-encodingSi la commande ne renvoie rien, la page est servie sans compression. Remplacez l'URL par celle d'un CSS ou d'un JS pour tester un fichier précis.
Méthode 3 : PageSpeed Insights et Lighthouse
Dans les diagnostics de PageSpeed Insights, l'audit « Activer la compression de texte » liste chaque ressource texte servie sans compression, avec le gain estimé en ko. S'il n'apparaît pas, tout est en ordre. Lighthouse ne distingue pas gzip de Brotli : il vérifie seulement qu'une compression est présente.
Ce que Vercel, les CDN et les serveurs font par défaut
Le comportement par défaut varie énormément selon l'hébergement, et c'est là que beaucoup de sites perdent du terrain sans le savoir.
Vercel : Brotli et gzip activés, rien à configurer
Sur Vercel, le réseau edge compresse automatiquement toutes les réponses de type texte selon l'en-tête Accept-Encoding du navigateur : Brotli quand il est supporté, gzip en repli. Cela couvre les fichiers statiques, les pages générées par Next.js et les réponses des fonctions serverless, sans rien à activer.
C'est l'une des raisons pour lesquelles un site Next.js déployé sur Vercel part avec une base de performance saine. Dans nos projets de création de sites internet, la compression est acquise dès le premier déploiement, et l'effort se concentre sur ce qui reste à optimiser : le poids des images et la quantité de JavaScript.
Cloudflare, Netlify et les autres CDN
Cloudflare active Brotli par défaut sur tous les plans, y compris gratuit ; Netlify fait de même pour les ressources statiques. Placer un CDN moderne devant votre site règle la question, même si le serveur d'origine ne compresse rien.
Nginx, Apache et les hébergements classiques
Ici, rien n'est garanti. Nginx active gzip de façon minimale par défaut (souvent sur le seul HTML), et Brotli nécessite le module ngx_brotli, absent des paquets standards. Apache demande d'activer mod_deflate pour gzip et mod_brotli pour Brotli, puis de lister les types MIME concernés. Sur un mutualisé WordPress, tout dépend de l'hébergeur et du plugin de cache : c'est le cas de « compression absente » le plus fréquent en audit.
Next.js auto-hébergé
Avec next start sur votre propre serveur, Next.js applique gzip par défaut via l'option compress, mais pas Brotli. Pour en bénéficier, désactivez la compression de Next.js et confiez-la à un reverse proxy : Nginx avec ngx_brotli, ou Caddy qui gère Brotli et gzip nativement.
Compression et cache navigateur : deux leviers complémentaires
La compression et le cache navigateur attaquent le même problème sous deux angles différents. La compression réduit le poids de chaque transfert ; le cache évite de refaire le transfert. Le premier agit sur la première visite, le second sur toutes les suivantes.
Un site bien réglé combine les deux : un bundle JavaScript compressé en Brotli au niveau 11, servi avec un en-tête Cache-Control de longue durée et un nom de fichier versionné. Le visiteur le télécharge une fois, léger, puis plus jamais jusqu'au prochain déploiement.
Un détail mérite attention à la rencontre des deux : l'en-tête Vary: Accept-Encoding. Il indique aux caches intermédiaires que la réponse diffère selon l'algorithme accepté ; sans lui, un CDN pourrait servir du Brotli à un client qui ne le lit pas. Les plateformes modernes le gèrent seules ; sur un Nginx configuré à la main, il faut y penser.
À lire aussi : Cache navigateur : accélérer son site - Comment régler Cache-Control, ETag et le versionnage des fichiers pour que vos visiteurs ne téléchargent chaque ressource qu'une seule fois.
Les erreurs qui annulent le bénéfice
Activer la compression est simple. La mal configurer est tout aussi simple. Les cas que nous voyons le plus souvent :
- •Compresser les images et les polices WOFF2 : aucun gain, du CPU gaspillé, et parfois des fichiers plus gros. La liste des types MIME compressés doit se limiter au texte.
- •Compresser dynamiquement au niveau maximal : Brotli 11 à la volée sur chaque page HTML fait exploser le temps de réponse serveur. Niveau 4 ou 5 pour le dynamique, niveau 11 uniquement en pré-compression au build.
- •Oublier les réponses d'API et le JSON : la compression est réglée sur les fichiers statiques, mais le reverse proxy ne compresse pas les routes
/api/. Résultat : les plus gros transferts du site passent en clair. - •Confondre minification et compression : la minification retire les espaces et raccourcit les noms de variables dans le code source ; la compression HTTP agit sur le transfert. Les deux se cumulent, l'une ne remplace pas l'autre.
- •S'arrêter là : la compression ne corrige pas un bundle JavaScript de 2 Mo. Elle réduit le symptôme, pas la cause.
FAQ : vos questions sur Brotli et gzip
Sur une application web sur-mesure, la compression des réponses d'API et du JSON pèse souvent plus que celle des fichiers statiques : nous la configurons dès l'architecture, pas après la mise en ligne.
Faut-il choisir entre Brotli et gzip ?
Accept-Encoding, et le serveur choisit le meilleur disponible. Brotli sera retenu dans la quasi-totalité des cas aujourd'hui, gzip reste en repli pour les clients anciens, certains robots ou les connexions en HTTP non sécurisé.Brotli fonctionne-t-il sans HTTPS ?
La compression ralentit-elle le serveur ?
La compression HTTP améliore-t-elle le SEO ?
Compressez d'abord, optimisez ensuite
La compression HTTP est le premier réglage à vérifier sur un site lent, parce que c'est le moins cher à corriger : aucune ligne de code à réécrire, un en-tête à contrôler, une configuration à ajuster. Brotli apporte 15 à 25 % de mieux que gzip, mais l'écart qui compte vraiment sépare un site compressé d'un site qui ne l'est pas.
Une fois la compression confirmée, le travail de fond commence : réduire le JavaScript livré, soigner les images, régler le cache.
Vous avez un doute sur la configuration de votre site, ou votre PageSpeed affiche encore « Activer la compression de texte » ? Parlons de votre projet : nous auditons la chaîne complète, du serveur au navigateur, et nous vous disons précisément quoi corriger.
