Comment vérifier la compression Brotli ou gzip des ressources texte ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre compression Brotli et gzip

Brotli et gzip réduisent le volume transféré de nombreuses ressources textuelles comme HTML, CSS, JavaScript, JSON ou SVG. La compression de transfert n’enlève pas le travail de parsing ni l’exécution du code, mais elle peut réduire les octets envoyés sur le réseau lorsque le serveur et le client négocient un encodage adapté.

Inspecter le comportement réellement servi

Relevez Content-Encoding et la taille transférée pour des ressources représentatives. Comparez les réponses HTML, feuilles de style et scripts, y compris les assets servis par un CDN. Une ressource minifiée n’est pas forcément compressée pendant le transport, et inversement.

Distinguer les notions qui se ressemblent

Distinguez compression, minification et cache. La minification retire des caractères inutiles du fichier, la compression encode le flux transmis, et le cache évite certains nouveaux transferts. Ces mécanismes peuvent se cumuler et ne résolvent pas le même problème.

Identifier les causes les plus probables

Une compression absente peut venir d’un serveur non configuré, d’un type MIME exclu, d’un proxy qui modifie les en-têtes, d’une origine qui sert déjà une ressource compressée de façon inadéquate ou d’un CDN dont la règle ne couvre qu’une partie des fichiers.

Décider ce qui mérite d’être corrigé en premier

Priorisez les gros fichiers textuels téléchargés fréquemment et les réponses critiques de navigation. Une petite ressource déjà négligeable mérite moins d’attention qu’un bundle JavaScript ou une réponse HTML importante. Mesurez les octets économisables avant de modifier toute la chaîne serveur.

Corriger à la bonne couche

Activez une compression adaptée aux contenus textuels sur la couche qui sert réellement la réponse et laissez la négociation HTTP choisir un encodage pris en charge. Évitez de recomprimer des formats déjà fortement compressés comme certaines images ou archives sans bénéfice mesuré.

Traiter les cas limites sans automatisme

Brotli peut produire de très bons ratios, mais le niveau de compression et l’endroit où il est calculé influencent le coût serveur. Pour des fichiers statiques, la précompression peut être différente d’une compression dynamique. Gzip reste utile comme solution largement compatible selon l’infrastructure.

Valider la correction sur des cas réels

Après changement, comparez en-têtes, taille transférée et contenu décompressé sur plusieurs navigateurs et routes. Vérifiez les réponses 200 comme les variantes mises en cache. Un gain de taille ne doit pas s’accompagner d’erreurs d’encodage ou d’une charge serveur disproportionnée.

Prévenir la régression dans le temps

Incluez la présence d’un encodage pertinent dans les contrôles d’infrastructure et surveillez les régressions après changement de CDN, serveur ou pipeline d’assets. Gardez séparées les métriques de transfert et les Core Web Vitals pour ne pas attribuer automatiquement un gain utilisateur précis.

Clôturer le contrôle sur compression Brotli et gzip

Pour clôturer le contrôle « Comment vérifier la compression Brotli ou gzip des ressources texte ? », conservez une preuve avant/après : URL ou composant testé, constat initial, origine technique, correction appliquée et résultat de la vérification. Contrôlez aussi les pages liées /seo/performance-technique, /seo/cache-navigateur-performance, /seo/javascript-inutilise-performance afin de vérifier que la correction reste cohérente avec le reste du corpus. Le périmètre documentaire reste volontairement borné : Relier la compression des ressources textuelles à la réduction des octets transférés. Distinguer compression de transfert, minification et cache, sans promettre un gain Core Web Vitals identique sur tous les sites. Si le comportement dépend d’un gabarit, d’un CDN, d’un navigateur ou d’un outil tiers, testez au moins un second cas représentatif. Une anomalie ambiguë doit rester en revue plutôt que d’être fermée sur une hypothèse. Attribuez enfin la règle à une source précise — composant, template, serveur, CMS ou configuration — pour pouvoir la retester après une refonte.

Conserver une preuve exploitable dans l’audit

Un contrôle sur compression Brotli et gzip est utile seulement si une autre personne peut reproduire le constat. Enregistrez la réponse ou l’état observé, l’outil utilisé, le contexte de test et l’élément exact qui justifie la conclusion. Évitez les captures isolées sans URL, statut ou propriété mesurée. Pour les anomalies répétées, comptez les occurrences par gabarit avant et après correction. Cette trace permet de distinguer une résolution globale d’un exemple corrigé manuellement et évite de rouvrir le même diagnostic sans information nouvelle. Lorsque la documentation officielle est la borne du contrôle, notez également la source utilisée afin de pouvoir réévaluer la règle si elle évolue.

Tester un scénario représentatif

Choisissez une réponse HTML, un bundle JavaScript, une feuille CSS et un fichier JSON. Pour chacun, relevez Content-Type, Content-Encoding, taille de ressource et taille transférée depuis un navigateur puis avec curl en annonçant différents Accept-Encoding. Comparez la réponse directe de l’origine à celle du CDN si les deux couches sont accessibles. Un script minifié de 300 Ko peut encore bénéficier d’une compression de transfert, tandis qu’une image JPEG ne doit pas être utilisée pour conclure que gzip est désactivé. Testez Brotli sur HTTPS et vérifiez le fallback gzip lorsque le client ne propose pas br. Mesurez aussi le coût d’une compression dynamique agressive sur une réponse générée fréquemment. Ce scénario sépare clairement ratio réseau, minification du fichier, cache et charge CPU du serveur. Conservez pour chaque ressource URL, Content-Type, Content-Encoding, Content-Length éventuel, transferSize, encodedBodySize et protocole négocié. Comparez br, gzip et identity sur HTML, CSS, JS, JSON et SVG. Pour la compression dynamique, ajoutez temps CPU ou TTFB si disponible afin de ne pas optimiser le ratio au prix d’un coût serveur excessif. Les fichiers JPEG, PNG, WebP, AVIF ou ZIP servent de contre-exemples déjà compressés. Pour un bundle versionné, comparez le fichier original, le fichier minifié, la variante .gz ou .br précompressée et la taille effectivement transférée après cache froid. Cette chaîne évite de conclure à partir du poids sur disque ou d’une extension de fichier qui ne correspond pas à la réponse négociée. Ajoutez Vary: Accept-Encoding, ETag, Cache-Control, âge du cache et status 304 au diagnostic lorsque l’infrastructure les utilise. Une variante Brotli peut avoir sa propre clé de cache ; une mauvaise configuration peut servir un corps compressé avec un en-tête incohérent. Vérifiez l’intégrité du contenu décompressé et les réponses partielles si Range est employé sur certaines ressources.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• webdev text compression