Guide de la compression : Gzip, Brotli et Zstd

En bref — La compression réduit vos fichiers texte — HTML, CSS, JavaScript — avant leur transfert sur Internet. Le navigateur télécharge ainsi moins d’octets et la page se charge plus vite, si le transfert constitue réellement le goulot d’étranglement. Les deux formats les plus courants sont Gzip (pris en charge partout) et Brotli (généralement plus compact et préféré par Google). Le gain exact varie selon le fichier : aucun pourcentage ne doit être considéré comme une promesse. Si PageSpeed Insights vous a déjà conseillé d’« activer la compression de texte », voici la correction à appliquer.

Qu’est-ce que la compression ?

Lorsqu’une personne charge votre page, son navigateur doit télécharger tous les fichiers qui la composent. La compression réduit leur taille pendant le transfert, puis le navigateur les décompresse à l’arrivée. La page ne change pas pour l’internaute : elle lui parvient simplement plus vite.

Chaque requête donne lieu à une brève négociation :

1. Le navigateur indique « voici ce que je peux décompresser » en envoyant un en-tête Accept-Encoding qui énumère les algorithmes compris, tels que gzip et br.
2. Le serveur en choisit un, compresse le fichier et renvoie un en-tête Content-Encoding qui précise le format utilisé.
3. Le navigateur décompresse le fichier et affiche la page.

C’est tout. L’opération se fait automatiquement pour chaque fichier, après activation dans la configuration du serveur ou de l’hébergement.

Les deux formats à connaître

• Gzip — la valeur sûre historique. Tous les navigateurs et moteurs de recherche le prennent en charge. C’est le choix de repli fiable.
• Brotli — plus récent, développé chez Google, il produit généralement des fichiers texte un peu plus petits que Gzip. Lorsqu’un navigateur le prend en charge, Google recommande de l’utiliser, tout en conservant Gzip pour les autres clients.

Vous rencontrerez aussi Zstandard (Zstd), une troisième option rapide à décompresser, mais son adoption reste limitée.

Ce que la compression n’est pas

• Ce n’est pas la minification. La minification retire les espaces et commentaires du code ; la compression réencode les octets pour leur transfert. Ces opérations sont distinctes et complémentaires : minifiez d’abord, puis compressez.
• Ce n’est pas la mise en cache. Le cache conserve une copie afin de ne pas renvoyer le fichier. La compression réduit sa taille lorsqu’il est envoyé. Consultez la page sur la mise en cache pour cet autre aspect.

Ce qu’il faut compresser — et ce qu’il faut exclure

Compressez le texte : fichiers HTML, CSS, JavaScript, JSON, SVG et XML, y compris les sitemaps.

Ne recompressez pas les formats déjà compressés : JPG, PNG, GIF, la plupart des vidéos, les polices web WOFF2 et la plupart des PDF. Ils ne rétréciront pas ; une nouvelle compression ne ferait que gaspiller des ressources. Google le soulignait déjà en 2008.

La compression aide-t-elle le SEO ?

Indirectement. La compression n’est pas un facteur de classement en soi. Des fichiers plus petits peuvent toutefois accélérer le chargement, et la vitesse alimente les Core Web Vitals, qui participent à l’évaluation de l’expérience sur la page par Google. Activez donc la compression pour accélérer votre site, pas pour obtenir des points liés au réglage lui-même.

Vous cherchez la version complète — chiffres Gzip contre Brotli, formats exactement pris en charge par Googlebot et preuves correspondantes, seuils de l’audit PageSpeed, niveaux de compression, activation et vérification sur le serveur ? Passez à l’onglet Avancé.

En bref — La compression repose sur la négociation de l’encodage de contenu HTTP : le client envoie Accept-Encoding, éventuellement avec des pondérations q et identity, puis le serveur répond avec Content-Encoding, pour chaque requête et chaque ressource. Une réponse pouvant être mise en cache et variant selon l’encodage doit aussi porter Vary: Accept-Encoding. Brotli compresse généralement mieux que Gzip un même texte — un gain d’environ 15 à 20 % est souvent cité, mais il dépend du contenu, de la version du codec et du niveau. Google le préfère lorsqu’il est pris en charge ; Gzip reste le repli universel. Zstd est un troisième codec enregistré, mais pas universellement pris en charge, et la documentation des robots Google ne confirme pas sa prise en charge par Googlebot. Googlebot accepte gzip, deflate et Brotli (br) : la documentation actuelle l’indique explicitement, Gary Illyes l’a confirmé de manière informelle en 2020, et l’historique remonte au billet de Google de 2008, « Premier rendez-vous avec Googlebot ». La compression n’est pas un facteur de classement et ne garantit à elle seule aucune amélioration du TTFB, du LCP ou de la recherche. Elle réduit le volume transféré, ce qui peut améliorer la chaîne TTFB → LCP si le transfert est réellement limitant. Elle aide aussi les pages à rester sous la limite de récupération de Google, soit 2 Mo de HTML d’après le billet « Dans les coulisses de Googlebot » de 2026 : un gain d’efficacité d’exploration, et pas seulement de vitesse. Décidez quoi compresser selon le type MIME et le résultat mesuré, pas selon une liste uniforme d’extensions. Le risque de type BREACH concerne les réponses mêlant un secret à un contenu contrôlé par un attaquant ; il ne justifie pas de désactiver la compression sur tout le site. Utilisez un niveau élevé pour les ressources statiques ou précompressées, et un niveau faible ou intermédiaire pour le contenu dynamique, après mesure sur votre trafic et votre CPU : aucun niveau n’est optimal partout. Enfin, le protocole Sitemaps autorise explicitement les sitemaps compressés avec gzip.

Ce qu’est réellement la compression

La compression — plus précisément, l’encodage de contenu HTTP — réduit le corps d’une réponse textuelle avant son passage sur le réseau. Le client télécharge moins d’octets, puis les décompresse localement. La négociation se fait à chaque requête. La documentation Lighthouse de Google l’explique ainsi : “When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.” (traduction) « Lorsqu’un navigateur demande une ressource, il utilise l’en-tête de requête HTTP Accept-Encoding pour indiquer les algorithmes de compression qu’il prend en charge. » Un en-tête courant ressemble à Accept-Encoding: gzip, deflate, br. Le serveur choisit un format et signale ce choix dans l’en-tête de réponse Content-Encoding.

