Qu'est-ce que la compression Gzip et Brotli ?

Gzip et Brotli sont des algorithmes de compression que votre serveur web utilise pour réduire la taille des fichiers avant de les envoyer au navigateur du visiteur. L'idée est simple : les fichiers textuels comme HTML, CSS et JavaScript contiennent beaucoup de motifs répétitifs, et les algorithmes de compression sont très efficaces pour trouver et éliminer cette redondance. Un fichier HTML de 100 Ko peut être compressé à 15-20 Ko. Le navigateur le décompresse instantanément, et le visiteur ne remarque rien d'autre qu'un chargement de page plus rapide.

Si vous avez déjà compressé un dossier sur votre ordinateur, vous comprenez déjà le concept de base. La compression web fonctionne de la même manière, mais automatiquement et de manière transparente. Le serveur compresse la réponse, le navigateur la décompresse, et ni le développeur ni le visiteur n'ont besoin de faire quoi que ce soit de spécial (à condition que le serveur soit configuré correctement).

Comment fonctionne la compression web au niveau du protocole

Chaque fois qu'un navigateur envoie une requête HTTP, il inclut un en-tête Accept-Encoding qui indique au serveur quels algorithmes de compression il prend en charge :

Accept-Encoding: gzip, deflate, br

Cet en-tête indique que le navigateur peut gérer Gzip, Deflate et Brotli (abrégé en br). Le serveur choisit le meilleur algorithme qu'il prend en charge, compresse le corps de la réponse et ajoute un en-tête Content-Encoding pour indiquer au navigateur quel algorithme a été utilisé :

Content-Encoding: gzip

ou :

Content-Encoding: br

Le navigateur lit cet en-tête, applique l'algorithme de décompression correspondant et affiche le contenu. Si le serveur ne prend pas en charge la compression (ou s'il n'est pas configuré), il envoie la réponse non compressée, et aucun en-tête Content-Encoding n'est présent.

Cette négociation se produit à chaque requête. Le serveur peut choisir différentes méthodes de compression pour différents types de fichiers, ou même servir du contenu non compressé pour les fichiers qui ne bénéficient pas de la compression.

Gzip : le standard établi

Gzip est le cheval de bataille de la compression web depuis la fin des années 1990. Il est basé sur l'algorithme DEFLATE (une combinaison de LZ77 et du codage de Huffman) et est pris en charge par littéralement tous les navigateurs et serveurs web utilisés aujourd'hui. Lorsque les gens parlent d'« activer la compression » sur un serveur web, ils font généralement référence à Gzip.

Gzip fonctionne avec des niveaux de compression configurables, allant généralement de 1 (le plus rapide, compression la plus faible) à 9 (le plus lent, meilleure compression). La plupart des serveurs web utilisent par défaut le niveau 6, qui offre un bon équilibre entre taux de compression et utilisation du processeur. Au niveau 6, Gzip atteint généralement 70-85 % de compression sur les fichiers textuels. Cela signifie qu'un fichier CSS de 100 Ko devient environ 15-30 Ko.

Les principaux avantages de Gzip sont son universalité (il fonctionne partout), sa rapidité à des niveaux de compression modérés et les décennies d'optimisation qui ont été apportées à ses implémentations. Le principal inconvénient est qu'il ne compresse pas aussi bien que Brotli, en particulier pour les fichiers plus petits.

Brotli : l'alternative moderne

Brotli a été développé par Google et publié sous la RFC 7932 en 2016. Il a été spécifiquement conçu pour le contenu web et atteint des taux de compression de 15-25 % supérieurs à Gzip sur les ressources web typiques. Brotli y parvient en utilisant un algorithme de compression plus sophistiqué et en incluant un dictionnaire intégré de chaînes courantes trouvées dans le contenu web (balises HTML, propriétés CSS, mots-clés JavaScript, etc.).

