Post-compression : Brotli vs Gzip – quel format accélère réellement les sites web ?

À l'adresse suivante : brotli vs gzip Je décide du format à utiliser en fonction des effets mesurables sur le TTFB, le volume de données et les Core Web Vitals. D'après des benchmarks fiables, je sais que : Brotli Compresse HTML, CSS et JS en moyenne 15 à 21 % plus fortement et décompresse dans le navigateur dans de nombreux cas plus rapidement, parfois jusqu'à 64 % [1][4][5].

Points centraux

• taux de compression: Brotli réduit les ressources textuelles en moyenne de 15 à 21 % de plus que Gzip, ce qui est perceptible pour FCP/LCP [1][4][5].
• Scénarios: Ressources statiques à la périphérie avec Brotli, réponses dynamiques souvent avec Gzip ou un niveau Brotli modéré.
• niveaux de performance: Brotli niveau 4 est souvent plus rapide et plus efficace que Gzip niveau 6 ; niveaux élevés uniquement en cas de précompression [4][5].
• Hébergement: L'hébergement compressif efficace avec HTTP/2/3, la mise en cache et le CDN réduisent considérablement les allers-retours [3][5][8].
• Suivi: toujours vérifier les modifications à l'aide de RUM et de tests synthétiques via FCP, LCP et TTFB.

Compatibilité, en-têtes et clés de mise en cache

Pour que Brotli ou Gzip fonctionnent correctement, je veille à ce que Négociation de contenu. Le navigateur envoie Accept-Encoding, le serveur répond par Encodage du contenu (br, gzip ou identity). Important : Vary : Accept-Encoding doit être ajouté à chaque réponse compressée afin que les caches et les CDN séparent correctement les différentes variantes. Sinon, le cache fournit un fichier Brotli à un client qui ne comprend que Gzip. Au niveau du CDN, je vérifie que Accept-Encoding Partie du Clés de cache et que les nœuds périphériques peuvent stocker à la fois les variantes .br et .gz.

Je tiens également un solide Fallback Prêt : si un client ne peut pas utiliser Brotli, il reçoit Gzip ; s'il ne peut rien utiliser, il reçoit le fichier non compressé. Pour les proxys locaux ou les appareils plus anciens, cette méthode vaut de l'or, et elle ne me prend pas de temps au quotidien si la chaîne Vary est correcte. J'utilise les ETags de manière réfléchie : des ETags forts par variante ou un hachage qui inclut la forme de compression empêchent les erreurs. 304 Non modifié Résultats entre br/gz.

Les avantages concrets de la post-compression au quotidien

Efficace Compression Cela réduit non seulement la durée de transfert, mais stabilise également les temps de chargement lorsque la qualité du réseau mobile est variable. Plus les fichiers HTML, CSS, JavaScript et JSON sont petits, plus les premiers contenus s'affichent rapidement, car le navigateur a moins d'octets à récupérer et à décompresser. Je donne donc la priorité aux ressources textuelles, car les images et les vidéos bénéficient davantage de leurs propres codecs que de la compression HTTP. Sur des hôtes bien configurés, le temps de réponse (Time to First Byte) peut être réduit de manière visible, car le temps CPU et le temps d'attente du réseau sont mieux équilibrés. En nettoyant son pipeline, on gagne doublement : moins de bande passante pour le Données et moins de reflows grâce à des styles et des scripts disponibles plus tôt.

Quels contenus compresser – et lesquels ne pas compresser

Je compresse de manière ciblée basé sur le texte Types : text/html, text/css, application/javascript, application/json, application/xml, image/svg+xml, application/manifest+json et similaires. Pour les formats binaires déjà compressés (images, vidéos, PDF dans de nombreux cas, WOFF2), j'économise le CPU : l'effet est minime, la latence peut augmenter. Autre point important : une valeur seuil(par exemple, entre 1024 et 2048 octets) afin que les réponses minimes ne soient pas inutilement retardées sans gain notable. Dans CI, je vérifie régulièrement le type et la taille du contenu afin de détecter rapidement les erreurs de configuration.

Brotli vs Gzip : des chiffres qui changent les temps de chargement

Compressé lors des tests Brotli HTML environ 21 %, JavaScript environ 14 % et CSS environ 17 % plus puissant que Gzip [1][4]. D'autres mesures confirment une avance d'environ 20 % par rapport à Deflate, le procédé derrière Gzip [5][6]. Cette différence rend les pages nettement plus rapides, en particulier lorsqu'elles contiennent beaucoup d'éléments textuels et sur les appareils mobiles à bande passante variable. De plus, la décompression dans le navigateur est souvent plus rapide avec Brotli ; des temps de décompression jusqu'à 64 % plus rapides ont été mesurés dans le frontend [1]. Au total, de meilleures performances réduisent taux de compression et un déballage rapide clarifient le chemin critique jusqu'au contenu visible.