Deux limites de vocabulaire méritent d’être précisées à partir de la spécification HTTP (RFC 9110). L’encodage de contenu est une transformation des données de la représentation, donc du corps de la réponse. Il diffère de l’encodage de transfert, appliqué au message pendant son acheminement sur une connexion. La compression abordée ici est un encodage de contenu identifié par Content-Encoding. La négociation n’est pas une simple liste : Accept-Encoding peut contenir des pondérations (q) qui classent les préférences du client et peut aussi refuser un format (q=0) ; identity signifie « aucun encodage appliqué » (RFC 9110, §8.4 et §12.5.3). Si le corps d’une réponse pouvant être mise en cache varie réellement selon le format négocié — par exemple une variante gzip et une variante Brotli pour la même URL — la réponse doit contenir Vary: Accept-Encoding. Le cache évite ainsi de servir une variante qu’un client ne peut pas décoder (RFC 9110, §12.5.5 ; la documentation mod_deflate d’Apache décrit cette exigence Vary pour les variantes compressées en cache).

Cela concerne le texte : HTML, CSS, JavaScript, JSON, SVG et XML, y compris les sitemaps. Gzip et Brotli peuvent réduire fortement ces ressources. Les recommandations PageSpeed de Google citent une limite supérieure : “Enabling gzip compression can reduce the size of the transferred response by up to 90%.” (traduction) « L’activation de la compression gzip peut réduire jusqu’à 90 % la taille de la réponse transférée. » Il s’agit d’un plafond, pas d’une valeur habituelle. Le gain réel dépend de la redondance et de la taille du contenu, de sa minification préalable, du codec, de sa version et de son dictionnaire, ainsi que du niveau de compression. Les chiffres d’un site ne peuvent donc pas être généralisés à un autre.

Deux distinctions supplémentaires sont essentielles :

• Pas la minification. La minification retire des caractères de la source — espaces, commentaires — tandis que la compression réencode les octets obtenus pour le transfert. Elles se cumulent : minifiez, puis compressez. En négliger une laisse des gains de côté.
• Pas la mise en cache. La compression relève de l’encodage, donc de la réduction des octets sur le réseau ; la mise en cache relève du stockage et de la réutilisation (Cache-Control, ETag, CDN). Ces deux leviers améliorent ensemble l’acheminement des octets vers le navigateur. Consultez la mise en cache pour la partie stockage.

Cette page approfondit la compression dans le pôle consacré au chemin critique de rendu, où « compresser le texte » figure dans une liste plus générale sur les octets critiques. C’est ici que ce point est traité en détail.

Gzip, Brotli et Zstd

Taux de compression

Brotli fait généralement mieux sur le texte, mais aucun chiffre précis n’est universel. La documentation Lighthouse de Google indique explicitement que les économies de l’audit sont calculées avec Gzip et que “if Brotli is used, even more savings are possible.” (traduction) « avec Brotli, des économies supplémentaires sont possibles. » Le codelab Brotli de web.dev donne un exemple concret : un fichier main.bundle.js de 225 Ko sans compression passe à environ 61,6 Ko avec Gzip et 53,1 Ko avec Brotli, soit près de 14 % de moins avec Brotli pour ce fichier. Ces valeurs — comme les 15 à 20 % souvent cités ailleurs — indiquent une tendance, pas une garantie. L’écart dépend de la version du codec ou de la bibliothèque, du niveau choisi, de la redondance du contenu et de sa minification préalable. Aucun codec ni niveau de qualité n’est toujours optimal indépendamment du contenu : mesurez vos propres ressources plutôt que de reprendre le pourcentage d’un tiers.

Gzip est le repli universel. Il est pris en charge partout, raison pour laquelle Google le recommande comme filet de sécurité : “Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli.” (traduction) « Utilisez GZIP comme solution de repli pour Brotli. GZIP est pris en charge par tous les principaux navigateurs, mais il est moins efficace que Brotli. »

Zstd est un troisième codec enregistré, mais pas encore une valeur par défaut sûre. Le registre IANA des encodages de contenu HTTP répertorie gzip, br et zstd. Cette inscription ne garantit cependant pas une prise en charge universelle par les clients, robots, serveurs d’origine ou CDN : n’annoncez que les formats demandés par la requête et conservez une voie de repli fonctionnelle. Pour l’interopérabilité HTTP, la RFC 9659 — qui met à jour l’enregistrement zstd de la RFC 8878 — impose aux décodeurs de prendre en charge des fenêtres jusqu’à 8 Mo et interdit aux encodeurs d’exiger une fenêtre plus grande. Cet encodage de contenu HTTP, zstd, est aussi distinct de l’encodage à dictionnaire dcz ; ne les confondez pas dans la documentation des fournisseurs. L’adoption reste précoce — Caddy expose par exemple encode zstd gzip — et la documentation actuelle de Google ne cite que gzip, deflate et Brotli pour ses robots et systèmes de récupération. Elle ne confirme pas Zstandard pour Googlebot. Considérez Zstd comme une option à surveiller et activez-le lorsque votre pile le prend en charge et que la requête le demande, pas encore comme un remplacement de Gzip et Brotli.

Prise en charge par les navigateurs et les robots

Brotli est désormais pratiquement universel dans les navigateurs, mais cela n’a pas toujours été le cas. Cet écart historique explique pourquoi le repli Gzip reste important. La documentation Lighthouse de Google précise : “As of December 2022 Brotli is supported in all major browsers except Safari on iOS.” (traduction) « En décembre 2022, tous les principaux navigateurs prenaient en charge Brotli, à l’exception de Safari sur iOS. » Cette lacune de Safari sur iOS illustre pourquoi il faut conserver Gzip dans la chaîne.

Google recommande Brotli dès que le client peut l’utiliser : “If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms.” (traduction) « Si le navigateur prend en charge Brotli (br), utilisez-le, car il peut réduire davantage la taille des ressources que les autres algorithmes de compression. »

Quand conserver le repli Gzip

Configurez toujours Gzip aux côtés de Brotli. L’encodage de contenu est négocié à chaque requête : un serveur correctement configuré fournit Brotli aux clients qui annoncent br et Gzip aux autres. Il ne s’agit pas de choisir l’un ou l’autre, mais de proposer les deux et de laisser la négociation décider.

Google et Bing prennent-ils en charge Brotli et Gzip ?

La plupart des articles l’affirment sans preuve. Voici une chronologie en trois points, fondée sur les propres déclarations datées de Google.

