G11 — Chapitre 7 - SEO Technique

Critère SEO G11 : Compression Gzip/Brotli — guide + exemple

PARTIE 1 - Fondamentaux Chapitre 7 - SEO Technique Mot-clé : compression gzip/brotli

Ce critère paraît “simple”, mais il crée beaucoup d’écarts en production.

Le critère **G11 — Compression Gzip/Brotli** fait partie de notre checklist SEO (335 critères). Ici, tu as une méthode **pratique** pour le vérifier et le corriger — avec un exemple concret.

Ce que couvre exactement ce critère

Le critère SEO G11 du Chapitre 7 - SEO Technique, Partie 1, porte sur la compression gzip/brotli appliquée aux fichiers HTML et ressources serveur. Il s'agit d'activer et optimiser la compression serveur pour HTML, CSS, JS, afin de réduire la taille des fichiers transmis entre serveur et client de 70 à 90%. Cette compression permet d’accélérer le temps de chargement des pages et d'améliorer l'efficacité des audits SEO en garantissant une bonne optimisation on-page.

Pourquoi c'est important (SEO + UX)

La compression gzip/brotli est cruciale pour le SEO technique car elle diminue significativement le poids des pages, ce qui réduit la latence et améliore la vitesse de rendu. Google privilégie les sites rapides, ce qui impacte directement le classement. Côté UX, une page rapide augmente la satisfaction utilisateur, diminue le taux de rebond et favorise la conversion. La réduction de 70-90% de la taille des fichiers est un levier puissant pour optimiser la performance globale.

Comment vérifier (pas à pas)

  1. Utilisez l'outil en ligne WebPageTest ou GTmetrix pour détecter la compression active. 2) Inspectez les en-têtes HTTP via l'onglet Réseau dans Chrome DevTools, recherchez 'content-encoding: gzip' ou 'br'. 3) Lancez un audit SEO avec Screaming Frog ou Sitebulb pour confirmer la compression sur toutes les ressources critiques. 4) Vérifiez la checklist technique G11 pour couvrir tous les fichiers HTML, CSS, JS compressés.

Comment corriger proprement

Activez la compression gzip ou brotli directement sur le serveur web (Apache, Nginx, IIS). Par exemple, pour Nginx, ajoutez dans la config :

```nginx
brotli on;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;
```

Pour Apache, activez mod_deflate et configurez les types mime. Testez systématiquement la compression après modification pour éviter tout impact négatif. Priorisez brotli, plus efficace, tout en assurant la compatibilité gzip pour les navigateurs anciens.

Exemple concret (illustratif)

Sur un site e-commerce, la compression gzip activée a réduit la taille moyenne des fichiers HTML de 85%, passant de 120 Ko à 18 Ko, diminuant le temps de chargement initial de 2,5s à 1s. Cette optimisation technique a permis une meilleure note PageSpeed Insights et une hausse du taux de conversion de 10% dans les 3 mois suivant l'audit SEO et la correction.

Checklist à cocher

  • Compression gzip ou brotli activée sur le serveur
  • Tous les fichiers HTML, CSS, JS compressés
  • Vérification via outils (GTmetrix, WebPageTest)
  • En-têtes HTTP correctement configurés (content-encoding)
  • Tests post-correction pour compatibilité et performance
  • Documentation mise à jour dans l'audit SEO (g11)
FAQ

Questions fréquentes — G11

Quelle est l’erreur la plus fréquente sur “Compression Gzip/Brotli” ?

Corriger une page isolée sans corriger le template/import : l’erreur revient à la prochaine génération.

Quel outil est le plus rapide pour contrôler à l’échelle ?

Pour ce type de critère, un crawl (ex. Screaming Frog) + une vérification ciblée dans Chrome DevTools Network est généralement le combo le plus rapide.

Comment éviter que ça se reproduise sur 10K pages générées ?

Figer une règle d’auto‑génération (title/structure/schema/URLs) + ajouter un contrôle automatique (crawl ou test) avant import en production.

Prêt à passer de la théorie à l'action ?

Validez ce critère avec un audit, puis approfondissez la méthode dans l'Academy.

Auditer avec l'outil → Apprendre dans l'Academy →