[WP] Compression Gzip vs Brotli : différences entre les deux algorithmes de compression
Pour rendre un site web plus rapide, y compris un site sous le CMS WordPress, il est utile de configurer la compression des données sur le serveur. Les données échangées entre le serveur web et le navigateur se chargent alors plus vite, et tout le site gagne en rapidité. C'est l'un des points auxquels les administrateurs de sites pensent le plus. La compression gzip est très répandue, et de nombreux serveurs web passent progressivement de gzip à Brotli pour la compression, une tendance en hausse.
1️⃣ Qu'est-ce que la compression ?
Site URL : à son ouverture, un échange commence entre le navigateur et le serveur. Le navigateur indique alors au serveur s'il peut défaire la compression du contenu (Compression) et quels algorithmes de compression il utilise. Le navigateur peut ainsi décompresser correctement les données que le serveur envoie compressées. Avec un serveur et un navigateur compatibles avec ces algorithmes, votre site se charge donc encore plus vite.
Quand un navigateur se connecte à un serveur, il envoie des en-têtes comme la compression gzip ou Brotli. Les données compressées avec l'une des deux sont livrées au navigateur, et des données compressées se chargent plus vite que des données non compressées.
Content-encoding: gzip
Content-encoding: br
Vérifier la compression Gzip 
Vérifier la compression Brotli
Les fichiers compressés sont surtout des fichiers texte : · HTML · CSS · JavaScript
2️⃣ Qu'est-ce que la compression Gzip ?
Les algorithmes de compression courants chez les hébergeurs web sont Gzip et Brotli. Gzip est sorti en bêta en 1992, puis en version 1.0 en 1993. En général, Gzip est l'une des méthodes standard pour compresser les données transmises sur Internet. Elle repose sur DEFLATE, un des premiers algorithmes de compression, et tient son nom de gzip, un programme de compression de fichiers développé auparavant pour Unix.
DEFLATE associe l'algorithme LZ77 (Lempel-Ziv 1977) au codage de Huffman. LZ77 recherche les données répétées, repère les chaînes identiques et les remplace par des codes. Le codage de Huffman attribue les codes binaires les plus courts selon la fréquence d'apparition de chaque caractère.
Gzip compresse les données avec DEFLATE et, grâce à l'en-tête ‘Accept-Encoding: gzip’ des requêtes et réponses HTTP, ne compresse que si le client prend en charge Gzip. Cette compression accélère le chargement du site.
3️⃣ Qu'est-ce que la compression Brotli ?
Brotli a été développé en 2013 par Jyrki Alakuijala et Zoltán Szabadka, employés de Google.
Gzip servait à l'origine à compresser des fichiers, mais il a été adapté pour le web. Brotli, en revanche, a été conçu pour le web. Avec Brotli, le serveur web peut donc compresser le contenu avant de l'envoyer au navigateur. Comme il est compressé avant d'être diffusé vers le navigateur, c'est une méthode meilleure et plus avancée.
Brotli utilise les deux mêmes techniques de base que la compression GZIP : LZ77 et le codage de Huffman.
4️⃣ Compression Gzip vs compression Brotli
Gzip compresse (& décompresse) les données avec la méthode DEFLATE, et Brotli avec son propre format, qui ajoute la modélisation de contexte à LZ77 et au codage de Huffman.
- Gzip compresse plus vite que Brotli.
- Brotli a été conçu spécifiquement pour le web.
- Brotli offre un meilleur taux de compression (c'est-à-dire des fichiers compressés plus petits) à tous les niveaux.
- Par rapport à Gzip, Brotli compresse mieux ces trois types de fichiers : de 21 % pour le HTML, 17 % pour le CSS et 14 % pour le JavaScript.
De plus en plus de serveurs web préfèrent Brotli à Gzip. Comme Brotli est conçu pour compresser les flux à la volée, sa décompression côté front-end serait jusqu'à 64 % plus rapide que celle de Gzip.
La RFC 1952, publiée en mai 1996, explique que le format Gzip utilise la méthode de compression DEFLATE et contient une valeur CRC pour détecter les données corrompues. La valeur CRC-32 et la taille des données d'origine sont inscrites à la fin des données compressées.
La RFC 7932, publiée en juillet 2016, indique que Brotli compresse en combinant l'algorithme LZ77 et le codage de Huffman. Il choisit en outre les codes de Huffman en prenant pour contexte les deux octets précédents des données non compressées, et peut aussi renvoyer, au lieu de chaînes répétées, à des mots d'un dictionnaire statique de 122 784 octets.
Les deux formats apparaissent dans l'en-tête de réponse sous la forme [Content-Encoding: gzip] et [Content-Encoding: br]. La valeur [br] a été enregistrée comme codage de contenu HTTP dans la RFC 7932.
| Catégorie | Gzip | Brotli |
|---|---|---|
| Spécification | RFC 1952 · mai 1996 | RFC 7932 · juillet 2016 |
| Méthode de compression | DEFLATE (LZ77 et codage de Huffman) | LZ77 et codage de Huffman · contexte des deux octets précédents · dictionnaire statique de 122 784 octets |
| En-tête de réponse | Content-Encoding: gzip | Content-Encoding: br |
5️⃣ Mesure de la compression Gzip et Brotli : serveur Nginx + Apache
Sur un serveur WordPress qui utilise Nginx et Apache ensemble, les réponses pour un même article, le fichier CSS des blocs par défaut de WordPress et le fichier jQuery ont été comparées en ne changeant que l'en-tête de requête. Des requêtes avec seulement gzip dans [Accept-Encoding], avec seulement br et sans cet en-tête ont été envoyées avec curl depuis le même serveur.
for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833Le HTML d'un article a été compressé à 21 390 octets avec la requête gzip et à 20 190 octets avec la requête br, et la requête sans en-tête a reçu les 90 833 octets non compressés. La réponse br était plus petite que la réponse gzip de 1 200 octets (5,6 %).
for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553Avec la requête gzip, le fichier CSS a été compressé à 19 655 octets et le fichier jQuery à 30 633 octets. Avec br seul ou sans en-tête, le serveur a renvoyé les originaux de 140 829 et 87 553 octets tels quels, sans en-tête [Content-Encoding].
nginx -V 2>&1 | grep -c brotli0httpd -M 2>/dev/null | grep -E 'brotli|deflate' deflate_module (shared)
brotli_module (shared)Les fichiers statiques comme le CSS et le JS sont servis et compressés directement par Nginx, et comme le Nginx de cette configuration n'a pas de module Brotli, il ne compresse qu'en gzip.
Pour le HTML, WordPress répond à la requête que Nginx transmet à Apache, et Apache compresse la réponse. Apache dispose à la fois du module Brotli et du module [mod_deflate], chargé de la compression Gzip.
for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633Avoir un module Brotli sur le serveur ne veut pas dire que le navigateur reçoit des réponses compressées en Brotli. Avec une requête [gzip, deflate, br, zstd], la même valeur qu'envoie Edge 155, Apache a lui aussi compressé le HTML en gzip, et les trois fichiers ont été renvoyés en gzip.
Même en plaçant br avant gzip ou en indiquant br comme prioritaire, comme dans [br;q=1.0, gzip;q=0.5], le HTML a été renvoyé en gzip. En ouvrant le même article et les deux fichiers dans Edge, tout a aussi été transféré en gzip.
Le temps jusqu'au premier octet est la médiane des valeurs [time_starttransfer] de curl, mesurées 40 fois chacune en mélangeant l'ordre des requêtes ; chaque requête ouvrait une nouvelle connexion, le temps de connexion TLS est donc inclus. Pour le HTML, la réponse non compressée a pris 22,7 ms, gzip 26,3 ms, br 26,5 ms et la requête identique à celle d'un navigateur 25,0 ms. Le CSS et le JS restaient entre 18 et 21 ms, avec ou sans compression.
La vitesse de compression de Gzip et de Brotli n'a pas été mesurée ici, mais comparée à partir de sources publiques. La RFC 7932 indique que Brotli compresse avec un taux de compression nettement plus élevé que le programme gzip et décompresse bien plus vite que les implémentations actuelles de LZMA. Google explique dans le dépôt de Brotli que sa vitesse est proche de celle de deflate, avec une compression plus dense.
En 2015, Cloudflare a testé les deux méthodes sur 10 655 fichiers HTML, CSS et JavaScript. À la qualité maximale, le résultat de Brotli était en moyenne 1,19 fois plus petit que celui de zlib à sa qualité maximale, mais la compression se faisait à 0,5 Mo par seconde, bien plus lentement que les 41,9 Mo de zlib au niveau 9. Brotli au niveau 4 avait un taux de compression proche de zlib au niveau 8 et était un peu plus rapide en moyenne globale, mais 1,48 fois plus lent si l'on ne regarde que les fichiers de moins de 64 Ko.
Nous avons vu comment optimiser un site web en compressant des fichiers comme le HTML, le CSS et le JavaScript. Pour accélérer un site web, la compression des fichiers et Optimisation des images sont deux éléments essentiels.
🔢 FAQ & contenus recommandés
ℹ️ Mention d'affiliation
Le contenu de ce site contient des liens d'affiliation. Lorsqu'un visiteur achète un produit ou un service via l'un de ces liens, le site perçoit une commission du vendeur. Le montant payé par l'acheteur(il baisse lors des promotions ↓), lui, n'augmente pas. Les prix, remises et stocks indiqués correspondent à la date de rédaction et peuvent différer ; vérifiez-les donc auprès du vendeur avant d'acheter. Les produits sont choisis et évalués selon nos propres critères, et les commissions n'influencent ni l'ordre de présentation ni le contenu des évaluations.