Le billet de 2008 « Premier rendez-vous avec Googlebot »

Google explique la compression avec ses propres mots depuis 2008. Dans Premier rendez-vous avec Googlebot : en-têtes et compression (Maile Ohye et Jeremy Lilley), Google indiquait que tous les principaux moteurs de recherche et navigateurs prennent en charge gzip pour économiser de la bande passante. Le billet mentionnait aussi x-gzip — équivalent à gzip —, deflate, également accepté par Google, et identity, sans compression. Google y expliquait que de nombreux formats — Flash, JPG, PNG, GIF, PDF — sont déjà compressés et gagnent donc peu à l’être de nouveau. Le texte exprimait même une légère préférence pour gzip plutôt que deflate pour sa robustesse : gzip inclut une somme de contrôle et un en-tête complet, ce qui réduit les ambiguïtés. Le billet est ancien et porte un avertissement d’obsolescence, mais son contenu reste accessible et directement pertinent, alors que presque aucun article récent ne le cite.

La confirmation de Gary Illyes en 2020

La prise en charge de Brotli par Googlebot a été confirmée de manière informelle avant d’apparaître dans la documentation. En août 2020, Gary Illyes, de Google, a déclaré après une réunion avec l’équipe Googlebot qu’on lui avait demandé quelques semaines plus tôt si Googlebot acceptait la compression Brotli — et que c’était bien le cas. Barry Schwartz l’a rapporté le même jour sur Search Engine Roundtable. Cette déclaration précède d’environ quatre ans la documentation actuelle sur les robots. Elle rappelle qu’un représentant peut confirmer un comportement d’exploration bien avant son ajout aux documents officiels.

La documentation officielle actuelle sur les robots

Aujourd’hui, l’information est explicite. La présentation des robots Google indique : “Google’s crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).” (traduction) « Les robots d’exploration et systèmes de récupération de Google prennent en charge les encodages de contenu suivants : gzip, deflate et Brotli (br). » Elle décrit aussi la négociation par requête comme pour un navigateur : “The content encodings supported by each Google user agent is advertised in the Accept-Encoding header of each request they make. For example, Accept-Encoding: gzip, deflate, br.” (traduction) « Les encodages de contenu pris en charge par chaque agent utilisateur Google sont annoncés dans l’en-tête Accept-Encoding de chacune de ses requêtes. Par exemple : Accept-Encoding: gzip, deflate, br. » Mon guide Googlebot chez Ahrefs possède également une section sur l’encodage de contenu : “Googlebot supports gzip, deflate, and Brotli (br).” (traduction) « Googlebot prend en charge gzip, deflate et Brotli (br). »

La chronologie est donc nette : billet de 2008 → confirmation d’Illyes en 2020 → documentation actuelle sur les robots. Le fait est établi, pas spéculatif.

La lacune documentaire de Bing

Bing constitue ici l’astérisque honnête. Aucun document public détaillé ne précise les encodages de contenu négociés par Bingbot lors de l’exploration de HTML ordinaire ; il n’existe pas d’équivalent à la présentation des robots Google. La documentation de Bing est plus étroite : son API Content Submission accepte Gzip et il est possible de lui soumettre des sitemaps compressés avec gzip (.xml.gz). La compression HTTP étant un mécanisme standard négocié par presque tous les clients modernes avec Accept-Encoding, il est raisonnable de supposer que Bingbot accepte au moins Gzip. Traitez toutefois cela comme une déduction fondée sur HTTP, pas comme une déclaration documentée de Bing. Il s’agit d’une véritable différence de transparence documentaire entre les deux moteurs, sans préjuger du comportement réel de Bingbot.

Pourquoi la compression compte pour les performances et les Core Web Vitals

La chaîne causale, formulée précisément

La compression n’est pas un facteur de classement direct. Le mécanisme est le suivant : un transfert plus petit peut raccourcir le téléchargement, améliorer le Time to First Byte, puis le Largest Contentful Paint, qui alimente les Core Web Vitals, signal lié à l’expérience sur la page. Le mot « peut » est essentiel : les recommandations de Google garantissent seulement moins d’octets sur le réseau, pas une amélioration assurée du TTFB, du LCP, des Core Web Vitals ou de la recherche. Si le goulot se trouve ailleurs — requête de base de données lente, script bloquant le rendu, DNS ou établissement de la connexion — compresser une petite réponse ne changera presque rien. Mesurez votre propre goulot et les résultats terrain au lieu de supposer que la compression résout seule la vitesse. Le résultat de vitesse est évalué, pas le réglage de compression. Cette distinction évite de confondre « aide le SEO » et « facteur de classement ». Voir Time to First Byte, Largest Contentful Paint et Core Web Vitals.

Martin Splitt, de Google, propose un cadrage utile : le poids brut d’une page est trompeur. Ce qui compte est ce qui traverse réellement le réseau après compression, et non la taille non compressée sur le disque ; une page de 10 Mo sans compression peut n’en transférer que cinq ou six. Ce propos de Splitt est relayé par Search Engine Journal et non par une transcription primaire ; il est donc paraphrasé ici, pas cité.

Compression et efficacité d’exploration : l’angle sous-estimé

La compression ne sert pas seulement la vitesse pour les humains. Elle aide aussi à rester sous la limite de récupération de Google. Depuis la mise à jour « Dans les coulisses de Googlebot » de 2026, signée Gary Illyes, Googlebot récupère environ 2 Mo de HTML par URL, contre 15 Mo auparavant. Le contenu dépassant la limite est tronqué, pas rejeté : seule la partie téléchargée est transmise pour indexation. Compresser le HTML contribue à maintenir le contenu essentiel dans ce budget. C’est donc aussi un enjeu d’efficacité d’exploration, pas uniquement de Core Web Vitals. La page sur l’exploration détaille cette limite.

Audit Lighthouse « Enable text compression » : les seuils exacts

L’audit “Enable text compression” de PageSpeed Insights et Lighthouse applique des règles précises. Lighthouse collecte les réponses textuelles dépourvues d’un content-encoding br, gzip ou deflate, puis les compresse avec Gzip pour estimer le gain. Selon Google : “If the original size of a response is less than 1.4KiB, or if the potential compression savings is less than 10% of the original size, then Lighthouse does not flag that response in the results.” (traduction) « Si la taille initiale d’une réponse est inférieure à 1,4 Kio, ou si le gain potentiel de compression est inférieur à 10 % de la taille initiale, Lighthouse ne signale pas cette réponse dans les résultats. » Les petits fichiers sous environ 1,4 Kio ne déclenchent donc pas l’avertissement même sans compression. Depuis Lighthouse 13, cet audit est intégré à l’indication plus large « Document request latency », mais la recommandation sous-jacente reste identique.