Conçu à partir du réseau : premiers RTT et CWV

De nombreux gains tangibles sont générés parce que les réponses plus modestes s'intègrent mieux dans les premières Vols TCP/QUIC Si, grâce à Brotli, le HTML initial tient dans un ou deux paquets de moins, le temps jusqu'au FCP/LCP et le blocage des ressources critiques pour le rendu sont réduits. Avec HTTP/3, les connexions bénéficient en outre d'une réduction Tête de ligneBlocage. Dans les réseaux mobiles présentant un taux de perte de paquets plus élevé, les transferts plus petits lissent les JitterCourbe – Les données RUM montrent alors moins de valeurs aberrantes vers le haut. Pour moi, c'est une raison suffisante pour réduire systématiquement le premier HTML et le CSS critique [3][5][8].

Quand utiliser Brotli – et quand utiliser Gzip

Pour statique Pour les ressources telles que HTML, CSS, JS, SVG et WOFF2, j'utilise Brotli avec un niveau élevé, précompressé lors de la compilation ou directement sur le CDN Edge. Les fichiers sont stockés dans le cache et sont livrés des milliers de fois sans coût CPU. Pour les réponses très dynamiques (vues HTML personnalisées, API JSON, recherche), j'utilise généralement Gzip ou Brotli avec un niveau modéré afin que le serveur diffuse rapidement la réponse. La courbe TTFB reste déterminante : si elle monte en flèche, je réduis le niveau ou je fournis plutôt tôt des contenus partiels non bloqués. C'est ainsi que je maintiens Temps de réponse faible, sans perdre les avantages des fichiers compacts.

Choisir correctement les niveaux de qualité (Level)

Je commence de manière pragmatique : niveau Brotli 4 pour on-the-fly, niveaux 9-11 uniquement pour la précompression ; niveau Gzip 6 comme point de départ solide [4][5][6]. Si la charge CPU augmente en période de trafic de pointe, je réduis d'abord le niveau Brotli et vérifie si les en-têtes de mise en cache et le CDN Edge fonctionnent correctement. Souvent, un petit ajustement au niveau du Cache plus qu'un niveau de compression élevé. Dans ses mesures, Brotli a souvent montré au niveau 4 de meilleures tailles de fichiers avec une latence similaire ou inférieure à celle du niveau 6 de Gzip [4]. En mesurant correctement les itérations, on aboutit rapidement à une configuration qui Serveur et économise néanmoins sensiblement les données.

Configuration : Nginx, Apache, Caddy – paramètres par défaut sécurisés

Je mise sur des valeurs par défaut simples et vérifiables. Pour Nginx, cela signifie : utiliser des variantes statiques, modérées à la volée, des types corrects, des tailles minimales raisonnables, définir Vary proprement.

# Nginx (exemple) brotli on; brotli_comp_level 4; brotli_static on; brotli_types text/html text/plain text/css application/javascript application/json application/xml image/svg+xml;

gzip on; gzip_comp_level 6; gzip_min_length 1024; gzip_static on; gzip_vary on; gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml; add_header Vary "Accept-Encoding" always;

Sous Apache, j'active mod_brotli et mod_deflate avec une responsabilité claire : Brotli en premier lieu, Deflate en second lieu. Les tailles minimales et les types restent cohérents.

# Apache (exemple)  AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/javascript application/json application/xml image/svg+xml BrotliCompressionQuality 4 BrotliWindowSize 22
  AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json application/xml image/svg+xml DeflateCompressionLevel 6  Header append Vary " Accept-Encoding "

Les gardes restent importants : pas de compression pour les médias déjà compressés, tests pour la double compression et sur les proxys. no-transform éviter lorsque les caches suppriment les variantes. Je vérifie avec curl : -H „ Accept-Encoding : br,gzip “ et -I, si Encodage du contenu, Vary et les tailles sont plausibles.

Précompresser les ressources statiques : Build, Edge, Cache

Pour les interfaces utilisateur riches en bundles, je précompresse Actifs dans la compilation et placez les variantes .br/.gz à côté des originaux afin que Nginx ou un CDN fournisse directement la version appropriée. Les grandes bibliothèques, les classes CSS répétées et le code de framework en bénéficient particulièrement, car Brotli utilise une fenêtre de recherche plus grande et un dictionnaire intégré [2][9]. Les caches légitimes à long terme (immuables + versionnage) réduisent encore davantage les requêtes et le travail de décompression. Si vous souhaitez fournir un service mondial, combinez cela avec un Optimisation CDN, afin que les nœuds Edge proches de l'utilisateur fournissent les données. Ainsi, la combinaison de fichiers plus petits et de la proximité géographique garantit des coûts de données plus faibles. Latence.

