Gzip ou Brotli : quelle compression choisir pour ses services Web ?

Dans un écosystème numérique où la vitesse de chargement et la performance web influencent directement l’expérience utilisateur et le référencement naturel (SEO), la question de la compression serveur et son optimisation mérite votre attention. Deux algorithmes dominent actuellement les pratiques : Gzip (ancien standard toujours très utilisé) et Brotli, une alternative plus récente développée par Google. Alors, Gzip ou Brotli : que faut-il choisir pour optimiser la vitesse et l’efficacité de son site web ?

Dans cet article, nous analysons en profondeur les différences, les avantages et les inconvénients de chaque méthode de compression, afin d’identifier la meilleure solution et la bonne implémentation pour les serveurs Web modernes.

---

Pourquoi compresser les fichiers sur le Web ?

Avant d’entrer dans le comparatif Gzip vs Brotli, rappelons pourquoi la compression HTTP est si importante.

La plupart des ressources web sont des fichiers texte (HTML, CSS, JavaScript, JSON, SVG…) qui peuvent être réduits de 60 à 80 % via la compression. Cela permet :

• de réduire la bande passante consommée,
• de diminuer le temps de chargement des pages,
• et d’améliorer le score Core Web Vitals, ce qui impacte directement le référencement sur Google.

L’activation d’un algorithme de compression côté serveur est donc une bonne pratique d’optimisation web incontournable aujourd’hui.

---

Gzip – L’algorithme de compression historique

Présentation de Gzip

Gzip (GNU zip) est un algorithme de compression introduit dans les années 90. Il est devenu un standard de facto sur le Web grâce à sa compatibilité universelle.

Tous les navigateurs modernes, proxies, CDN et clients HTTP supportent Gzip. C’est d’ailleurs pourquoi de nombreux serveurs Web (Apache, Nginx, IIS) proposent son activation par défaut.

Avantages de Gzip

• Compatibilité maximale : Fonctionne avec tous les navigateurs, même les plus anciens.
• Configuration simple sur tous les serveurs classiques.
• Performant pour les fichiers texte compressibles (HTML, CSS, JS…).
• Temps de compression relativement rapide, surtout à des niveaux faibles à moyens (niveau 6 ou 7 recommandés en prod).

Limites de Gzip

• Moins performant que Brotli en termes de ratio de compression (taille finale du fichier).
• Ne compresse pas certains types de fichiers déjà optimisés comme les images WebP, AVIF ou les polices WOFF2.
• Compression à la volée coûteuse en CPU sur des serveurs avec beaucoup de trafic.

---

Brotli – L’alternative moderne signée Google

Origine et conception

Brotli est un algorithme de compression développé par Google en 2015, initialement conçu pour la compression des polices web (WOFF2). Rapidement, il a été étendu à la compression HTTP, notamment via les navigateurs Chrome et Firefox.

Brotli utilise une combinaison d’algorithmes modernes (LZ77, Huffman, context modeling) qui lui permettent de mieux compresser les fichiers texte que Gzip, à taille égale ou moindre.

Chronologie clé :

• 2015 : Google publie Brotli en open source.
• Début 2016 : Chrome et Firefox ajoutent le support de Content-Encoding: br en HTTPS.
• 2017-2018 : CDN comme Cloudflare et Akamai adoptent Brotli à grande échelle.
• 2019+ : Brotli devient la compression par défaut sur de nombreux sites via des CDN ou Nginx compilé avec ngx_brotli.

Les niveaux de compression Brotli

Brotli offre 11 niveaux de compression, du plus rapide (niveau 0) au plus efficace (niveau 11). Voici quelques points de repère :

Niveau	Vitesse	Ratio de compression
1 à 4	Rapide	Meilleur que Gzip niveau 6
5 à 7	Moyen	Idéal pour les fichiers statiques
8 à 11	Lent	Compression maximale, mais coûteuse en CPU

Cloudflare, par exemple, utilise Brotli niveau 4, un compromis équilibré entre vitesse et efficacité.

Sous-section : Avantages de Brotli

• Ratio de compression supérieur à Gzip, en particulier sur les fichiers HTML, CSS, JS et JSON.
• Décompression rapide (parfois plus rapide que Gzip).
• Supporté par tous les navigateurs modernes (Chrome, Firefox, Safari, Edge…).
• Permet une meilleure optimisation des performances web pour le référencement.