Pourquoi un site bien configuré peut quand même échouer à l’audit

La documentation PageSpeed de Google fournit une piste de diagnostic utile : “Proxy servers and anti-virus software can disable compression when files are downloaded to a client machine.” (traduction) « Les serveurs proxy et les logiciels antivirus peuvent désactiver la compression lorsque des fichiers sont téléchargés sur une machine cliente. » Un outil peut donc produire un faux négatif — « la compression n’est pas activée » — alors que le serveur est correctement configuré, parce qu’un intermédiaire a retiré l’en-tête Content-Encoding pendant le transfert. Avant d’accuser le rapport ou le serveur, testez depuis un chemin réseau propre.

Compression statique ou dynamique : compromis de mise en œuvre

Niveaux de compression

Les deux algorithmes proposent des niveaux qui arbitrent temps CPU et taux de compression :

• Gzip : niveaux 1 à 9.
• Brotli : niveaux 0 — aucune compression — à 11 — maximum — selon le codelab web.dev de Google.

Les niveaux élevés réduisent davantage la taille, mais consomment plus de temps CPU.

Le coût CPU et l’importance du caractère statique ou dynamique

La compression n’est pas gratuite : elle consomme du CPU. Son profil de coût diffère totalement entre les ressources préparées à l’avance et le contenu généré à la volée. Aucun nombre universel ne convient dans les deux cas. Le bon réglage dépend de la fréquence de modification du contenu, du traitement de la variante compressée par le cache ou le CDN, du trafic et de vos mesures, pas d’une règle empirique copiée dans un article.

• Ressources statiques — précompressées à la compilation : un contenu suffisamment stable pour être compressé une fois à l’avance peut supporter des niveaux élevés. Les documentations gzip_static de nginx et mod_deflate d’Apache décrivent toutes deux la sélection d’un fichier précompressé plutôt que sa recompression à chaque requête. Le coût CPU est payé une fois à la compilation. Comme l’explique le codelab web.dev, la latence des niveaux élevés n’est alors plus un problème ; le compromis devient un temps de compilation plus long, payé une seule fois.
• Réponses dynamiques — générées à chaque requête : les niveaux maximaux ajoutent de la latence à chaque réponse. Un niveau faible ou intermédiaire constitue donc un point de départ fréquent ; certains outils proposent environ 4 pour Brotli afin d’équilibrer taux et vitesse. Il faut toutefois le mesurer selon votre marge CPU et votre trafic, pas en faire une règle fixe. Google relevait déjà ce coût en 2008 : gzip et deflate consomment du CPU et méritent réflexion sur un serveur très chargé qui produit du contenu dynamique, avant d’activer la compression maximale partout.

Le point de départ pratique est donc élevé pour le statique, faible ou intermédiaire pour le dynamique. Confirmez-le selon la mutabilité, le cache ou CDN, le trafic et une mesure avant/après, pas selon un niveau repris d’un article — y compris celui-ci.

Comment activer la compression

Le principe est identique partout : configurez le serveur — ou le CDN ou la périphérie — pour compresser les réponses textuelles et proposer Brotli avec Gzip comme repli. Selon la plateforme :

• Apache — module mod_deflate, et mod_brotli pour Brotli. Les recommandations PageSpeed de Google y renvoient directement.
• Nginx — module intégré ngx_http_gzip_module avec gzip on; et gzip_types, plus le module Brotli pour br.
• IIS — compression HTTP intégrée, statique et dynamique.
• CDN ou périphérie — Cloudflare, Fastly et services similaires proposent généralement Brotli et Gzip par un réglage ; Caddy expose encode zstd gzip.
• Frameworks applicatifs — middleware compression de Node ou Express ; Next.js, Vercel et la plupart des hébergeurs modernes compressent par défaut.

Vérifiez ensuite la configuration — l’onglet Listes de contrôle donne les commandes exactes. Le test le plus rapide est curl -I -H "Accept-Encoding: br, gzip" https://example.com/ : recherchez un en-tête content-encoding dans la réponse.

Ce qu’il ne faut PAS compresser

Ne recompressez pas les formats déjà compressés : JPG, PNG, GIF, la plupart des vidéos, les polices WOFF2 et la plupart des PDF. Leur compression interne est déjà faite ; leur appliquer Gzip ou Brotli consomme du CPU pour un gain négligeable, parfois négatif. Cette liste donne des exemples, pas une règle exhaustive. Le guide de diagnostic de GTmetrix indique lui aussi que les formats déjà compressés ou à forte entropie peuvent ne pas gagner et même grossir. La règle plus sûre consiste à limiter la compression par type MIME aux formats textuels et, si possible, à vérifier la sortie mesurée d’une réponse plutôt que de faire confiance à une liste générale d’extensions.

Il n’existe pas non plus de taille minimale universelle en dessous de laquelle la compression « ne compte pas ». Le cadrage et les métadonnées peuvent annuler le gain sur un corps petit ou déjà dense, mais le seuil de rentabilité dépend du codec, de l’implémentation, des en-têtes et du contenu. Les seuils de 1,4 Kio et 10 % de Lighthouse sont les règles de suppression de cet audit précis, pas un plancher général. Un CDN peut publier un minimum différent pour décider de compresser une réponse.

Compression et BREACH : un risque circonscrit, pas une raison de tout désactiver

Certains conseils de sécurité recommandent de désactiver la compression par prudence. Ne généralisez pas. Un risque de type BREACH n’est pas une propriété abstraite de toute compression. La recherche originale décrit une forme d’attaque précise : une réponse HTTP (1) compressée, qui (2) mêle un secret, tel qu’un jeton CSRF, à (3) un contenu influencé par l’attaquant et reflété dans la même réponse, tandis que (4) l’attaquant peut observer la longueur compressée sur des requêtes répétées afin de déduire le secret octet par octet. La documentation mod_deflate d’Apache signale exactement cette combinaison pour un examen spécifique à BREACH. Si une réponse ne mêle pas de secret à une entrée contrôlée par un attaquant et reflétée dans un corps compressé, l’attaque classique ne s’applique pas. La bonne réponse consiste à examiner et atténuer le contexte vulnérable — ne pas refléter l’entrée près d’un secret, ajouter des jetons par requête ou limiter le débit — et non à désactiver la compression textuelle sur tout le site.

