Vérificateur de compression

Colle une URL et vois ce que Gzip ou Brotli fait vraiment dessus : les headers du HEAD à côté du GET, le Vary, le cache et le parcours des redirections, sur un seul écran.

Ce vérificateur de compression te montre ce que Gzip ou Brotli fait vraiment sur une URL, côté serveur, au lieu d'afficher un badge vert ou rouge et de te laisser deviner. Colle une adresse publique et il lit la toute première réponse HEAD, récupère les headers du GET de la page juste à côté quand le backend arrive à parser la destination comme du HTML, parcourt les redirections, puis sort le Content-Encoding et le Vary et range les headers de cache à côté de tout ça. Pourquoi se prendre la tête ? Parce qu'un simple badge pas de compression ment la moitié du temps. Une redirection a remplacé la vraie page, ou le HEAD a répondu autrement que le GET, ou tu l'as pointé sur un JPEG déjà compressé. Il note la passe, nomme les ressources texte à traquer face aux médias à laisser tranquilles, et te donne un rapport copiable. Pensé pour l'audit WordPress, CDN, reverse proxy et origine que tu lances quand une page pèse plus lourd qu'elle ne le devrait.

Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.

Audit des signaux de compression et de livraison HTTP

Colle une URL publique. Je te montre ce qui se passe vraiment avec Gzip ou Brotli dessus. D'abord les headers du HEAD, puis ceux du GET de la page juste à côté, le parcours des redirections, le contexte du cache, tout sur un seul écran. Pourquoi se prendre la tête avec ça ? Parce qu'un simple badge "pas de compression" ment, et il ment souvent. La moitié du temps tu regardes en fait une redirection qui a remplacé la page, ou une image que personne n'a jamais cherché à gzipper. J'en avais marre de plisser les yeux devant un point rouge en essayant de deviner lequel des deux c'était.

URL à vérifier

Type de ressource attendu

La compression se négocie réponse par réponse, pas site par site. Du coup je l'échantillonne avec soin. La première lecture des headers tape sur l'URL exacte que tu as tapée, avant que quoi que ce soit ne suive une redirection. La lecture du GET de la page n'apparaît que quand le backend arrive à lire la destination comme du HTML.

Ce qu'un vérificateur de compression devrait prouver

Un vérificateur de compression devrait prouver ce que Gzip ou Brotli fait vraiment sur une URL, pas afficher un badge vert ou rouge et s'arrêter là. La compression, c'est un de ces gains dont personne ne se vante. Sauf qu'il est gratuit, et bien réel. Envoie du HTML, du CSS, du JavaScript, du JSON, du XML ou du SVG sur le réseau avec Gzip ou Brotli correctement négocié, et le poids transféré chute fort. Franchement, tout ce que j'ai jamais attendu d'un vérificateur, c'est de l'honnêteté. Montre-moi la négociation. Ne hurle pas "cassé" à la seconde où un header Content-Encoding manque, parce que la plupart du temps rien n'est cassé. Une redirection a discrètement remplacé la vraie page. Ou le HEAD a répondu d'une façon et le GET du navigateur aurait répondu autrement. Ou alors, soyons honnêtes, tu l'as pointé sur un JPEG déjà compressé, et une deuxième couche de compression ne te rapporte quasiment rien. Donc celui-ci garde le contexte directement dans le rapport au lieu de le jeter. Il lit la toute première réponse, récupère les headers du GET de la page quand le backend arrive à lire la destination comme du HTML, parcourt les lignes de redirection, sort le Content-Encoding et le Vary, puis range les headers de cache juste à côté de tout ça.

Gzip, Brotli et la réponse qui compte

Gzip est partout et il ne va nulle part. Brotli apparaît beaucoup pour le texte moderne, surtout en HTTPS. Honnêtement quand même, j'arrêterais de courir après le nom le plus clinquant. Ce qui compte vraiment, c'est de savoir si le texte final que tes visiteurs téléchargent arrive petit et est bien mis en cache pour chaque variante que tu sers. Et garde ça en tête : le serveur peut donner du Brotli à un client, du Gzip au suivant, un corps brut non compressé à un outil de diagnostic qui a envoyé des headers bizarres. La seule réponse que tu as échantillonnée, ce n'est pas toute l'histoire.

