La compression gzip est l’un des réglages les plus simples à vérifier quand une page web charge trop lentement. Chez GreenCodeLab, agence web éco-responsable, on la regarde comme une brique de base : utile, mesurable, mais jamais suffisante pour sauver un site obèse. Elle réduit les fichiers textuels envoyés au navigateur, donc moins de données circulent pour afficher le même contenu.
Définition de la compression Gzip
La compression Gzip est une compression sans perte appliquée surtout aux ressources textuelles d’un site web : HTML, CSS, JavaScript, XML, JSON ou SVG. Le serveur compresse la ressource avant de l’envoyer, puis le navigateur la décompresse sans intervention visible côté utilisateur. Le fichier affiché reste identique à l’original.
Bon, le nom prête parfois à confusion. Un fichier .gz stocké sur un serveur et une réponse HTTP envoyée avec Content-Encoding: gzip ne désignent pas exactement le même geste. Dans le second cas, ce qui compte est le transfert.
Dans une logique d’écoconception web, Gzip sert donc à éviter un gaspillage assez bête : envoyer du texte brut alors qu’il peut être compacté proprement.
Comment Gzip fonctionne sur une page web
Le mécanisme tient en quelques en-têtes HTTP. Pas besoin de transformer cette fiche en manuel Apache, sinon on perd le lecteur en route.
- Le navigateur demande une ressource et annonce ce qu’il accepte avec
Accept-Encoding, par exemplegzip,broudeflate. - Le serveur, le CDN ou le cache choisit un encodage disponible.
- La réponse indique
Content-Encoding: gzipsi Gzip est utilisé. - Un en-tête
Vary: Accept-Encodingaide les caches à servir la bonne version selon le navigateur.
Pour l’utilisateur, rien ne change visuellement. La page ne devient pas différente. Elle arrive juste avec moins de poids transféré. C’est discret. C’est justement ce qu’on veut.
Selon la pile technique, l’activation passe par mod_deflate sur Apache, la directive gzip sur Nginx, une option CDN, une couche de cache ou un plugin WordPress sérieux. Le piège habituel : croire que l’option est active sans l’avoir vérifiée.
Quels fichiers faut-il compresser avec Gzip ?
La règle est simple : Gzip est intéressant pour le texte, rarement pour ce qui est déjà compressé. Recompresser une image WebP ou une archive ZIP, c’est souvent du bruit pour presque rien. Parfois même une perte de temps CPU.
| Type de ressource | Gzip utile ? | Pourquoi |
|---|---|---|
| HTML, CSS, JavaScript | Oui | Ces fichiers contiennent beaucoup de répétitions et se compressent bien. |
| JSON, XML, SVG | Oui, selon configuration | Ce sont des formats textuels, souvent très compressibles. |
| Polices web | Parfois | Certaines polices sont déjà servies dans des formats optimisés. |
| JPEG, PNG, WebP, AVIF | Non | Ces formats d’image ont déjà leur propre compression. |
| MP4, PDF, ZIP | Non ou rarement | Le gain est faible, et la double compression peut être contre-productive. |
| Ressources externes | Pas directement | Vous ne contrôlez pas toujours les en-têtes d’un script ou d’une police tiers. |
Les petits fichiers méritent aussi un peu de nuance. Compresser un micro-fichier de quelques centaines d’octets ne change pas grand-chose. Les ressources externes sont plus frustrantes : si un outil tiers sert son script sans compression, votre serveur ne peut pas corriger ça à sa place.
Pourquoi la compression Gzip améliore la performance web
Moins d’octets sur le réseau, c’est moins d’attente avant que le navigateur commence vraiment son travail. Le gain se voit surtout sur mobile, en 4G moyenne, sur Wi-Fi saturé ou quand le serveur est loin. Pas glamour. Très concret.
La compression Gzip peut aider le temps de chargement global et certains signaux liés aux Core Web Vitals, notamment quand une ressource bloquante arrive plus vite. Elle ne garantit pas un bon LCP à elle seule. Si votre image principale pèse 900 Ko, si votre JavaScript bloque le rendu ou si le DOM part dans tous les sens, Gzip ne fera pas de miracle.
Point de méthode
Je préfère être net là-dessus : activer Gzip est une base, pas une stratégie de performance. La bonne approche combine compression, minification, cache, budget de poids de page, limitation des dépendances et mesure régulière. Sinon on se retrouve avec un site compressé, certes, mais toujours trop lourd. Le résultat ? Décevant.
Le lien avec le SEO est indirect. Une page plus rapide améliore l’expérience, limite certains abandons et aide à mieux passer les audits techniques. Mais promettre un gain de positions juste parce que Content-Encoding: gzip apparaît dans les en-têtes, c’est vendre du rêve.
Gzip, Brotli et Deflate : quelles différences ?
Gzip reste très compatible. C’est son grand intérêt. La plupart des navigateurs, serveurs, proxies et CDN savent le gérer depuis longtemps.
Deflate désigne l’algorithme de compression historique utilisé dans l’écosystème Gzip. Dans le web, on le croise aussi comme valeur d’encodage HTTP, mais il est moins souvent le choix principal aujourd’hui.
Brotli, lui, compresse souvent mieux les assets textuels modernes, surtout lorsqu’ils sont pré-compressés et servis via CDN. Si votre infrastructure le supporte correctement, Brotli peut être le meilleur choix pour CSS, JavaScript et HTML. Mais Gzip garde un rôle de filet de sécurité très pratique. En gros : Brotli quand il est disponible, Gzip en fallback propre.
Le vrai choix dépend du serveur, du CDN, du cache, du navigateur et de la manière dont les fichiers sont générés. Là encore, testez. Ne supposez pas.
Comment vérifier si Gzip est activé
Le contrôle le plus fiable consiste à regarder les en-têtes de réponse d’une ressource servie par votre domaine. Dans les DevTools du navigateur, ouvrez l’onglet Réseau, rechargez la page, cliquez sur un fichier HTML, CSS ou JS, puis cherchez :
Content-Encoding: gzip, ou parfoisbrsi Brotli est utilisé ;Vary: Accept-Encoding, utile pour les caches ;- une taille transférée plus faible que la taille non compressée.
Les audits Lighthouse, PageSpeed Insights ou GTmetrix peuvent aussi afficher une alerte du type « enable text compression ». C’est pratique pour repérer un problème, mais il faut ensuite vérifier fichier par fichier. Les faux positifs arrivent avec les CDN, les caches intermédiaires, les petits fichiers et les scripts tiers.
Un bon réflexe : testez une page HTML, un fichier CSS, un fichier JS et une réponse JSON si votre site en sert. Pas seulement la page d’accueil.
Compression Gzip et écoconception web
La compression Gzip s’inscrit bien dans une démarche de sobriété numérique, parce qu’elle réduit le poids transféré à service identique. Moins de bande passante consommée, moins d’attente, moins d’octets inutiles qui traversent le réseau. C’est cohérent avec une lecture EcoIndex, où le poids de page fait partie des signaux à surveiller.
Mais il y a une limite que les audits oublient parfois : compresser un excès ne supprime pas l’excès. Un site qui charge 700 Ko de JavaScript inutile reste mal conçu, même si le transfert descend fortement grâce à Gzip ou Brotli. La question adulte reste entière : pourquoi ces fichiers sont-ils aussi lourds au départ ?
Gzip est-il encore utile avec Brotli ?
Oui. Brotli peut mieux compresser certains fichiers textuels, mais Gzip reste un excellent fallback. Sur beaucoup de stacks, les deux cohabitent très bien.
La compression Gzip améliore-t-elle le SEO ?
Pas directement. Elle peut améliorer la vitesse perçue et la qualité technique, ce qui soutient l’expérience utilisateur. Le SEO dépend aussi du contenu, de l’intention, du maillage et de nombreux signaux hors compression.
Pourquoi Lighthouse signale-t-il encore « enable text compression » ?
Souvent parce qu’un fichier textuel n’est pas compressé, parce qu’un CDN sert une variante inattendue, ou parce qu’une ressource externe échappe à votre configuration. Regardez les en-têtes avant de changer le serveur au hasard.
Faut-il compresser les images avec Gzip ?
Non, dans la majorité des cas. JPEG, PNG, WebP et AVIF ont déjà leur propre logique de compression. Travaillez plutôt le format, les dimensions, le lazy loading et le poids réel des images.
À retenir
La compression Gzip est une base saine de performance web : elle allège surtout HTML, CSS, JavaScript, JSON, XML et SVG avant le transfert vers le navigateur. Elle se vérifie dans les en-têtes HTTP, pas au feeling.
À activer, oui. À surestimer, non. Pour un site vraiment plus sobre, Gzip doit accompagner une réduction du code, des dépendances et du poids de page. Si votre audit numérique responsable commence par cette vérification, c’est bon signe. S’il s’arrête là, il manque le plus gros du travail.