Le mythe du sitemap : la compression est explicitement autorisée

Une correction mérite d’être affirmée clairement : le protocole Sitemaps autorise explicitement les sitemaps compressés avec gzip. Certains pensent qu’un sitemap ne peut ou ne doit pas être compressé ; c’est faux. Le protocole sitemaps.org accepte les fichiers .xml.gz afin de réduire la bande passante. Les deux moteurs les acceptent, et les outils de soumission de Bing prennent aussi en charge gzip. La seule réserve est habituelle : le sitemap non compressé doit respecter les limites du protocole, soit 50 000 URL et 50 Mo. Compresser le transfert convient et est recommandé pour les grands sitemaps.

La place de la compression dans les performances web

La compression est un levier parmi les sujets voisins. Elle réduit les octets critiques à télécharger par le chemin critique de rendu, diminue le TTFB et le LCP en aval ; elle fait l’objet d’un audit nommé dans PageSpeed Insights et Lighthouse. Elle complète la mise en cache — encodage contre stockage — et les ressources bloquant le rendu — des fichiers bloquants plus petits accélèrent l’affichage. Pour l’ensemble des outils, consultez les outils de performance web.

Résumé par l’IA

Voici une synthèse de la version Avancé :

• Compression = encodage de contenu HTTP, distinct de l’encodage de transfert HTTP (RFC 9110, §8.4). Elle réduit les réponses textuelles — HTML, CSS, JS, JSON, SVG et sitemaps XML — avant leur passage sur le réseau. La négociation se fait par requête : le client envoie Accept-Encoding, qui peut porter des pondérations q et identity, puis le serveur répond par Content-Encoding. Une réponse mise en cache et variant selon l’encodage doit inclure Vary: Accept-Encoding (§12.5.5).
• Trois codecs : Gzip, repli universel ; Brotli, généralement plus compact sur le texte — un gain de 15 à 20 % est souvent cité mais varie avec le contenu, la version et le niveau — et préféré par Google lorsqu’il est pris en charge ; Zstd, enregistré par l’IANA et défini par la RFC 9659, mais pas universel. La documentation des robots Google ne confirme pas Zstd pour Googlebot. Servez Brotli avec Gzip en repli.
• Googlebot accepte gzip, deflate et Brotli (br) : la documentation actuelle le dit explicitement, Gary Illyes l’a confirmé de façon informelle en 2020, et Google l’explique depuis son billet de 2008 « Premier rendez-vous avec Googlebot ». Bing ne publie pas de document équivalent sur la compression de son robot ; déduisez Gzip des standards HTTP, tout en signalant cette lacune.
• Ce n’est ni un facteur de classement ni une garantie de vitesse. Un transfert plus petit peut améliorer TTFB → LCP → Core Web Vitals, uniquement s’il est le vrai goulot. Google garantit moins d’octets sur le réseau, pas un meilleur résultat Core Web Vitals ou dans la recherche. La compression aide aussi le HTML à rester sous la limite de récupération d’environ 2 Mo de Googlebot, d’après « Dans les coulisses de Googlebot » en 2026 : ce qui dépasse est tronqué, pas rejeté.
• L’audit Lighthouse « Enable text compression » vise les réponses textuelles sans encodage br, gzip ou deflate, mais ignore les fichiers sous environ 1,4 Kio ou dont le gain est inférieur à 10 %. C’est son seuil propre, pas un minimum universel. Un proxy ou antivirus peut retirer Content-Encoding et produire un faux négatif.
• Niveaux et compromis : Gzip 1 à 9, Brotli 0 à 11. Utilisez un niveau élevé pour les ressources statiques ou précompressées, payé à la compilation, et faible ou intermédiaire pour le dynamique, qui consomme CPU et latence à chaque requête. Mesurez sur votre trafic : aucun niveau n’est toujours optimal.
• N’excluez pas aveuglément par extension. Décidez selon le type MIME et le résultat mesuré. Les formats déjà compressés — images, vidéo, WOFF2 et la plupart des PDF — gagnent rarement à l’être de nouveau.
• Le risque BREACH est circonscrit. Il exige une réponse compressée mêlant un secret à du contenu reflété contrôlé par un attaquant, avec observation répétée de la longueur. Corrigez cette réponse et ce contexte, sans désactiver la compression partout.
• Validez chaque représentation encodée : Vary: Accept-Encoding pour les variantes en cache, absence de double compression entre proxy, CDN et origine, et gestion de ETag, Content-Length et des plages propre à la variante identity, gzip ou br.
• Mythe du sitemap réfuté : le protocole Sitemaps autorise explicitement les fichiers gzip (.xml.gz) ; les limites s’appliquent toujours à leur taille non compressée.

Documentation officielle

Sources primaires sur la compression et l’encodage de contenu.

Google

• Activer la compression du texte — Lighthouse — seuils de déclenchement, négociation Accept-Encoding et recommandation « Brotli préféré, Gzip en repli ».
• Minifier et compresser les charges réseau avec Brotli — codelab web.dev — niveaux Brotli 0 à 11, compromis statique/dynamique et exemple avant/après.
• Activer la compression — PageSpeed Insights — plafond de 90 %, modules serveur et réserve sur les faux négatifs dus aux proxy ou antivirus.
• Présentation des robots Google — déclaration de référence « gzip, deflate et Brotli (br) » et annonce via Accept-Encoding.
• Premier rendez-vous avec Googlebot : en-têtes et compression — 2008 — explication originale de gzip, deflate et des formats qui ne gagnent pas à être recompressés.

Standards et protocoles

