La compression gzip réduit-elle vraiment de 70% le poids de vos pages web ?

Qu'est-ce que la compression gzip et pourquoi Google en parle-t-il ?

La compression gzip est une méthode de compression de données qui intervient côté serveur. Quand un navigateur demande une page, le serveur compresse les fichiers texte (HTML, CSS, JavaScript) avant de les envoyer. Le navigateur décompresse ensuite ces fichiers pour les afficher.

Google mentionne cette technique parce qu'elle impacte directement la vitesse de chargement des pages, un facteur de ranking depuis des années. Les Core Web Vitals intègrent notamment le LCP (Largest Contentful Paint), qui mesure le temps d'affichage du plus gros élément visible. Moins de données à transférer = affichage plus rapide.

Pourquoi parle-t-on de 70% de réduction ?

Les fichiers texte comme le HTML ou le CSS contiennent beaucoup de répétitions et de redondances. Les algorithmes de compression comme gzip exploitent ces patterns pour réduire drastiquement la taille. Un fichier HTML de 100 Ko peut facilement descendre à 30 Ko une fois compressé.

Ce taux de 70% est une moyenne observée sur des fichiers texte classiques. Dans la pratique, le gain varie : un HTML bien structuré peut atteindre 75-80%, tandis qu'un CSS déjà minifié et optimisé sera compressé à 60-65%. Les fichiers JavaScript verbeux bénéficient particulièrement de cette compression.

Tous les serveurs activent-ils gzip par défaut ?

Non, et c'est là que ça coince. De nombreux hébergements mutualisés ne l'activent pas d'office, ou le configurent mal. Certains serveurs compressent uniquement le HTML, oubliant les CSS et JS. D'autres appliquent gzip aux mauvais types MIME, gaspillant des cycles CPU sur des formats déjà compressés comme les images JPEG ou PNG.

Les serveurs modernes comme Nginx ou Apache (versions récentes) supportent gzip, mais il faut souvent l'activer manuellement via la configuration. Les CDN comme Cloudflare ou Fastly l'activent automatiquement, ce qui explique pourquoi un site sur CDN charge souvent plus vite qu'un site hébergé classiquement.

• Gzip compresse les fichiers texte (HTML, CSS, JavaScript) avant transfert entre serveur et navigateur
• Réduction typique de 60 à 75% de la taille des fichiers, selon le contenu et la structure
• Impact direct sur les Core Web Vitals, notamment le LCP et le Time to First Byte (TTFB)
• Activation manuelle souvent nécessaire selon l'hébergement, vérification obligatoire
• Alternative moderne : Brotli, qui offre 15-20% de compression supplémentaire mais nécessite HTTPS

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, le gain de 70% est parfaitement réaliste sur des fichiers HTML et CSS non minifiés. J'ai personnellement mesuré des compressions allant de 68% à 82% sur des sites d'actualité ou e-commerce avec beaucoup de balisage sémantique. Les sites WordPress avec des thèmes verbeux et des builders comme Elementor ou Divi voient souvent des gains supérieurs à 75%.

Par contre, Google reste flou sur un point : gzip seul ne suffit pas. Si ton HTML pèse 500 Ko parce qu'il embarque des scripts inline et du CSS critique non optimisé, même avec 70% de compression, tu te retrouves avec 150 Ko à transférer. La minification préalable et l'optimisation du code restent indispensables.

Quelles nuances faut-il apporter à cette affirmation ?

Première nuance : gzip n'est plus la seule option. Brotli (compression développée par Google lui-même) offre des taux de compression supérieurs de 15 à 25% par rapport à gzip, surtout sur du texte structuré. Mais Brotli nécessite HTTPS et un support serveur récent. [À vérifier] : Google ne dit pas pourquoi il continue de pousser gzip alors que Brotli est supérieur.

Deuxième nuance : la compression consomme du CPU côté serveur. Sur un hébergement mutualisé déjà saturé, activer gzip peut ralentir le TTFB si le serveur peine à compresser à la volée. Les serveurs modernes gèrent ça très bien, mais sur du vieux matériel ou des configurations sous-dimensionnées, ça peut créer un goulot d'étranglement.

Dans quels cas cette règle ne s'applique-t-elle pas pleinement ?

Gzip n'apporte rien sur les images, vidéos ou polices déjà compressées. Compresser un JPEG ou un WOFF2 avec gzip ne réduit leur poids que de 1 à 3%, voire augmente légèrement la taille. Certains serveurs mal configurés tentent de compresser ces formats, gaspillant du CPU pour zéro bénéfice.

Autre cas limite : les sites avec du contenu déjà sur CDN et minifié. Si ton HTML fait 12 Ko après minification et ton CSS 8 Ko, le gain absolu de gzip sera faible en valeur absolue (même si le pourcentage reste élevé). À ce stade, l'optimisation prioritaire devient le nombre de requêtes HTTP, le cache navigateur, ou le préchargement des ressources critiques.

Comment vérifier si gzip est activé sur mon site ?

La méthode la plus simple : utilise les outils de développement de Chrome (F12 > Network > Headers). Charge une page, clique sur la requête du document HTML, et regarde la section "Response Headers". Si tu vois Content-Encoding: gzip, c'est actif. Sinon, ça ne l'est pas.

Alternative : des outils en ligne comme GiftOfSpeed ou Varvy testent la compression automatiquement. Ils te donnent le poids non compressé vs compressé, et le taux de réduction obtenu. Si le taux est inférieur à 50%, soit gzip n'est pas actif, soit tes fichiers sont déjà très légers ou mal structurés pour la compression.

Que faut-il faire concrètement pour activer gzip ?

Sur Apache, ajoute ces lignes dans ton fichier .htaccess ou dans la config du VirtualHost. Le module mod_deflate doit être activé côté serveur. Si tu es sur un hébergement mutualisé, contacte le support pour vérifier que le module est disponible.

Sur Nginx, la configuration se fait dans le fichier nginx.conf ou dans le bloc server de ton site. Active gzip on; et définis les types MIME à compresser : gzip_types text/plain text/css application/json application/javascript text/xml application/xml. Redémarre Nginx après modification.

Quelles erreurs éviter lors de la mise en place ?

Ne compresse pas les fichiers déjà compressés comme les images (JPEG, PNG, WebP), les vidéos (MP4, WebM), ou les polices modernes (WOFF2). Ça consomme du CPU pour rien et peut même légèrement augmenter la taille finale. Vérifie que ta config gzip ou Brotli cible uniquement les types MIME texte.

Autre erreur fréquente : compresser des fichiers trop petits. Gzip ajoute un overhead de quelques octets. Compresser un fichier de 300 octets peut donner un résultat compressé de 320 octets. Configure un seuil minimum (par exemple 1024 octets) en dessous duquel la compression ne s'applique pas.

• Vérifier dans les DevTools Chrome que Content-Encoding: gzip ou br apparaît dans les headers de réponse
• Activer gzip sur Apache via mod_deflate ou sur Nginx via gzip on; dans la config
• Limiter la compression aux types MIME texte : HTML, CSS, JavaScript, XML, JSON, SVG
• Exclure explicitement les formats déjà compressés : images, vidéos, polices WOFF2
• Configurer un seuil minimum (1 Ko) pour éviter de compresser des fichiers trop légers
• Tester le site après activation pour détecter d'éventuels bugs d'affichage ou erreurs de double compression