Brotli utilise également des niveaux de compression configurables, allant de 0 à 11. À des niveaux de qualité comparables, Brotli produit une sortie plus petite que Gzip, mais aux niveaux les plus élevés (10-11), il est nettement plus lent à compresser. Cela rend la compression Brotli de haut niveau idéale pour les ressources statiques pouvant être pré-compressées une fois et servies plusieurs fois, mais moins adaptée au contenu dynamique qui doit être compressé à chaque requête.

Une limitation importante : Brotli ne fonctionne que sur HTTPS. Les navigateurs n'accepteront pas les réponses compressées en Brotli sur des connexions HTTP simples. Comme la plupart des sites WordPress devraient de toute façon être en HTTPS (et HTTP/2 l'exige), ce n'est rarement un problème pratique.

Gzip vs Brotli : une comparaison pratique

Voici comment les deux algorithmes se comparent sur les métriques importantes pour les propriétaires de sites WordPress :

• Taux de compression : Brotli produit généralement des fichiers 15-25 % plus petits que Gzip à des niveaux de compression comparables. Sur un site WordPress qui charge 500 Ko de ressources compressibles, cette différence se traduit par environ 15-30 Ko de données en moins transférées par chargement de page.
• Vitesse de compression : Gzip au niveau 6 est plus rapide que Brotli à un réglage de qualité équivalent. Pour le contenu dynamique (pages HTML générées par PHP), Gzip est souvent le choix le plus pratique car la compression se produit à chaque requête. Brotli aux niveaux 1-4 est comparable en vitesse à Gzip et compresse encore un peu mieux.
• Vitesse de décompression : Brotli se décompresse légèrement plus vite que Gzip, ce qui signifie que le navigateur peut traiter le contenu un peu plus rapidement. La différence est faible mais constante.
• Prise en charge des navigateurs : tous les navigateurs modernes prennent en charge à la fois Gzip et Brotli. Internet Explorer (désormais abandonné) ne prenait pas en charge Brotli, mais Edge, Chrome, Firefox et Safari le font tous. La prise en charge mondiale du navigateur pour Brotli est supérieure à 96 %.
• Prise en charge des serveurs : Apache prend en charge Brotli via mod_brotli (disponible depuis Apache 2.4.26). Nginx le prend en charge via le module ngx_brotli (un module tiers qui doit être compilé séparément). LiteSpeed dispose d'une prise en charge intégrée de Brotli. La plupart des hébergeurs gérés et des CDN prennent en charge les deux.
• Exigence HTTPS : Brotli nécessite HTTPS. Gzip fonctionne à la fois sur HTTP et HTTPS.

En pratique, de nombreux serveurs sont configurés pour préférer Brotli lorsque le navigateur le prend en charge et se rabattre sur Gzip sinon. Cela vous donne la meilleure compression pour les navigateurs modernes tout en maintenant la compatibilité avec les clients plus anciens.

Comment activer la compression dans Apache

Pour Apache, vous activez la compression Gzip via mod_deflate (au nom prêtant à confusion, mais qui utilise Gzip, pas Deflate brut). Ajoutez ce qui suit à votre fichier .htaccess :

  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE application/font-woff2

Pour Brotli sur Apache, vous avez besoin de mod_brotli :

  AddOutputFilterByType BROTLI_COMPRESS text/html
  AddOutputFilterByType BROTLI_COMPRESS text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json

Comment activer la compression dans Nginx

Pour Nginx, Gzip est intégré et il suffit de l'activer dans la configuration :

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Pour Brotli sur Nginx, après avoir installé le module ngx_brotli :

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Extensions de cache WordPress et compression

Si vous n'avez pas accès à la configuration de votre serveur (courant sur l'hébergement mutualisé), plusieurs extensions de cache WordPress peuvent gérer la compression pour vous :

