Gzip vs Brotli décide en Hébergement sur le temps de chargement, la taille des fichiers et le budget CPU. Dans cette comparaison, je montre de manière pratique quand activer quelle méthode de compression HTTP, quels niveaux utiliser et comment cela se répercute directement sur les Core Web Vitals et les coûts.
Points centraux
- taux de compression: Brotli permet d'économiser 15-25 % octets de plus que Gzip, surtout pour les assets statiques.
- VitesseGzip compresse plus rapidement à la volée, Brotli décompresse souvent plus rapidement dans le navigateur.
- Statique/Dynamique: Brotli pour les fichiers pré-compressés, Gzip pour les réponses dynamiques.
- Fallback: donner la priorité à Brotli, utiliser Gzip comme couche de repli compatible.
- SEO/UXDes fichiers plus petits réduisent la latence, renforcent les vitaux du cœur du Web et les classements.
Pourquoi la compression HTTP favorise le succès de l'hébergement
Je mise sur Compression HTTP, Le transfert est plus rapide, car il rend chaque réponse plus facile et prend donc moins de temps sur le réseau. Des transferts plus courts améliorent Interactivité, Les compressions de données réduisent l'impression de TTFB et stabilisent la séquence de chargement. Sur les connexions mobiles, chaque kilooctet compte et la compression réduit sensiblement cette empreinte. De plus, j'économise de la bande passante sur le serveur, ce qui, en cas de trafic important, constitue une véritable économie. Coûts est réduite. Celui qui donne la priorité à la performance active donc systématiquement la bonne méthode de compression sur tous les bords : serveur, CDN et Edge.
Gzip : points forts, niveaux et champs d'application
Gzip est basé sur DEFLATE et fournit en pratique des fichiers 50-70 % plus petits avec un temps de compression très court. Pour les réponses HTML dynamiques, je choisis souvent Level 6, car il offre un bon rapport vitesse/économie. En cas de débit élevé, cela ménage le CPU et maintient la latence à un niveau bas. Pour les contenus très dynamiques, j'utilise également le niveau 4-5 en fonction de la charge, afin de réduire encore le temps à la volée. Gzip reste indispensable en tant que solution de repli, car il peut être utilisé pratiquement partout. fonctionne.
Brotli : avantages, niveaux et limites
Brotli utilise LZ77, le codage Huffman et un dictionnaire d'environ 120 Ko contenant des modèles web fréquents. De ce fait, HTML, CSS et JavaScript rétrécissent en moyenne beaucoup plus qu'avec Gzip, surtout à des niveaux élevés. Je vois typiquement 15-25 % d'octets en moins par rapport à Gzip, ce qui réduit clairement le temps de transmission. La décompression dans le navigateur est très rapide, ce qui allège le pipeline de rendu. J'utilise des niveaux modérés (par ex. 4-6) pour la compression à la volée, mais je préfère les niveaux 8-11 pour les assets pré-compressés dans les processus de construction.
Gzip vs Brotli dans le quotidien de l'hébergement
Je décide en fonction Contenu et profil de charge : dynamiquement plutôt Gzip, statiquement plutôt Brotli. Pour les CSS/JS, les polices et les grands modèles HTML, la pré-compression avec Brotli est nettement plus avantageuse. Pour le contenu qui varie à chaque requête, le temps de compression compte, c'est pourquoi Brotli marque des points. Gzip. Les piles modernes gèrent les deux en parallèle : Brotli en priorité, Gzip comme repli. Si vous souhaitez aller plus loin, vous trouverez dans ce comparaison détaillée d'autres chiffres clés et des cas d'application concrets.
Tableau comparatif : chiffres clés et support
Le tableau suivant classe les principaux Critères pour les configurations d'hébergement et montre quand chaque méthode marque des points. Elle m'aide à prendre des décisions en fonction du type de fichier, de la charge et de la compatibilité. J'évalue le taux de compression, la charge du serveur, le support du navigateur et l'impact sur la vitesse perçue. Je détermine ainsi si je dois utiliser la compression à la volée ou en tant qu'étape de construction. comprime. Pour les grands bundles statiques, la pré-compression avec Brotli est particulièrement bien adaptée.
| Critère | Gzip | Brotli | Effets dans la pratique |
|---|---|---|---|
| taux de compression | env. 50-70 % plus petit | typiquement 15-25 % plus petit que Gzip | Moins d'octets, une transmission plus rapide |
| Vitesse de compression | Rapide, surtout aux niveaux 1 à 6 | Plus lent aux niveaux élevés (8-11) | Gzip avantageux pour les réponses dynamiques |
| Décompression | Rapide | Souvent encore plus rapide | Le démarrage du rendu semble plus fluide |
| Prise en charge des navigateurs | Presque complet | Très large avec les navigateurs modernes | Gzip comme solution de repli compatible |
| Consommation du processeur | Faible à bas niveau | Plus élevé pour les niveaux élevés | Évaluer proprement le temps de construction par rapport au temps d'exécution |
J'ajoute à ces chiffres clés TTFB et la bande passante comme facteurs de décision. Lorsque les réserves de l'unité centrale sont limitées, je choisis des niveaux plus bas pour la compression en direct. Dans les pipelines CI/CD, je préemballe les fichiers statiques avec des niveaux Brotli élevés. Je combine ainsi des temps de réponse courts avec des temps de réponse très faibles. Actifs. Le mélange fournit de manière cohérente de meilleures expériences de chargement.
Pratique de configuration avec Nginx et Apache
J'active Brotli et Gzip via des modules, en définissant des MIME raisonnables et en réglant les niveaux en fonction de la charge du serveur. Pour Nginx, j'utilise des paramètres distincts pour les fichiers compressés à la volée et pour les fichiers pré-compressés avec des extensions .br/.gz. Dans Apache, je configure des modules tels que mod_brotli et mod_deflate, ainsi que des modules tels que .htaccess Règles pour la mise en cache et les en-têtes Vary. L'important reste la pré-compression dans le build, afin que le serveur ne fasse que délivrer et ne doive pas constamment compresser. Ceux qui cherchent un guide pas à pas peuvent commencer par cette page Configuration de la compression HTTP.
les stratégies : Dynamique vs. Statique
À l'adresse suivante : dynamique Les pages comptent le temps jusqu'à la première réponse, c'est pourquoi je compresse rapidement avec Gzip au niveau 4-6. Pour les ressources statiques, j'utilise Brotli à des niveaux élevés et je stocke déjà les artefacts dans le système de fichiers ou le CDN. Cette stratégie allège la charge de travail des CPU au moment de l'exécution et réduit les octets au maximum. Je m'assure que le serveur choisit la variante appropriée à l'aide d'Accept-Encoding. Ainsi, je sers les navigateurs modernes avec Brotli et les clients plus anciens de manière fiable avec Gzip.
Effets SEO et Core Web Vitals
Les petits fichiers réduisent la Latence et apportent plus rapidement du contenu à la surface. J'enregistre souvent une meilleure First Contentful Paint et une Largest Contentful Paint plus stable. Sur les appareils mobiles avec une connexion faible, cela se remarque nettement. En outre, j'économise le transfert de données, ce qui, en cas de trafic important, se traduit par des économies mesurables. Coûts de la qualité. L'ensemble de ces avantages se répercute sur la visibilité, la conversion et la satisfaction des utilisateurs.
Monitoring et tuning : une rapidité mesurable
Je vérifie l'effet de Compression avec des mesures en laboratoire et sur le terrain. Des outils comme PageSpeed ou les données RUM m'indiquent les FCP, LCP, TTFB et les tailles de transfert avant et après les ajustements. Si la charge CPU est élevée, je diminue les niveaux, si les fichiers sont trop volumineux, je les augmente par étapes de construction. Les en-têtes de cache tels que Cache-Control et ETag empêchent les reconditionnements inutiles et renforcent les Efficacité. Il reste important de tester régulièrement, car les modèles de trafic et la taille des actifs évoluent.
Configuration de la pratique : Approche hybride pour WordPress & Co.
Pour WordPress je choisis souvent Brotli pour les CSS/JS/polices et Gzip pour les pages HTML générées par PHP. Les CDN livrent les fichiers pré-compressés, tandis que l'Origin compresse rapidement les réponses dynamiques. Je fais attention aux en-têtes Vary pour séparer proprement les caches et aux ETags identiques pour les variantes .br/.gz. Pour ceux qui souhaitent un réglage plus fin, voici des détails sur Niveau de compression et charge CPU. Ainsi, la chaîne de rendu reste légère, les Charge du serveur calculable et la compatibilité élevée.
Les fichiers que je ne compresse pas
Tout ne profite pas de la compression HTTP. Certains formats sont déjà compressés de manière optimale en interne ou nécessitent des requêtes de plage d'octets, pour lesquelles une compression supplémentaire est plutôt gênante. C'est pourquoi je laisse généralement les fichiers non compressés :
- Images : JPEG/JPG, PNG, GIF, WebP, AVIF (déjà fortement compressé)
- Vidéo/audio : MP4, WebM, MOV, MP3, OGG, AAC
- Archives/conteneurs : ZIP, 7z, RAR, ISO, PDF (souvent compressé), DMG
- Formats de police : WOFF2 (utilise Brotli en interne), WOFF partiellement compressible, TTF/OTF pré-compressé selon le setup
- Téléchargements binaires qui sont souvent chargés par range
Il convient avant tout de comprimer Formats de texte: HTML, CSS, JavaScript, JSON, XML, SVG, manifestes web et sitemaps. SVG en tant que XML en profite fortement ; WOFF2 en revanche n'en profite pas - ici, je m'épargne l'encodage de contenu.
HTTP/2/HTTP/3 et TLS : interaction avec la compression
HTTP/2 et HTTP/3 accélèrent le transport et le multiplexage, mais remplacent pas la compression de la charge utile. La compression de l'en-tête (HPACK/QPACK) ne s'occupe que de l'en-tête, pas du corps. Moins d'octets dans le corps restent donc un net avantage. Important : Brotli n'est, dans la pratique, principalement utilisé par les navigateurs que par le biais de HTTPS sont proposés. Ceux qui utilisent encore le HTTP pur ne voient en général que Gzip comme option. Dans les chaînes de terminaison TLS, je veille à ce que la compression à la périphérie se fasse près du client afin de minimiser la latence et l'érosion.
Gestion des variantes : Accept-Encoding, caches et ETags
Propre Négociation de contenu décide du taux de réussite de la mise en cache. Je mets systématiquement l'en-tête Vary sur Accept-Encoding, pour que les proxies et les CDN séparent correctement les variantes. Pour les assets pré-packagés, je considère que Dernière modification et attribuer des ETags séparés par représentation (.br/.gz/identique). Les CDN devraient ajouter l'encodage Accept à la clé de cache. Il est important d'exclure la double compression : Si un fichier existe déjà en .br, le serveur ne doit pas le zipper à nouveau. Pour les rangs d'octets (par ex. vidéo), je fournis la variante non comprimée, car les rangs se réfèrent à la représentation codée et les caches peuvent sinon devenir incohérents.
Ajustement fin : seuils, niveaux et budget CPU
Je travaille avec Tailles minimales, Les fichiers de petite taille ne sont pas inutilement compressés (seuil typique de 1-2 Ko). Pour les réponses dynamiques, je choisis Gzip niveau 4-6 ou Brotli 4-6. Pour les artefacts de construction, je préfère Brotli 9-11, pour autant que le temps de construction reste raisonnable. Règles empiriques qui ont fait leurs preuves :
- Petits snippets HTML et réponses API : Gzip 4-5 ou Brotli 4-5
- Grands bundles (JS/CSS > 50 KB) : Brotli 8-11 en avant-première
- Volume de trafic en direct très élevé : abaisser le niveau pour éviter les files d'attente et les pics de TTFB
Il est important de garder un œil sur les pics de CPU. Si le pipeline de compression se bloque, le TTFB perçu se détériore. J'abaisse alors les niveaux en direct et transfère les économies dans le build.
Sécurité : compression sans risque
La compression de transport via TLS est sûre, mais il existe depuis des années des attaques connues par canal latéral sur la compression de contenu (mot-clé BREACH). En pratique, cela signifie : les pages contenant des jetons secrets et reflètent simultanément les entrées de l'utilisateur, je les compresse avec précaution ou pas du tout. Par exemple, je sépare les pages de formulaire avec des jetons CSRF des paramètres réfléchissants, je minimise le contenu de l'écho ou je désactive la compression sur ces points finaux. Les ressources statiques ne sont pas concernées par cette mesure - je continue à les compresser de manière agressive.
CDN, Serverless et stockage objet : clarifier les responsabilités
À l'adresse suivante : Configurations CDN je laisse la compression Edge active et je télécharge en plus des artefacts pré-compressés. Il est important que les métadonnées soient correctes : Type de contenu et Encodage du contenu doivent être correctes, sinon les CDN servent de mauvaises variantes ou compriment deux fois. Dans Sans serveur-Pour les fonctions d'enregistrement, je garde les niveaux live conservateurs (Gzip 4-5 ou Brotli 4) afin d'éviter les démarrages à froid et les pics de CPU. Pour le stockage d'objets (par ex. en tant qu'origin), j'enregistre .br/.gz à côté du fichier brut ; le CDN choisit en fonction de l'encodage Accept. Le pipeline de construction génère toutes les variantes de manière déterministe afin que les ETags restent stables.
Contrôle et débogage : comment vérifier l'effet ?
Je valide régulièrement la livraison à l'aide de Browser-DevTools : Dans la vue réseau, je contrôle Encodage du contenu, les octets envoyés et si le serveur répond à partir du cache. En outre, je vérifie si les Vary-et si Brotli est vraiment livré aux clients HTTPS. Pour les réponses API, je compare les tailles compressées et non compressées et j'observe TTFB sous charge. Si je trouve erreurs types il s'agit généralement d'un en-tête Vary manquant (empoisonnement du cache), d'une double compression (br+gz), de paires type de contenu/encodage mal définies ou d'une compression inutile de fichiers minuscules. Je corrige d'abord ces cas avant d'augmenter les niveaux.
Effet sur les coûts calculé brièvement
La compression fait gagner du temps, mais aussi Volume de l'égression. Celui qui livre par exemple 1 TB de trafic texte par mois et qui économise en moyenne 20 % supplémentaires par rapport à Gzip grâce à Brotli, réduit son trafic de sortie d'environ 200 Go. Selon le tarif, de telles économies s'additionnent sensiblement. Du côté du calcul, la règle est la suivante : des niveaux de live plus élevés coûtent du temps de CPU. J'équilibre donc les coûts d'égression avec le budget CPU et je déplace les niveaux coûteux dans le build, où ils ne sont générés qu'une seule fois.
Edge cases : streaming, proxies et petits fichiers
À l'adresse suivante : Événements envoyés par le serveur ou des réponses en streaming, je préfère utiliser Gzip à bas niveau ou désactiver la compression pour que les chunks s'écoulent sans délai. Derrière les anciens proxies, les Accept-Encoding je garde Gzip actif en tant que solution de repli robuste. Et pour les fichiers de moins de ~1 Ko, j'évite complètement la compression, car les surcharges d'en-tête et la latence neutralisent souvent le gain.
Résumé : Un mélange judicieux est payant
Je mets Brotli pour les fichiers statiques et je garde Gzip à disposition comme solution de repli fiable. Pour les réponses dynamiques, je vise des niveaux rapides, pour les builds, une économie maximale. Je combine ainsi des TTFB courts avec de très petits transferts et je renforce durablement les Core Web Vitals. Avec une configuration propre, une pré-compression et un monitoring, la pile reste rapide et stable. Celui qui utilise ce mélange de manière conséquente ressent immédiatement les avantages en termes de temps de chargement.