• RFC 9110 — HTTP Semantics — définit l’encodage de contenu comme transformation des données de représentation (§8.4), le distingue de l’encodage de transfert, décrit les pondérations q et identity dans Accept-Encoding (§12.5.3), ainsi que Vary pour les variantes en cache (§12.5.5).
• RFC 9659 — Zstandard (zstd) as an HTTP Content Coding — met à jour la RFC 8878, fixe la fenêtre interopérable de 8 Mo pour zstd et le distingue du codage à dictionnaire dcz.
• Registre IANA des encodages de contenu HTTP — liste officielle des jetons enregistrés, dont gzip, br et zstd ; l’enregistrement ne garantit pas une prise en charge universelle.
• Documentation Apache mod_deflate — Vary: Accept-Encoding, prévention de la double compression, DeflateAlterETag et note de sécurité BREACH.
• Cloudflare — content compression — transformations origine/périphérie, taille minimale et sélection du codec.
• nginx ngx_http_gzip_static_module — service de fichiers statiques précompressés.
• Protocole Sitemaps — autorise les sitemaps gzip et précise les limites non compressées.

Sécurité

• Attaque BREACH — recherche originale — conditions réelles : une réponse compressée mêlant secret et contenu reflété influencé par l’attaquant, dont la longueur est observée à répétition.

Bing et Microsoft

• Aucun document Bing dédié ne précise les encodages de contenu acceptés par Bingbot pour l’exploration HTML. L’aide de Bing confirme les sitemaps gzip et Gzip pour l’API Content Submission : aide Bing Webmaster Tools. Considérez la prise en charge côté robot comme une déduction des standards HTTP, pas une déclaration documentée.

Citations des sources

Déclarations officielles de Google. Chaque lien doté d’un fragment #:~:text= mène au passage cité sur la page source.

Google — Lighthouse « Enable text compression »

• “When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.” (traduction) « Lorsqu’un navigateur demande une ressource, il utilise l’en-tête de requête HTTP Accept-Encoding pour indiquer les algorithmes de compression qu’il prend en charge. » Accéder à la citation
• “If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms.” (traduction) « Si le navigateur prend en charge Brotli (br), utilisez-le, car il peut réduire davantage la taille des ressources que les autres algorithmes de compression. » Accéder à la citation
• “The potential savings that Lighthouse lists are the potential savings when the response is encoded with GZIP. If Brotli is used, even more savings are possible.” (traduction) « Les économies potentielles indiquées par Lighthouse correspondent à un encodage GZIP de la réponse. Avec Brotli, des économies supplémentaires sont possibles. » Accéder à la citation
• “If the original size of a response is less than 1.4KiB, or if the potential compression savings is less than 10% of the original size, then Lighthouse does not flag that response in the results.” (traduction) « Si la taille initiale d’une réponse est inférieure à 1,4 Kio, ou si le gain potentiel est inférieur à 10 % de la taille initiale, Lighthouse ne la signale pas. » Accéder à la citation
• “As of December 2022 Brotli is supported in all major browsers except Safari on iOS.” (traduction) « En décembre 2022, tous les principaux navigateurs prenaient en charge Brotli, à l’exception de Safari sur iOS. » … “Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli.” (traduction) « Utilisez GZIP comme repli pour Brotli. GZIP est pris en charge par tous les principaux navigateurs, mais reste moins efficace que Brotli. » Accéder à la citation

Google — PageSpeed Insights « Enable Compression »

• “Enabling gzip compression can reduce the size of the transferred response by up to 90%.” (traduction) « L’activation de la compression gzip peut réduire jusqu’à 90 % la taille de la réponse transférée. » Accéder à la citation
• “Proxy servers and anti-virus software can disable compression when files are downloaded to a client machine.” (traduction) « Les serveurs proxy et les logiciels antivirus peuvent désactiver la compression lors du téléchargement de fichiers sur une machine cliente. » Accéder à la citation

Google — présentation des robots

• “Google’s crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).” (traduction) « Les robots d’exploration et systèmes de récupération de Google prennent en charge gzip, deflate et Brotli (br). » Accéder à la citation
• “The content encodings supported by each Google user agent is advertised in the Accept-Encoding header of each request they make. For example, Accept-Encoding: gzip, deflate, br.” (traduction) « Les encodages pris en charge par chaque agent utilisateur Google sont annoncés dans l’en-tête Accept-Encoding de chacune de ses requêtes. Par exemple : Accept-Encoding: gzip, deflate, br. » Accéder à la citation

Gary Illyes, Google — confirmation de Brotli en 2020

• Après une réunion avec l’équipe Googlebot, Illyes a confirmé que Googlebot prend en charge la compression Brotli. Il l’a publié sur X en août 2020, et Barry Schwartz l’a rapporté le même jour. Cette phrase paraphrase le compte rendu et n’est pas reproduite comme citation textuelle. Lire l’article

Quelle configuration de compression choisir ?

Partez de ce que vous servez et de l’endroit où vous le servez, pas de la question « Gzip ou Brotli ? » : en pratique, vous proposez presque toujours les deux.

Q1. Votre serveur ou CDN peut-il proposer Brotli avec Gzip en repli ?

• Oui — module Nginx ou Apache moderne, ou option CDN — → activez Brotli + Gzip. La négociation choisit Brotli pour les clients qui annoncent br et Gzip pour les autres. C’est la réponse par défaut. Passez à Q2.
• Non — pile ancienne ou module Brotli indisponible — → activez Gzip seul pour l’instant. Il fonctionne partout et capte l’essentiel du gain. Ajoutez Brotli dès que votre pile le permet.

Q2. La ressource est-elle statique — produite à l’avance — ou générée par requête ?

• Statique — bundles CSS/JS, HTML préconstruit, sitemaps — → précompressez à un niveau élevé, jusqu’à Gzip 9 ou Brotli 11, après mesure sur vos ressources. Le coût CPU est payé une fois ; chaque requête reçoit le petit fichier.
• Dynamique — HTML produit par une application ou un CMS à chaque requête — → compressez à un niveau faible ou intermédiaire. Brotli autour de 4 est un point de départ fréquent à mesurer. Les niveaux maximaux ajoutent de la latence à chaque réponse ; le bon choix dépend du trafic et de la marge CPU.

Q3. Le fichier est-il déjà un binaire compressé ? (JPG, PNG, GIF, vidéo, WOFF2, la plupart des PDF)

• Oui → ne le recompressez pas. Il ne rétrécira pas, gaspillera du CPU et peut même grossir légèrement. Limitez les règles de compression aux types MIME textuels.
• Non — HTML, CSS, JS, JSON, SVG, XML — → compressez-le.

Q4. PageSpeed affiche encore « Enable text compression » après l’activation.