Contrôler les réponses dynamiques et le TTFB

Pour les fichiers générés côté serveur HTML-En termes de vues, le streaming et la faible latence comptent plus que les derniers points de pourcentage de taille de fichier. Je compresse à la volée avec Gzip ou Brotli à un niveau modéré, je vérifie le TTFB et le CPU par travailleur et j'augmente le niveau uniquement si les réserves sont suffisantes. Un ordre de modèles intelligent envoie les premiers octets tôt afin que le navigateur puisse commencer le rendu. De plus, cela stabilise Mise en cache côté serveur le temps de réponse, car les fragments récurrents ne sont pas recalculés à chaque fois. Cette configuration maintient Pointes sans ralentir l'expérience utilisateur.

Diffuser correctement le streaming et les contenus partiels

En particulier pour les vues HTML, je mise sur rivières précoces: CSS inline critique, section Head précoce, puis streaming rapide du corps. La compression ne doit pas ralentir le processus. C'est pourquoi je surveille la taille des tampons et les points de vidage et évite les niveaux Brotli complexes à la volée. Le niveau Gzip 6 ou Brotli 3-4 offre ici un bon équilibre. Il est essentiel que le serveur n'attende pas que „ tout soit prêt “, mais qu'il envoie des blocs significatifs, ce qui améliore le FCP et la réactivité perçue.

HTTP/2 et HTTP/3 : combiner efficacement la compression

Multiplexage sous HTTP/2 et QUIC sous HTTP/3 fonctionnent parfaitement avec les fichiers de petite taille, car davantage d'objets circulent en parallèle et avec moins de blocage en tête de ligne. Sur les réseaux mobiles en particulier, les RTT réduits et la diminution des pertes de paquets dans HTTP/3 apportent une stabilité supplémentaire. Je vérifie donc toujours si l'hôte prend en charge les deux protocoles avec une priorisation correcte et le remplacement du serveur push (Early Hints). Si vous comparez les configurations, vous trouverez des détails utiles dans le compact HTTP/3 contre HTTP/2 Aperçu. En combinaison avec Brotli pour les fichiers statiques et Gzip pour le HTML en direct, les temps d'attente et Jitter perceptible.

Stratégies CDN : clés de cache, stale et précompression en périphérie

Dans le CDN, je veille à ce que .br et .gz Les variantes sont mises en cache séparément et les nœuds périphériques fournissent de préférence les artefacts déjà précompressés. J'active stale-while-revalidate et stale-if-error, afin que les pics ou les interruptions backend ne soient pas visibles. Pour les routes API, je laisse souvent le CDN compresser en direct, mais avec des niveaux conservateurs. Important : les en-têtes tels que Contrôle du cache, ETag, Vary et Encodage du contenu doivent former un ensemble cohérent, sinon des vagues de cache manquées bizarres apparaissent, ce qui détériore le TTFB.

Utilisateurs mobiles : économisez de la bande passante, préservez votre batterie

Sur le smartphone, chaque économie réalisée octet ont un impact direct sur le temps de chargement et la consommation d'énergie. Les fichiers Brotli, plus petits de 15 à 21 %, réduisent la durée de transfert et l'activité radio ; lorsque la bande passante est limitée, le soulagement est particulièrement perceptible [4][5]. Des charges utiles plus faibles stabilisent également les métriques FCP et LCP, car les ressources critiques pour le rendu arrivent plus rapidement. Je veille également à ce que le CSS critique soit propre et je prends une décision claire quant aux scripts qui peuvent réellement bloquer le rendu. Au final, les taux de rebond diminuent et les interactions démarrent plus tôt, car le navigateur est moins Dernier porte.

Flux de travail de l'équipe, CI et budgets

