Vérificateur de compression GZIP/Brotli

Le Vérificateur de Compression GZIP/Brotli est un outil en ligne gratuit dans lequel vous collez les en-têtes de réponse HTTP pour vérifier la compression gzip, Brotli, deflate ou zstd. Il analyse la compressibilité, les économies estimées et fournit des guides de configuration serveur. Il fonctionne entièrement dans votre navigateur, sans installation ni inscription.

Il détecte gzip, Brotli (br), deflate, zstd et identity à partir de Content-Encoding. Il vérifie aussi Transfer-Encoding pour la compression au niveau du transport.

Lorsque Content-Length est présent, il utilise des ratios moyens (gzip ~70 %, Brotli ~78 %, deflate ~65 %, zstd ~75 %) pour estimer la taille originale ou compressée.

Oui. Toute l'analyse s'exécute dans votre navigateur. Aucune donnée n'est envoyée à un serveur.

Oui, le Vérificateur de Compression GZIP/Brotli est 100 % gratuit, sans inscription, sans frais cachés et sans limite d'utilisation. Tout le traitement se fait localement dans votre navigateur, garantissant une confidentialité totale.

Oui, le Vérificateur de Compression GZIP/Brotli est entièrement responsive et fonctionne sur smartphones et tablettes. Vous pouvez l'utiliser sur n'importe quel appareil doté d'un navigateur web moderne, sans aucune application à télécharger.

Aucun compte ni inscription n'est nécessaire. Ouvrez simplement le Vérificateur de Compression GZIP/Brotli dans votre navigateur et utilisez-le immédiatement. Il n'y a ni barrière d'inscription ni restriction d'utilisation.

Saisissez simplement vos données dans le champ prévu, ajustez les paramètres selon vos préférences, et l'outil les traitera instantanément. Vous pouvez ensuite copier le résultat dans le presse-papiers ou le télécharger.

Le Vérificateur de Compression GZIP/Brotli fonctionne dans tous les navigateurs modernes, dont Chrome, Firefox, Safari, Edge et Opera. Pour une expérience optimale, utilisez la dernière version de votre navigateur préféré.

Gzip et Brotli sont tous deux des algorithmes sans perte qui réduisent la taille des réponses textuelles avant qu'elles n'arrivent jusqu'au navigateur, mais Brotli est plus récent et plus efficace. Sur des contenus textuels typiques comme HTML, CSS et JavaScript, Brotli compresse généralement 15 à 20 % de plus que gzip, ce qui se traduit par des transferts plus rapides et un meilleur Largest Contentful Paint, surtout sur les connexions mobiles lentes. Gzip garde l'avantage d'un support quasi universel et d'une compression légèrement plus rapide à des niveaux de réglage bas, donc de nombreux serveurs y reviennent lorsqu'un client n'annonce pas Brotli. Le navigateur indique ce qu'il accepte via l'en-tête de requête Accept-Encoding, et le serveur répond avec Content-Encoding: gzip ou br. Si vous collez vos en-têtes de réponse ici, le vérificateur identifie précisément quel encodage est actif et encourage les sites qui n'utilisent que gzip à ajouter Brotli.

Il vous suffit des en-têtes de réponse bruts d'une seule URL, et il existe trois moyens simples de les obtenir. Dans les DevTools de Chrome ou Firefox, ouvrez l'onglet Réseau, rechargez la page, cliquez sur la requête du document principal, et copiez le bloc Response Headers. Depuis un terminal, curl -I https://example.com affiche les en-têtes sans télécharger le corps de la réponse, et curl -sI -H "Accept-Encoding: br,gzip" https://example.com indique au serveur que vous acceptez la compression afin qu'il renvoie effectivement une réponse encodée. L'outil analyse n'importe quelle liste de lignes En-tête: valeur, donc un simple copier-coller fonctionne très bien. Portez attention à Content-Encoding, Content-Type, Content-Length et Vary, car ce sont eux qui déterminent le verdict. Collez les en-têtes ci-dessus et le vérificateur détaille chaque ligne pertinente en langage clair.

Un verdict Partielle signifie que la compression fonctionne techniquement, mais qu'un élément de la configuration pourrait poser problème. Le déclencheur le plus courant est un en-tête Vary manquant ou incomplet. Si Content-Encoding indique br ou gzip mais qu'il n'y a pas de Vary: Accept-Encoding, un proxy partagé ou un CDN peut mettre en cache la copie compressée et la servir plus tard à un client qui ne l'avait jamais demandée, produisant des pages illisibles. Le vérificateur rétrograde volontairement ce cas en Partielle et recommande d'ajouter l'en-tête. Il signale aussi un en-tête Vary existant mais qui omet Accept-Encoding, ainsi que des anomalies au niveau de Transfer-Encoding. Partielle n'est donc pas une fausse alerte ; cela pointe vers un vrai risque de mise en cache qu'une simple vérification « est-ce gzippé ? » laisserait passer. Collez vos en-têtes ci-dessus pour voir exactement quel signal a déclenché la rétrogradation et comment le corriger.

La compression n'aide que lorsqu'il reste de la redondance à éliminer, elle est donc rentable sur les formats textuels et inutile sur les binaires déjà compressés. Les types hautement compressibles incluent HTML, CSS, JavaScript, JSON, XML et SVG, où gzip ou Brotli peuvent réduire la taille de 65 à 78 % environ. Le vérificateur les marque comme Hautement compressibles et recommande d'activer l'encodage s'il est absent. Les fichiers déjà compressés au niveau du format, comme JPEG, PNG, WebP, MP4, PDF, les polices WOFF2 et les archives ZIP, ne gagnent presque rien à être recompressés ; l'outil les marque Déjà compressés et ne vous pousse pas à les encoder. Connaître cette différence permet de cibler la compression là où elle améliore réellement le temps de chargement plutôt que de ralentir le serveur. Collez vos en-têtes ci-dessus et le vérificateur évalue automatiquement votre Content-Type.

Le chiffre d'économies est une estimation de planification, pas une valeur mesurée pour votre fichier exact. Lorsqu'un en-tête Content-Length est présent, le vérificateur applique des ratios réels typiques pour les contenus texte : environ 70 % de réduction pour gzip, 78 % pour Brotli, 65 % pour deflate, et 75 % pour zstd. Sur une réponse déjà compressée, il remonte le calcul à partir de ces ratios pour approximer la taille non compressée d'origine, et sur une réponse non compressée, il projette les économies probables que gzip apporterait. Comme la compression réelle dépend fortement du contenu précis, un balisage répétitif se compresse bien mieux qu'un texte dense et unique, vous devriez considérer ce chiffre comme un repère directionnel pour prioriser les corrections plutôt que comme un nombre d'octets exact. Pour des chiffres précis, comparez le Content-Length réel avant et après l'activation de la compression. Collez vos en-têtes ci-dessus pour voir l'estimation aux côtés du verdict complet.