• Le fichier signalé fait-il moins d’environ 1,4 Kio ou économiserait-il moins de 10 % ? → Lighthouse ne les signale de toute façon pas. S’il n’est pas signalé, rien n’est à corriger.
• La commande curl -I -H "Accept-Encoding: br, gzip" renvoie-t-elle un en-tête content-encoding ? → le serveur fonctionne ; un proxy ou antivirus sur le chemin de test a probablement retiré l’en-tête. Recommencez depuis un réseau propre.
• Aucun en-tête content-encoding ? → le serveur ne compresse réellement pas cette réponse. Vérifiez le périmètre des types MIME et la configuration du module.

Liste de contrôle : configuration et vérification de la compression

Contrôlez que le texte est compressé, que Brotli est préféré et qu’aucune ressource n’est compressée deux fois :

• Brotli activé avec Gzip en repli — le serveur annonce br et sert Gzip aux clients qui ne le prennent pas en charge.
• Compression limitée aux types MIME textuels — HTML, CSS, JS, JSON, SVG, XML. Les formats déjà compressés — images, vidéo, WOFF2, la plupart des PDF — sont exclus.
• Ressources statiques précompressées à un niveau élevé — jusqu’à Gzip 9 ou Brotli 11 — pendant la compilation, selon des mesures et non un billet de blog.
• Réponses dynamiques compressées à un niveau faible ou intermédiaire pour équilibrer CPU et latence, puis confirmées sur votre trafic.
• Vary: Accept-Encoding présent sur les réponses mises en cache qui varient selon l’encodage, afin qu’un cache partagé ne serve pas la mauvaise variante.
• Aucune double compression entre proxy, CDN et origine ; Content-Length correspond au corps encodé réellement envoyé à chaque étape.
• Vérification en ligne de commande : curl -I -H "Accept-Encoding: br, gzip" https://example.com/ renvoie un en-tête content-encoding: br ou gzip.
• Vérification dans DevTools — l’onglet Network montre une taille transférée nettement inférieure à la taille de la ressource pour les réponses textuelles.
• PageSpeed Insights ou Lighthouse — aucun avertissement « Enable text compression » sur les réponses textuelles de plus d’environ 1,4 Kio.
• Faux négatif exclu — si un outil affirme que la compression est désactivée alors que curl montre content-encoding, suspectez un proxy ou antivirus qui retire l’en-tête, pas nécessairement le serveur.
• Sitemaps — grands sitemaps servis en gzip (.xml.gz), le fichier non compressé restant sous 50 000 URL et 50 Mo.
• Minification également effectuée — compression et minification se cumulent ; utilisez les deux, pas l’une à la place de l’autre.

Aide-mémoire sur la compression

Les trois codecs

Niveaux de compression

À compresser ou à exclure

Repères rapides

• Googlebot accepte gzip, deflate et Brotli (br), négociés via Accept-Encoding ; Zstd n’est pas confirmé.
• Google cite pour Gzip un plafond d’économie jusqu’à environ 90 %. C’est un maximum, pas une valeur habituelle ; le gain varie selon le contenu et le codec.
• Lighthouse ignore les fichiers de moins d’environ 1,4 Kio ou dont le gain potentiel est inférieur à 10 %. C’est sa propre règle de suppression, pas une taille minimale universelle.
• La compression aide le HTML à rester sous la limite de récupération d’environ 2 Mo de Googlebot en 2026. C’est un gain d’efficacité d’exploration ; au-delà, le contenu est tronqué, pas rejeté.
• Une réponse mise en cache qui varie selon l’encodage doit porter Vary: Accept-Encoding, sinon un cache partagé peut servir une variante indécodable.
• Le risque BREACH concerne seulement les réponses mêlant secret et contenu reflété contrôlé par un attaquant ; il ne justifie pas de tout désactiver.
• Le protocole Sitemaps autorise gzip (.xml.gz) : l’idée inverse est un mythe.
• Vérification : curl -I -H "Accept-Encoding: br, gzip" <url>, puis contrôlez content-encoding et vary.

Mythes et erreurs sur la compression

Voici les confusions récurrentes à abandonner :

• « Activer la compression améliorera mon classement. » Aucune source officielle ni aucun représentant ne décrit la compression comme un signal de classement. Elle contribue à la vitesse et aux Core Web Vitals, à proximité de l’expérience sur la page, mais n’est pas un facteur évalué en soi. Activez-la pour la vitesse et décrivez-la honnêtement.
• « Google ne prend pas en charge Brotli, donc il faut rester sur Gzip. » C’est obsolète. L’infrastructure d’exploration de Google accepte Brotli depuis au moins 2020, selon Illyes, et la documentation actuelle l’indique explicitement.
• « Compresser mes images, polices et vidéos accélérera le site. » C’est contre- productif. JPG, PNG, GIF, la plupart des vidéos et les polices WOFF2 sont déjà compressés. Une nouvelle compression gaspille du CPU, apporte peu ou rien et peut parfois agrandir le fichier. Limitez-la au texte.
• « PageSpeed dit que la compression est désactivée alors que je l’ai activée : le rapport est cassé. » Pas forcément. Selon Google, un proxy ou antivirus peut retirer Content-Encoding avant la mesure et produire un faux négatif. Testez avec curl sur un chemin propre avant d’accuser l’outil ou le serveur.
• « Compression et minification sont identiques. » Ce sont deux étapes : la minification retire des caractères source, la compression réencode les octets pour le transfert. Elles se cumulent ; utilisez les deux.
• « Le niveau maximal est toujours optimal. » C’est excessif pour le dynamique. Gzip 9 et Brotli 11 coûtent du CPU à chaque requête. Réservez-les aux ressources statiques ou précompressées et utilisez un niveau intermédiaire à la volée.
• « Un sitemap ne peut ou ne doit pas être compressé avec gzip. » Faux : le protocole Sitemaps autorise explicitement .xml.gz. Le fichier non compressé doit simplement rester sous 50 000 URL et 50 Mo.

Vérifier la négociation de compression en ligne de commande

Exécutez cette commande sous macOS ou Linux. --compressed annonce les encodages pris en charge et décompresse le corps pour l’affichage ; les en-têtes indiquent toujours ce qui a réellement traversé le réseau.

curl -sS --compressed -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: br' -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: gzip' -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: identity' -D - -o /dev/null https://example.com/app.js

Pour une ressource pouvant être mise en cache, la réponse doit inclure un Content-Encoding approprié et Vary: Accept-Encoding. Vérifiez explicitement ce dernier derrière un cache partagé ou un CDN : son absence permet au cache de servir la variante encodée d’un client à un autre qui ne peut pas la décoder.

