Gzip ou Brotli ? Pourquoi votre site doit compresser ses pages
Une page non compressée peut peser 5 fois plus que nécessaire. Le test #01 le vérifie instantanément — et la correction prend moins de 5 minutes.
- La compression HTTP (Gzip ou Brotli) réduit le poids des pages de 60 à 80 % — les visiteurs téléchargent moins, les pages chargent plus vite
- Le test #01 d'Orilyt vérifie l'en-tête Content-Encoding : compressé = 100, non compressé = 25. Binaire, pas de zone grise
- La plupart des hébergeurs l'activent en un clic — le ratio effort/impact est exceptionnel
Une page WordPress typique génère 50 à 200 Ko de HTML. Ajoutez le CSS, le JavaScript et les polices web — et vous atteignez facilement 1 Mo de ressources textuelles. Multipliez par chaque visiteur, chaque chargement.
La compression HTTP résout ce problème : le serveur compresse la réponse avant de l'envoyer, le navigateur la décompresse à l'arrivée. Le transfert diminue de 60 à 80 %. Le visiteur télécharge moins, la page charge plus vite, et Google le remarque.
Le plus surprenant ? Environ 15 % des sites WordPress n'ont toujours pas la compression activée. Ce n'est pas une optimisation complexe — c'est un réglage serveur. Et le test #01 d'Orilyt le détecte en moins de 2 secondes.
Comment fonctionne la compression HTTP
Quand votre navigateur envoie une requête, il inclut un en-tête Accept-Encoding listant les formats de compression qu'il supporte (typiquement gzip et br pour Brotli). Le serveur en choisit un, compresse la réponse, et la renvoie avec un en-tête Content-Encoding.
- Gzip — le standard universel depuis les années 2000. Supporté par tous les navigateurs et serveurs. Réduit le texte de 60 à 70 %. Compression et décompression rapides
- Brotli (br) — développé par Google, disponible depuis 2016. Compresse 15 à 25 % mieux que Gzip en moyenne. Supporté par tous les navigateurs modernes. Légèrement plus lent à compresser mais plus rapide à décompresser
- Pas de compression — le serveur envoie du texte brut. Le navigateur reçoit 3 à 5 fois plus de données que nécessaire. Les temps de chargement augmentent proportionnellement
La compression s'applique à toutes les ressources textuelles : HTML, CSS, JavaScript, JSON, XML, SVG. Les images (JPEG, PNG, WebP) sont déjà compressées par leur format et ne sont pas concernées.
En pratique, Brotli est le meilleur choix quand il est disponible. Mais Gzip est parfaitement suffisant — l'important, c'est que la compression soit activée.
Comment Orilyt note la compression
Le test #01 est binaire. Orilyt inspecte l'en-tête Content-Encoding de la réponse du serveur :
- L'en-tête contient "br" ou "gzip" → Score 100 — Compressé. Le serveur fait son travail
- L'en-tête est absent ou vide → Score 25 — Non compressé. Chaque chargement transfère des données inutiles
Orilyt détecte également la source de compression. Si un CDN comme Cloudflare ou QUIC.cloud est devant le site, il gère souvent la compression en périphérie — même si le serveur d'origine ne le fait pas. Le test distingue compression CDN et compression serveur.
Pourquoi la compression est parfois absente
Si la compression est si simple, pourquoi manque-t-elle sur 15 % des sites ? Raisons courantes :
- Configuration serveur par défaut — certains hébergeurs livrent la compression désactivée. Le propriétaire du site ne vérifie jamais
- .htaccess mal configuré — un plugin ou une modification manuelle a supprimé les règles mod_deflate/mod_brotli. Ou un reset du .htaccess les a effacées
- Nginx sans gzip on — Nginx a la compression désactivée par défaut. Il faut ajouter explicitement gzip on; dans la configuration
- Conflit de proxy inverse — un load balancer ou un WAF supprime l'en-tête Content-Encoding. Le serveur compresse, mais le visiteur reçoit du texte brut
La bonne nouvelle : dans 90 % des cas, la correction prend moins de 5 minutes. C'est soit une case à cocher dans le panel hébergeur, une ligne dans le .htaccess, ou un réglage de plugin.
La compression comme argument de vente
Pour les freelances et agences, un constat de compression manquante est en or. C'est facile à expliquer, spectaculaire en impact, et trivial à corriger :
Dans le rapport Orilyt, le test #01 génère une recommandation FIA structurée :
- Fait : « Aucune compression HTTP détectée — la page est servie à plein poids (187 Ko au lieu de ~45 Ko) »
- Impact : « Chaque visiteur télécharge 4 fois plus de données que nécessaire. Sur mobile, cela ajoute 1 à 3 secondes au chargement »
- Action : « Activer la compression Gzip ou Brotli dans la configuration serveur — amélioration estimée : 60 à 80 % de réduction de poids »
Un score de 25/100 dès le premier test de l'audit signale immédiatement un site négligé. C'est le genre de constat qui fait dire au client « on a besoin d'aide ».
La correction de 5 minutes qui change tout
La compression est le fruit le plus accessible en performance web. Pas de changement de code, pas de redesign, pas de stratégie de cache complexe — juste un réglage serveur qui réduit chaque transfert de 60 à 80 %.
Le test #01 d'Orilyt le détecte instantanément. Le scoring binaire (100 ou 25) rend le résultat limpide — pas d'ambiguïté.
Si vous construisez des propositions basées sur l'audit pour vos clients, c'est le test qui démontre une valeur immédiate et tangible. Une correction de 5 minutes avec un avant/après mesurable. C'est comme ça qu'on démarre une conversation.