• WP Rocket : active automatiquement la compression Gzip en ajoutant des règles à votre fichier .htaccess. Il crée également des fichiers de cache HTML statiques pré-compressés.
• W3 Total Cache : propose la compression Gzip comme option configurable dans ses paramètres de Browser Cache. Il peut également servir des fichiers pré-compressés.
• LiteSpeed Cache : si votre hébergeur exécute le serveur LiteSpeed, cette extension active automatiquement à la fois la compression Gzip et Brotli.
• WP Super Cache : inclut une option de compression Gzip qui compresse les pages mises en cache.
• Autoptimize : bien qu'il s'agisse principalement d'une extension d'optimisation CSS/JS, il peut également servir des versions compressées des fichiers qu'il génère.

Gardez à l'esprit que si votre serveur gère déjà la compression au niveau du serveur, l'activer à nouveau via une extension est inutile et peut parfois provoquer des conflits (double compression, que les navigateurs ne peuvent pas décompresser).

Quels types de fichiers bénéficient le plus de la compression

La compression fonctionne mieux sur du contenu textuel et répétitif. Voici une répartition par type de fichier :

• HTML : se compresse extrêmement bien (réduction de 70-90 %). Les pages HTML générées par WordPress regorgent de structures de balises répétitives, de noms de classes et d'espaces blancs.
• CSS : se compresse très bien (réduction de 80-90 %). Les feuilles de style contiennent de nombreux noms de propriétés et sélecteurs répétés.
• JavaScript : se compresse très bien (réduction de 70-85 %). Les fichiers JS comportent des mots-clés, noms de fonctions et motifs structurels répétés.
• SVG : se compresse extrêmement bien (réduction de 80-95 %). Les SVG sont basés sur XML et très répétitifs.
• JSON : se compresse très bien (réduction de 75-90 %). Les réponses d'API et les données de configuration en bénéficient grandement.
• Flux XML et RSS : se compressent très bien grâce à leur structure de balises répétitive.
• Polices web (WOFF/WOFF2) : les polices WOFF2 incluent déjà la compression Brotli en interne, donc une compression supplémentaire côté serveur n'apporte qu'un bénéfice minimal. Les polices WOFF incluent une compression plus légère et peuvent légèrement bénéficier de Gzip.

Ce qui NE doit PAS être compressé

Tous les types de fichiers ne bénéficient pas de la compression, et certains doivent activement être exclus :

• Images JPEG, PNG, WebP, AVIF : ces formats sont déjà compressés. Les faire passer par Gzip ou Brotli gaspille du temps processeur et peut même augmenter légèrement la taille du fichier.
• Fichiers vidéo (MP4, WebM) : déjà compressés avec des codecs très efficaces. La compression côté serveur ajoute une surcharge sans aucun bénéfice.
• Fichiers audio (MP3, AAC, OGG) : comme la vidéo, déjà compressés.
• ZIP, GZIP et autres archives : déjà compressés par définition.
• Fichiers PDF : la plupart des PDF utilisent une compression interne. La compression supplémentaire offre des économies négligeables.

Compresser des fichiers déjà compressés gaspille le processeur du serveur à chaque requête et peut même entraîner une sortie légèrement plus grande. La plupart des configurations de serveurs web et des extensions de cache WordPress limitent correctement la compression aux types MIME textuels, mais il vaut la peine de vérifier votre configuration pour s'assurer que les fichiers binaires sont exclus.

Ce que vérifie InspectWP

InspectWP examine l'en-tête de réponse Content-Encoding renvoyé par votre site WordPress pour déterminer si la compression est active. Il recherche spécifiquement gzip, br (Brotli) ou deflate dans la valeur de l'en-tête. Si aucune compression n'est détectée, le rapport signale cela comme un problème de performance avec une recommandation d'activer la compression Gzip ou Brotli. La méthode de compression détectée est affichée dans la section performance du rapport, vous donnant une vue claire de savoir si votre serveur est correctement configuré pour réduire les tailles de transfert.