Sous-section : Limites de Brotli

• Non activé par défaut sur Nginx ou Apache : nécessite parfois une compilation manuelle ou un module spécifique (ngx_brotli).
• Compression lente aux niveaux élevés : à éviter pour la compression à la volée sur des contenus dynamiques lourds.
• Support limité sur certains proxies anciens ou outils legacy.

---

Gzip vs Brotli – Le comparatif complet

Comparaison des performances

Critère	Gzip	Brotli (niveau 4)
Ratio de compression	Moyen (~30-70 %)	Meilleur (~40-85 %)
Vitesse de compression	Rapide	Rapide (niveaux bas)
Vitesse de décompression	Bonne	Très bonne
Support navigateur	Universel	Très bon (sauf très vieux navigateurs)
Configuration serveur	Simple	Complexe si hors CDN

Pour quels fichiers Brotli est-il préférable ?

Brotli est particulièrement efficace sur les fichiers texte compressibles :

• .html, .css, .js, .json, .svg, .xml, .csv, .txt

Sur ces types de fichiers, Brotli peut surpasser Gzip avec un gain de 15 à 25 % en taille.

Quand Gzip reste-t-il utile ?

• Sur des serveurs ne prenant pas en charge Brotli nativement.
• En complément de Brotli pour garantir la compatibilité descendante (avec Accept-Encoding géré proprement).
• Pour les contenus dynamiques compressés à la volée sur des serveurs sous-dimensionnés (où Brotli pourrait être trop lent aux niveaux élevés).

---

Cloudflare et la compression Brotli – Une solution optimale ?

De nombreux sites utilisent aujourd’hui Cloudflare comme CDN et reverse proxy. Cloudflare applique automatiquement la compression Brotli à la volée, en niveau 4, pour les navigateurs compatibles.

Faut-il compresser aussi côté Nginx ou Apache ?

Non, dans la majorité des cas. Si Cloudflare est activé avec compression Brotli :

• il intercepte les requêtes,
• compresse ou sert les fichiers compressés,
• et ignore la compression Nginx si elle est redondante.

Cela signifie que garder gzip on dans Nginx ajoute une surcharge inutile, surtout pour les réponses dynamiques générées par PHP/FPM.

➡️ Recommandation : désactiver gzip on sur Nginx lorsque Cloudflare est actif.

Exceptions à connaître

• Si certaines routes ne passent pas par Cloudflare (mode DNS only, ou sous-domaines spécifiques), il peut être pertinent d’activer une compression locale.
• En environnement local, il faut gérer la compression côté serveur.

🔍 Point à vérifier : ton site ou certaines parties contournent-elles Cloudflare ? Si oui, une compression Nginx ciblée (Brotli ou Gzip) pourrait rester utile.

---

Faut-il compresser les fichiers déjà optimisés ? (.webp, .woff2, .avif…)

Il est tentant d’appliquer la compression HTTP à tous les fichiers statiques, mais ce n’est pas toujours pertinent. Certains formats modernes sont déjà compressés de manière optimale. Les recomprimer via Gzip ou Brotli peut :

• ne pas réduire leur taille (voire l’augmenter légèrement),
• ajouter de la latence,
• consommer inutilement les ressources CPU du serveur.

Extensions déjà compressées (pas besoin de Brotli ou Gzip)

Extension	Compression utile ?	Remarques
.webp	❌ Inutile	Déjà optimisé
.avif	❌ Inutile	Compression supérieure à JPEG/PNG
.woff2	❌ Inutile	Déjà compressé avec Brotli
.jpg/.jpeg	❌ Inutile	Compression native, peu de gain
.png	❌ Inutile	Déjà compressé (lossless)
.ttf, .otf	🔸 Faible gain possible	Mais généralement remplacés par .woff2

Fichiers à compresser impérativement

Extension	Compression recommandée	Pourquoi ?
.html, .htm	✅ Oui	Fort ratio de compression
.css	✅ Oui	Réduction importante du poids
.js, .mjs	✅ Oui	Scripts souvent lourds
.json, .xml	✅ Oui	Format texte compressible
.svg	✅ Oui	Vectoriel mais très compressible
.txt, .csv	✅ Oui	Fichiers texte compressibles