Je fais de la compression un Thème du pipeline: les étapes de compilation génèrent .br/.gz, CI mesure la taille des artefacts et la compare aux budgets. Une pull request qui gonfle les ressources critiques de 30 % est immédiatement détectée. De plus, je stocke des tests de fumée (vérifications curl sur l'encodage du contenu, Vary, comparaison de taille) afin que les erreurs ne soient pas détectées seulement en production. Je lance les déploiements en tant que Canary: Répartir le trafic sur de nouveaux niveaux, observer les métriques RUM et serveur, puis déployer complètement. Des leviers de retour en arrière clairs (indicateurs de fonctionnalités, carte Nginx pour les niveaux de qualité) me rassurent en cas de pic de trafic.

Tableau comparatif : les points forts en un coup d'œil

L'aperçu suivant m'aide dans mes discussions avec Équipes, prendre des décisions rapides. Elle ne remplace pas un test dans votre propre pile, mais elle montre où se trouvent les effets les plus importants. J'évalue toujours la combinaison de la taille du fichier, du profil CPU et de l'impact sur l'utilisateur. Si vous vous concentrez clairement sur les ressources textuelles statiques, vous serez presque toujours satisfait de Brotli. Pour les applications très dynamiques, Gzip reste une solution fiable. Allrounder.

Critère	Brotli	Gzip	Effet pratique
taux de compression	~15–21 % plus petit avec HTML/CSS/JS [1][4][5]	Bon, mais plus grand que Brotli	Moins d'octets, plus rapide Transmission
Décompression dans le navigateur	Souvent plus rapide ; jusqu'à 64 % lors des tests [1]	Vitesse solide	Démarrage plus rapide visible Contenu
Profil CPU à la volée	Niveaux modérés rapides ; niveaux élevés coûteux	Niveaux moyens très rapides	Choisissez un niveau HTML conservateur pour le mode Live
Meilleures utilisations	Ressources statiques, précompression, cache périphérique	Réponses dynamiques, flux, API	Séparer les configurations par type de ressource
Étapes typiques	4 (à la volée), 9-11 (pré) [4][5][6]	6 comme point de départ	Équilibre entre taille et TTFB
Compatibilité	Largement pris en charge, solution de repli possible [3][5][6]	Disponible presque partout	Pas d'obstacles réels dans les piles modernes

Suivi et tests : comment mesurer les progrès

Je commence par installer des Métriques: TTFB, FCP, LCP, octets/requête et CPU par travailleur. Ensuite, je compare les variantes – Gzip vs Brotli, ajustements de niveau, cache périphérique activé/désactivé – dans des fenêtres temporelles identiques. Les tests synthétiques montrent des différences reproductibles, la surveillance des utilisateurs réels confirme l'effet sur les utilisateurs réels. Il est important de pouvoir effectuer une restauration propre en cas de pics de CPU ou de vagues de cache manqué. Ce n'est que lorsque les effets sont stables que je déploie la configuration. Traficdes itinéraires difficiles.

Dépannage : erreurs courantes et vérifications rapides

• Double compression: Le codage du contenu affiche „ br, br “ ou „ gzip, gzip “. Cela est souvent dû à des chaînes de filtrage ou à un proxy + origine. Solution : ne désigner qu'un seul responsable, privilégier les variantes statiques.
• Variante incorrecte provenant du cache: Brotli est bien accueilli par les clients sans prise en charge br‑. La plupart du temps, il manque Vary : Accept-Encoding ou la clé de cache CDN ne contient pas ce champ. Solution : forcer Vary et adapter la clé CDN.
• Explosion du TTFB Après activation : niveau on-the-fly trop élevé, saturation du processeur ou cache Edge manquant. Solution : réduire le niveau, activer la précompression, vérifier l'en-tête du cache.
• Pas de gain de taille: types incorrects (médias déjà compressés), longueur minimale trop faible ou absence de minification agressive. Solution : sélectionner les types, augmenter la longueur minimale, vérifier l'optimisation de la compilation.
• Téléchargements endommagés: La longueur du contenu ne correspond pas à la réponse compressée ou le flux amont supprime l'encodage du contenu. Solution : lors de la compression, utiliser l'encodage de transfert : chunked ou recalculer correctement la longueur.
• Chemins de rendu saccadés: Le HTML est diffusé trop tard, bien qu'il soit compressé. Solution : structurer le modèle, envoyer les premiers octets, utiliser le CSS critique, choisir des niveaux modérés.

En bref : ma stratégie par défaut

Pour toutes les ressources texte pouvant être mises en cache, j'active Brotli et je fournis des contenus précompressés via Build ou CDN Edge. Les contenus très dynamiques sont compressés avec Gzip ou Brotli à un niveau modéré afin que le TTFB et l'interactivité restent stables. HTTP/2 et HTTP/3 fonctionnent avec des en-têtes de cache correctement définis, des Early Hints et un chargement prioritaire des ressources critiques. Je maintiens les paramètres de qualité aussi bas que possible, tant que la taille des fichiers présente un avantage évident. Cette approche combine une faible Volume de données avec une faible charge serveur – et accélère sensiblement les pages.