Content-Encoding nomme l'encodage appliqué à cette seule réponse que j'ai échantillonnée. Rien de plus.
Vary c'est ce qui dit aux caches de bien séparer les variantes Accept-Encoding pour qu'elles ne se mélangent pas.
Content-Type c'est comme ça que tu décides si la compression a sa place sur cette ressource ou pas.
Cache-Control couvre une bonne partie de ce qui se passe aux visites suivantes, et au niveau du CDN aussi.
Le parcours des redirections c'est ta preuve que tu as audité la vraie destination, pas une vieille URL périmée.

Quand une compression manquante mérite qu'on agisse

Alors, quand est-ce que j'irais vraiment fouiller ça ? Tu as une vraie page HTML, une feuille de style, un script, une réponse JSON ou un flux XML assez gros pour se sentir, et aucune compression n'apparaît nulle part sur le chemin qui compte. Celui-là vaut ton temps. Va titiller l'origine et l'edge. Sur WordPress c'est en général l'un d'un petit casting de suspects : un réglage par défaut de l'hébergeur, une règle Nginx ou Apache, un plugin de performance, un interrupteur du CDN, une règle de proxy, une couche de cache qui renvoie discrètement une variante différente de celle que tu crois récupérer. Ce que je ne ferais pas, c'est me mettre à gzipper tes JPEG, WebP, MP4 ou ZIP juste pour faire passer un vérificateur au vert. Ils sont déjà compressés. Tu vas cramer du CPU pour rien. Et sois honnête sur le poids tant que tu y es. La compression rogne des octets sur le texte, point. Elle ne sauvera pas une image hero de 4 Mo, un tas de scripts, du travail render-blocking, un cache que tu n'as jamais pris la peine de configurer, ou un backend qui a besoin d'une seconde entière pour construire la page.

Un workflow de compression concret

Teste l'URL finale canonique. Pas la vieille qui te renvoie juste ailleurs.
Lis le Content-Type d'abord, comme ça tu sais déjà si la compression a sa place ici.
Aligne le Content-Encoding et le Vary sur tous les échantillons que tu as réellement réussi à obtenir.
Regarde les headers de cache et le comportement du CDN avant de te lancer à réécrire des règles serveur à l'aveugle.
Reteste après chaque changement : une purge de cache, un réglage d'hébergement, une bascule du CDN, un interrupteur de plugin.

Questions fréquentes

Brotli est-il toujours meilleur que Gzip ?

Toujours ? Non. Brotli compresse en général le texte plus fort, c'est vrai, mais l'encodage qui gagne vraiment, c'est celui qui est bien négocié et servi à chaque fois sans flancher. Celui qui est prouvé sur ton vrai chemin. Gzip fait toujours le boulot et tourne partout, alors ne le raye pas de la liste.

Faut-il compresser chaque fichier ?

Non. Le texte, c'est la cible ici. Tes images, vidéos, archives et polices modernes arrivent déjà compressées ou packées autrement, donc coller du Gzip par-dessus crame surtout du CPU pour économiser une erreur d'arrondi.

La compression garantit-elle une page rapide ?

J'aimerais bien. Tout ce qu'elle fait, c'est réduire le coût de transfert sur ce qui vaut le coup d'être compressé. La latence du backend, le caching, le travail de rendu, ton JavaScript, le poids des images, chaque script tiers, ils ont tous leur mot à dire. Et d'habitude ils crient plus fort que la compression ne le fera jamais.

Pourquoi ma compression ne marche pas ?

Rassemble les suspects habituels. Le module serveur n'est pas activé. Ton type de contenu n'est pas dans la liste des compressibles. La réponse est déjà binaire. Ou un proxy quelque part au milieu strippe discrètement le header Accept-Encoding avant qu'il n'atteigne l'origine.