👉 Conclusion : concentrez la compression Brotli ou Gzip sur les fichiers texte compressibles. Pour les formats déjà optimisés (WebP, AVIF, WOFF2…), désactivez la compression dans Nginx pour éviter un traitement inutile.

---

Configurer la compression sur son serveur web (Nginx ou Apache)

Activer Brotli sur Nginx (si compilé avec ngx_brotli)

Voici une configuration type pour Brotli :

brotli on;
brotli_comp_level 4;
brotli_static on;  # Sert les fichiers .br précompressés si disponibles
brotli_types text/plain text/css application/javascript application/json application/xml+rss image/svg+xml;

À noter : Brotli n’est pas activé par défaut sur Nginx. Il faut généralement compiler le serveur avec le module ngx_brotli ou utiliser un package précompilé (dispo sous Alpine, Arch, certains PPA Ubuntu).

Activer Gzip sur Nginx (en cas d’absence de Brotli)

gzip on;
gzip_comp_level 6;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml+rss image/svg+xml;

Recommandation : si tu actives Gzip, n’applique la compression qu’aux fichiers compressibles pour éviter une surcharge CPU inutile.

Apache – Brotli ou Gzip ?

Apache propose les deux modules :

• mod_deflate pour Gzip
• mod_brotli pour Brotli (Apache ≥ 2.4.26)

Exemple pour activer Brotli :

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/javascript application/json image/svg+xml
</IfModule>

Et pour fallback en Gzip :

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json image/svg+xml
</IfModule>

---

Compression et SEO – quel impact réel sur le référencement ?

Google ne pénalise pas directement l’absence de compression, mais des fichiers trop lourds ralentissent le temps de chargement et dégradent les Core Web Vitals, notamment :

• LCP (Largest Contentful Paint) : ralenti si les CSS ou JS ne sont pas compressés.
• FID (First Input Delay) : impacté si trop de scripts lourds sont exécutés tardivement.
• TTFB (Time to First Byte) : indirectement influencé par la compression dynamique mal optimisée.

Compression et score Lighthouse

L’outil Google PageSpeed Insights recommande systématiquement d’activer la compression de texte. Une absence de Brotli ou Gzip sur les ressources statiques affichera :

“Activer la compression du texte pour réduire la taille de transfert des ressources”

Activer la compression est donc un critère mesurable de performance web, avec un impact SEO indirect mais réel.

---

Quelle stratégie adopter ? Résumé des recommandations

Voici une synthèse pour t’aider à choisir entre Brotli et Gzip selon ton contexte technique :

Contexte	Recommandation principale
Site derrière Cloudflare	Laisser Brotli géré par Cloudflare. Désactiver Gzip côté Nginx.
Site sans CDN ou en local	Activer Brotli si disponible. Sinon, fallback en Gzip niveau 6.
Site avec fichiers dynamiques lourds	Limiter la compression à certains types MIME pour éviter surcharge CPU
Serveur mutualisé ou sans accès root	Gzip reste plus facile à mettre en œuvre
Pour fichiers HTML lourds et statiques	Une stratégie mise en cache sur le serveur d’origine avec un niveau de compression max

---

Conclusion

Le choix entre Gzip ou Brotli dépend surtout de ton environnement d’hébergement et de ton objectif en matière de performance Web. Si tu utilises un CDN comme Cloudflare, inutile de dupliquer les efforts côté serveur : Brotli est déjà appliqué efficacement en bordure du réseau.

Pour les autres cas, Brotli offre de bien meilleurs résultats que Gzip en termes de ratio de compression, surtout sur les fichiers texte (HTML, CSS, JavaScript, JSON…). Toutefois, il demande une configuration plus poussée et n’est pas toujours supporté nativement sur tous les serveurs.

En résumé :

• Active Brotli quand tu peux, pour les fichiers compressibles.
• Désactive Gzip si Cloudflare le remplace déjà.
• Cible uniquement les fichiers utiles, pour éviter une surcharge et des effets contre-productifs.

La compression est un levier simple mais puissant pour améliorer la vitesse de chargement de ton site et répondre aux exigences modernes du référencement SEO.

A lire également : Qu’est-ce que le Hotlinking ? Définition, risques et protections

---