Sous Windows PowerShell, demandez chaque encodage et inspectez les en-têtes :

$headers = @{ "Accept-Encoding" = "br, gzip" }
$r = Invoke-WebRequest -Uri "https://example.com/app.js" -Headers $headers
$r.Headers | Select-Object Content-Encoding, Vary, Content-Length

Repérer dans DevTools les ressources textuelles non compressées de même origine

Collez ce code dans la console Chrome DevTools après le chargement de la page. Il utilise les tailles de Resource Timing pour établir une liste courte. Confirmez chaque réponse dans l’onglet Network, car les entrées en cache ou interorigines peuvent omettre ces tailles.

performance.getEntriesByType('resource')
  .filter((r) => r.transferSize > 0 && r.encodedBodySize === r.decodedBodySize)
  .map((r) => ({ url: r.name, bytes: r.transferSize }));

Extraire les en-têtes de compression dans un robot

Utilisez cet XPath dans un processus d’extraction personnalisé capable de consulter les en-têtes de réponse. Il ne repère le marqueur HTML que si le robot a stocké les en-têtes séparément. Dans un document HTML ordinaire, la compression est un en-tête HTTP absent du DOM. Cette distinction évite un faux test fréquent : XPath seul ne peut pas prouver l’encodage du transfert.

Outils pour tester la compression HTTP

• Panneau Network de Chrome DevTools — inspectez Content-Encoding, la taille transférée, le type de ressource et les modifications apportées par le CDN ou le cache.
• curl --compressed — testez la négociation réelle et comparez Brotli, Gzip et identity sans dépendre de l’interface d’un navigateur.
• PageSpeed Insights ou Lighthouse — repérez les ressources textuelles dont le gain suffit à déclencher l’audit « Enable text compression » décrit plus haut.
• WebPageTest — comparez tailles transférées et cascades de requêtes avec un lieu, un navigateur et un profil réseau constants.
• Configuration et journaux du CDN ou serveur — confirmez le codec et le niveau choisis pour les ressources statiques et dynamiques.

Prouver que la compression est correctement configurée

Test de négociation de l’encodage

Test : demandez séparément une ressource textuelle avec Accept-Encoding: br, gzip et identity. Résultat attendu : les requêtes prises en charge reçoivent le Content-Encoding correspondant ; identity reste décodable et les variantes incluent un Vary approprié. Interprétation d’un échec : la négociation, la variation du cache ou la configuration origine/CDN est incorrecte. Fenêtre de surveillance : immédiatement après propagation. Déclencheur de retour arrière : corps corrompu ou variante servie avec le mauvais encodage.

Test du périmètre des ressources

Test : échantillonnez HTML, CSS, JS, JSON, SVG et XML, ainsi que des images, vidéos et polices déjà compressées dans Network. Résultat attendu : les formats textuels sont compressés, les autres ne le sont pas de nouveau. Interprétation d’un échec : la liste autorisée de types MIME est incomplète ou trop large. Fenêtre de surveillance : immédiate. Déclencheur de retour arrière : taille transférée accrue, CPU d’origine excessif ou ressource cassée.

Test de régression des performances

Test : comparez des exécutions reproductibles de WebPageTest ou Lighthouse et le CPU serveur avant et après l’activation de la compression dynamique. Résultat attendu : les octets textuels transférés diminuent sans régression persistante du TTFB ni des erreurs. Interprétation d’un échec : le codec ou niveau coûte trop de CPU, ou la compression s’effectue à la mauvaise couche. Fenêtre de surveillance : laboratoire immédiatement, puis production sous charge représentative. Déclencheur de retour arrière : latence durable, saturation CPU ou hausse des erreurs.

Test des variantes de cache (Vary)

Test : pour une réponse mise en cache et servie avec différents encodages, demandez-la avec Accept-Encoding: br, puis gzip, puis identity, sur le même chemin de cache ou CDN. Résultat attendu : chaque variante correspond à la requête et la réponse porte Vary: Accept-Encoding, de sorte que la clé de cache inclut l’encodage négocié (RFC 9110, §12.5.5). Interprétation d’un échec : un cache partagé conserve une variante encodée et la sert à un client incapable de la décoder — cas classique d’un client qui n’a pas annoncé br mais reçoit un corps Brotli. Fenêtre de surveillance : immédiatement après toute modification du cache ou CDN. Déclencheur de retour arrière : un client reçoit un corps non annoncé ou le taux de succès du cache s’effondre à cause d’une clé trop large.

Test de double transformation et de métadonnées obsolètes

Test : suivez une réponse à travers chaque proxy, CDN et origine — en comparant par exemple les en-têtes à l’origine et en périphérie — afin de confirmer qu’elle n’est compressée qu’une fois. Résultat attendu : le Content-Encoding final nomme un seul encodage et Content-Length correspond au corps réellement envoyé, sans ancienne longueur de la version identity. Interprétation d’un échec : un intermédiaire a décompressé puis recompressé la réponse, ou compressé un corps déjà compressé, sans mettre à jour les métadonnées de longueur ou d’intégrité. Les documentations mod_deflate d’Apache et de Cloudflare signalent ce scénario. Fenêtre de surveillance : après toute modification d’un CDN, proxy inverse ou règle de transformation en périphérie. Déclencheur de retour arrière : téléchargement corrompu, Content-Length incohérent ou corps visiblement compressé deux fois.

Test des validateurs et des requêtes par plages

Test : demandez la même ressource avec identity, gzip et br, puis comparez ETag, Content-Length et le comportement d’une requête Range. Résultat attendu : chaque représentation encodée est distincte, avec son propre ETag — ou une politique partagée explicitement documentée —, la longueur correcte et des plages appliquées à la représentation sélectionnée. Interprétation d’un échec : les validateurs ou le contenu partiel supposent une représentation canonique unique, ce qui brise les requêtes conditionnelles ou les téléchargements par plages. Fenêtre de surveillance : immédiatement, puis après chaque changement de compression ou de cache CDN. Déclencheur de retour arrière : une requête If-None-Match ou par plage renvoie un corps erroné ou corrompu pour une variante compressée.

Testez vos connaissances : compression

Cinq questions rapides sur la compression de texte HTTP et les formats acceptés par Google. Choisissez une réponse, puis vérifiez-la.

Journal des modifications