Comment forcer le serveur à envoyer une réponse compressée : guide pas à pas pour économiser du trafic

Un seul en-tête dans une requête HTTP peut réduire de plusieurs fois le volume de données téléchargées. Il s'agit de la négociation de la compression entre le client et le serveur. Si vous travaillez avec un proxy et payez pour chaque gigaoctet de trafic, ce sujet affecte directement votre facture. Dans ce guide, nous verrons comment forcer le serveur à envoyer une réponse compressée, comment mesurer les économies réelles sur votre tâche et quels pièges vous attendent.

Introduction : un en-tête peut réduire le trafic de plusieurs fois

La compression HTTP fonctionne de manière étonnamment simple. Le client indique au serveur quels algorithmes de compression il comprend. Le serveur choisit celui qui convient, compresse le corps de la réponse et l'envoie. Le client décompresse les données de son côté. Ainsi, ce qui circule sur le réseau n'est pas le HTML ou le JSON d'origine, mais sa version compressée, qui pèse souvent trois à cinq fois moins.

Ce que vous obtiendrez au final. Après avoir lu ce guide, vous saurez activer la compression côté client, vérifier si le serveur renvoie réellement une réponse compressée, mesurer les économies de trafic en octets avant et après, et diagnostiquer les situations où la compression ne fonctionne pas pour une raison ou une autre. Tout cela est crucial lorsque vous faites passer du trafic par le proxy Proxeon et payez pour les gigaoctets.

À qui s'adresse ce guide. Le contenu s'adresse aux développeurs, aux spécialistes du scraping, aux ingénieurs en automatisation et à tous ceux qui écrivent des clients pour travailler avec HTTP via des proxys. Niveau intermédiaire. Nous ne verrons pas en détail ce qui constitue la consommation de trafic en général. Un article séparé est dédié à ce sujet. Ici, nous nous concentrons strictement sur la compression.

Ce qu'il faut savoir à l'avance. Une compréhension de base de ce qu'est une requête et une réponse HTTP, ce que sont les en-têtes et comment exécuter une commande dans un terminal suffit. Si vous avez déjà fait une requête avec curl ou écrit un script en Python ou Node.js, vous vous en sortirez sans difficulté.

Temps nécessaire. La lecture et la répétition de tous les exemples prendront environ soixante minutes. Vous verrez les premiers résultats pratiques en dix minutes, lorsque vous comparerez la taille des réponses compressées et non compressées de vos propres yeux.

Préparation préalable

Avant de commencer, assurez-vous d'avoir tout ce qu'il faut. Cela vous fera gagner du temps et évitera des erreurs en cours de route.

Outils nécessaires

• curl version 7.72 ou plus récente. Dans les versions de 2026, brotli et zstd sont pris en charge nativement sur la plupart des systèmes.
• Python version 3.10 ou plus récente avec la bibliothèque requests installée, et pour brotli, le paquet brotli ou brotlicffi.
• Node.js version 18 ou plus récente. Le module zlib est intégré et prend en charge gzip, deflate, brotli.
• Accès au proxy Proxeon, si vous voulez mesurer les économies précisément dans les conditions dans lesquelles vous travaillez chaque jour.
• Un éditeur de texte pour écrire des scripts.

Exigences système

N'importe quel système moderne convient : Windows, macOS ou Linux. Tous les exemples sont multiplateformes. Deux gigaoctets de RAM suffisent. Il n'y a aucune exigence particulière pour le processeur, bien que la compression de gros volumes avec brotli au niveau maximal puisse charger visiblement un cœur.

Ce qu'il faut installer et vérifier

1. Ouvrez un terminal et exécutez la commande de vérification de version de curl :

   curl --version

2. Regardez la première ligne de la sortie. Elle indique la version. Assurez-vous que dans la liste des fonctionnalités figurent brotli et si possible zstd.
3. Vérifiez Python avec la commande

   python --version

   et installez les dépendances :

   pip install requests brotli

4. Vérifiez Node.js avec la commande

   node --version

Astuce : Si curl dans votre système est compilé sans brotli, installez-le via le gestionnaire de paquets officiel de votre système d'exploitation. Dans les versions d'entreprise de 2026, brotli est presque toujours activé par défaut.

Copies de sauvegarde. Dans ce guide, nous ne modifions pas la configuration des serveurs de production et ne touchons pas aux données réelles. Nous envoyons seulement des requêtes et mesurons les réponses. Par conséquent, aucune sauvegarde n'est nécessaire. Cependant, si plus tard vous décidez d'activer la compression sur votre propre serveur web, assurez-vous de sauvegarder le fichier de configuration d'origine avant de le modifier.

✅ Vérification : Les trois outils répondent à la commande de vérification de version et affichent le numéro. La préparation est terminée, nous pouvons continuer.

Concepts de base en langage simple

Avant d'appuyer sur les boutons, clarifions les termes. Cela prendra cinq minutes, mais évitera toute confusion par la suite.

Comment fonctionne la négociation de la compression

La compression HTTP repose sur trois en-têtes. Comprendre leur rôle résout la plupart des problèmes.

Accept-Encoding côté client. C'est l'en-tête que votre client envoie avec la requête. Il énumère les algorithmes de compression que le client sait décompresser. Par exemple, la chaîne

Accept-Encoding: gzip, br, zstd

Content-Encoding dans la réponse. C'est l'en-tête que le serveur ajoute à sa réponse. Il indique avec quel algorithme le corps a été compressé. Si vous voyez

Content-Encoding: br

Vary côté serveur. L'en-tête Vary indique aux caches et aux proxys que la réponse dépend de certains en-têtes de la requête. Pour la compression, la valeur

Vary: Accept-Encoding

Idée clé de la négociation

Mémorisez la séquence. Le client demande via Accept-Encoding. Le serveur décide et répond via Content-Encoding. Les intermédiaires s'orientent sur Vary. Si au moins un maillon de cette chaîne est cassé, vous recevrez une réponse non compressée et paierez plus pour le trafic.

Astuce : Même si votre bibliothèque HTTP ajoute Accept-Encoding automatiquement, vérifiez toujours l'en-tête réel de la réponse. L'automatisation peut parfois être silencieuse, mais le trafic part.

gzip, deflate, brotli, zstd : comparaison des algorithmes

Il existe quatre algorithmes de compression courants pour HTTP. Ils diffèrent par le taux de compression et la charge CPU. Examinons chacun et résumons les chiffres dans un tableau.

gzip

Le plus ancien et le plus universel. Pris en charge partout : tout serveur, tout client, tout proxy. Offre un bon taux de compression sur les données textuelles avec une charge modérée. En cas de doute, commencez par gzip.

deflate

Proche parent de gzip, utilise le même algorithme en interne mais avec un emballage différent. En pratique, il est moins courant et parfois implémenté avec des erreurs sur les serveurs. Le taux de compression est similaire à gzip. Il n'y a pas de raison particulière de choisir deflate plutôt que gzip.

brotli

Algorithme moderne, spécialement conçu pour le web. Sur les données textuelles, il compresse nettement mieux que gzip, en particulier sur HTML, CSS et JSON. La contrepartie est une charge CPU plus élevée lors de la compression aux niveaux maximaux. La décompression est rapide. Il est désigné par br dans les en-têtes.

zstd

Algorithme moderne rapide avec une configuration flexible des niveaux. Il offre un taux de compression comparable à brotli, mais fonctionne plus vite en vitesse de compression. Le support dans le web augmente ; d'ici 2026, la plupart des serveurs et clients actuels le comprennent. Il est désigné par zstd.

Tableau comparatif sur une réponse textuelle typique

Prenons une réponse JSON hypothétique de 1000 kilooctets non compressée. Les chiffres sont approximatifs, ils dépendent du contenu, mais l'ordre de grandeur est correct.

• Sans compression : 1000 Ko, économie 0 %, charge CPU minimale.
• gzip niveau 6 : environ 190 Ko, économie d'environ 81 %, charge faible.
• deflate niveau 6 : environ 195 Ko, économie d'environ 80 %, charge faible.
• brotli niveau 5 : environ 165 Ko, économie d'environ 83 %, charge moyenne.
• brotli niveau 11 : environ 140 Ko, économie d'environ 86 %, charge élevée.
• zstd niveau 3 : environ 175 Ko, économie d'environ 82 %, charge faible.
• zstd niveau 19 : environ 150 Ko, économie d'environ 85 %, charge moyenne.

La conclusion est simple. Sur les données textuelles, toute compression réduit le trafic d'environ cinq fois. La différence entre les algorithmes est de quelques pour cent. Par conséquent, pour économiser du trafic via un proxy, l'important n'est pas quel algorithme, mais le fait même que la compression soit activée.

Astuce : Si vous téléchargez des données plutôt que de les envoyer, la charge sur votre processeur ne vient que de la décompression, et elle est rapide pour tous les algorithmes. Vous pouvez donc demander en toute sécurité l'option la plus efficace en termes de taux de compression.

✅ Vérification : Vous comprenez que brotli et zstd sont généralement un peu plus efficaces que gzip sur le texte, mais gzip est le plus compatible. C'est suffisant pour la pratique.

Étape 1 : Envoyer une requête et vérifier si la réponse est compressée

Objectif de l'étape. Apprendre à voir les en-têtes Content-Encoding et la taille réelle du corps. Sans cela, il est impossible de mesurer l'économie.

Vérification avec curl

1. Ouvrez un terminal.
2. D'abord, demandez la ressource sans compression pour connaître la taille d'origine. Exécutez :

   curl -s -o /dev/null -w "%{size_download}" https://example.com/api/data

3. Notez le nombre. C'est la taille de la réponse non compressée en octets.
4. Maintenant, demandez la compression. Le drapeau --compressed ajoute automatiquement Accept-Encoding et décompresse la réponse :

   curl -s --compressed -o /dev/null -w "%{size_download}" https://example.com/api/data

5. Comparez les deux nombres. Le second doit être nettement inférieur pour le même contenu.

Important : La valeur size_download dans curl avec --compressed reflète la taille des données déjà décompressées, pas ce qui a transité sur le réseau. Pour voir le volume réseau réel, utilisez l'en-tête de réponse et les mesures intermédiaires dont nous parlerons à l'étape de mesure.

Inspecter les en-têtes de réponse

1. Exécutez une requête avec le drapeau d'affichage des en-têtes :

   curl -s -I --compressed https://example.com/api/data

2. Repérez la ligne Content-Encoding. Si elle contient gzip, br ou zstd, le serveur a envoyé une réponse compressée.
3. Repérez la ligne Vary. La présence de Accept-Encoding dans sa valeur indique une configuration correcte du cache.

Astuce : Pour spécifier explicitement l'algorithme souhaité, ajoutez l'en-tête manuellement :

curl -s -H "Accept-Encoding: br" -I https://example.com/api/data

Travailler via le proxy Proxeon

Pour mesurer l'économie dans des conditions réelles, envoyez la requête via le proxy. Dans curl, cela se fait avec le drapeau -x :

curl -s --compressed -x http://identifiant:mot_de_passe@adresse_proxeon:port -o /dev/null -w "%{size_download}" https://example.com/api/data

Ainsi, vous verrez si la compression survit au proxy et si quelque chose ne supprime pas les en-têtes en cours de route.

Résultat attendu. Vous voyez deux nombres : la taille sans compression et la taille avec compression. Et vous voyez l'en-tête Content-Encoding dans la réponse. Cela signifie que le mécanisme fonctionne.

Problème possible : si les deux nombres sont identiques et que Content-Encoding est absent, le serveur n'a pas envoyé de compression. Les causes seront examinées dans une section dédiée.

✅ Vérification : Dans la réponse avec le drapeau --compressed, la ligne Content-Encoding contient l'un des algorithmes. L'étape est terminée.

Étape 2 : Mesurer l'économie réelle avec Python

Objectif de l'étape. Obtenir des chiffres précis du trafic réseau avant et après compression avec un script fonctionnel qui peut être appliqué à votre tâche.

Mesure simple avec requests

La bibliothèque requests ajoute automatiquement Accept-Encoding et décompresse la réponse par défaut. Pour mesurer précisément la taille réseau, nous examinerons la longueur du contenu brut avant décompression.

1. Créez un fichier measure.py.
2. Collez le code suivant :

import requests
url = "https://example.com/api/data"
# Requête sans compression
r_plain = requests.get(url, headers={"Accept-Encoding": "identity"})
size_plain = len(r_plain.content)
# Requête avec compression
r_comp = requests.get(url, headers={"Accept-Encoding": "gzip, br, zstd"})
encoding = r_comp.headers.get("Content-Encoding", "aucun")
size_wire = int(r_comp.headers.get("Content-Length", 0))
size_body = len(r_comp.content)
print("Taille sans compression, octets :", size_plain)
print("Algorithme de compression :", encoding)
print("Taille réseau environ, octets :", size_wire)
print("Taille après décompression, octets :", size_body)
if size_plain and size_wire:
saved = 100 - size_wire * 100 
print("Économie de trafic, pourcentage :", saved)

Attention : La valeur Content-Length n'est pas toujours présente, notamment lors d'un transfert en mode chunked. Si elle est absente, utilisez la méthode plus précise ci-dessous.

Mesure précise du volume réseau

Pour mesurer exactement ce qui a transité sur le réseau, désactivez la décompression automatique et comptez les octets du flux brut.

import requests
url = "https://example.com/api/data"
sess = requests.Session()
# Désactiver la décompression automatique pour voir la taille brute
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, stream=True)
raw_bytes = 0
for chunk in r.raw.stream(8192, decode_content=False):
raw_bytes += len(chunk)
print("Algorithme :", r.headers.get("Content-Encoding", "aucun"))
print("Octets bruts sur le réseau :", raw_bytes)

Comparez raw_bytes avec la taille de la requête non compressée. La différence est votre économie réelle.

Mesure via le proxy Proxeon

Ajoutez le paramètre proxies pour obtenir des chiffres dans des conditions de production :

proxies = {
"http": "http://identifiant:mot_de_passe@adresse_proxeon:port",
"https": "http://identifiant:mot_de_passe@adresse_proxeon:port",
}
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, proxies=proxies, stream=True)

Astuce : Exécutez la mesure plusieurs fois et faites la moyenne. Les réponses dynamiques varient en taille, une seule mesure peut donc être trompeuse.

Résultat attendu. Le script affiche l'algorithme de compression et le nombre d'octets bruts, qui est inférieur à la taille de la réponse non compressée. Si l'économie atteint soixante-dix pour cent ou plus sur une ressource textuelle, tout fonctionne correctement.

✅ Vérification : Dans la sortie, l'algorithme n'est pas égal à "aucun", et les octets bruts sont inférieurs à la taille sans compression. Parfait.

Étape 3 : Même mesure avec Node.js

Objectif de l'étape. Obtenir un outil de mesure fonctionnel en JavaScript pour ceux qui écrivent des clients Node.

Mesure du flux brut

1. Créez un fichier measure.js.
2. Collez le code qui compte les octets avant décompression :

const https = require('https');
const url = 'https://example.com/api/data';
function measure(acceptEncoding) {
 return new Promise((resolve) => {
const req = https.get(url, { headers: { 'Accept-Encoding': acceptEncoding } }, (res) => {
 let bytes = 0;
 res.on('data', (chunk) => { bytes += chunk.length; });
 res.on('end', () => {
resolve({ enc: res.headers['content-encoding'] || 'aucun', bytes });
 });
});
req.end();
 });
}
(async () => {
 const plain = await measure('identity');
 const comp = await measure('gzip, br, zstd');
 console.log('Taille sans compression, octets :', plain.bytes);
 console.log('Algorithme :', comp.enc);
 console.log('Taille compressée sur le réseau, octets :', comp.bytes);
 const saved = Math.round(100 - (comp.bytes * 100) / plain.bytes);
 console.log('Économie, pourcentage :', saved);
})();

Important : Dans cet exemple, nous lisons le flux brut de res et ne connectons pas zlib. Par conséquent, le compteur bytes montre exactement le volume réseau. C'est précisément ce que vous payez au fournisseur de proxy.

Décompression manuelle avec Node

Si vous devez aussi lire le contenu, décompressez le flux via le module intégré zlib :

const zlib = require('zlib');
let stream = res;
const enc = res.headers['content-encoding'];
if (enc === 'gzip') stream = res.pipe(zlib.createGunzip());
else if (enc === 'br') stream = res.pipe(zlib.createBrotliDecompress());
else if (enc === 'deflate') stream = res.pipe(zlib.createInflate());

Astuce : Pour zstd, les versions récentes de Node.js proposent zlib.createZstdDecompress. Si votre version ne l'inclut pas, mettez à jour Node ou utilisez un package npm dédié.

Résultat attendu. Node affiche une économie en pourcentage comparable à celle obtenue avec Python et curl.

✅ Vérification : Les trois outils donnent des chiffres d'économie proches. Vos mesures sont donc fiables.

Étape 4 : Pourquoi la réponse arrive non compressée

Objectif de l'étape. Apprendre à diagnostiquer pourquoi la compression n'a pas fonctionné et à en éliminer la cause. C'est le problème le plus courant en pratique.

Premier cas : le client n'a pas demandé

La cause la plus fréquente. Votre client HTTP n'a pas envoyé l'en-tête Accept-Encoding, et le serveur envoie honnêtement une réponse non compressée. Cela se produit lorsque vous formez manuellement les en-têtes et oubliez la compression, ou lorsque vous utilisez un socket de bas niveau.

1. Vérifiez ce qui part réellement vers le serveur. Avec curl, ajoutez le drapeau -v et trouvez la ligne Accept-Encoding dans les en-têtes sortants.
2. Si la ligne est absente, ajoutez-la explicitement avec -H ou le drapeau --compressed.
3. En Python, assurez-vous de ne pas avoir redéfini l'en-tête avec une valeur vide.

Attention : Certaines bibliothèques, lorsque vous définissez manuellement un en-tête, cessent d'ajouter leurs propres valeurs par défaut. Si vous définissez User-Agent à la main, vérifiez que Accept-Encoding n'a pas disparu en même temps.

Deuxième cas : le serveur ne sait pas

Le serveur peut ne pas prendre en charge la compression du tout, ou ne pas prendre en charge l'algorithme demandé. Dans ce cas, il renvoie une réponse non compressée, ce qui est acceptable selon la norme.

1. Demandez différents algorithmes un par un : d'abord gzip, puis br, puis zstd.
2. Observez lequel produit un Content-Encoding dans la réponse.
3. Si aucun, le serveur ne fournit pas de compression. Sur un serveur tiers, vous ne pouvez pas le changer, mais vous pouvez choisir un autre endpoint ou une autre API s'il en existe.

Astuce : De nombreuses API n'activent la compression que pour les réponses dépassant une certaine taille. Les petites réponses restent souvent non compressées volontairement, car les frais généraux de compression dépassent le gain.

Troisième cas : un intermédiaire a supprimé l'en-tête

Entre vous et le serveur, il peut y avoir un nœud de cache, une passerelle ou un proxy qui supprime ou modifie les en-têtes de compression. Parfois, l'intermédiaire décompresse la réponse pour ses besoins et vous envoie une version déjà décompressée.

1. Faites une requête directement et via le proxy, puis comparez les en-têtes Content-Encoding.
2. Si directement la compression est présente, mais via l'intermédiaire elle est absente, c'est l'intermédiaire qui intervient.
3. Lorsque vous travaillez via le proxy Proxeon, la compression est transmise de manière transparente ; si vous voyez une différence, cherchez le problème du côté du serveur cible ou de son CDN.

Résultat attendu. Vous savez exactement à quel maillon de la chaîne la compression se perd et vous comprenez quoi faire.

✅ Vérification : Vous pouvez expliquer en une phrase pourquoi une réponse spécifique arrive non compressée. Le diagnostic est maîtrisé.

Étape 5 : Pièges lors du travail avec la compression

Objectif de l'étape. Éviter les erreurs subtiles qui cassent les données ou faussent les mesures.

Double compression

Parfois, le contenu est déjà compressé au niveau de l'application, et le serveur le comprime à nouveau. Ou inversement : vous compressez le corps de la requête, et le proxy ou la bibliothèque le fait une seconde fois. La double compression n'apporte presque aucun gain, parfois même augmente la taille et gaspille sûrment du CPU.

1. Vérifiez s'il n'y a pas deux valeurs dans Content-Encoding, par exemple gzip dans br.
2. Ne compressez pas manuellement ce que la bibliothèque va de toute façon compresser automatiquement.
3. Si vous voyez une chaîne d'encodages, décompressez-la dans l'ordre inverse.

Flux corrompu

Une coupure de connexion ou une erreur d'intermédiaire peut entraîner un flux compressé incomplet. Lors de la décompression, vous obtiendrez une erreur ou des données tronquées.

1. Enveloppez toujours la décompression dans une gestion des erreurs.
2. En cas d'erreur de décompression, répétez la requête plutôt que d'essayer de lire des données corrompues.
3. Comparez la taille réelle avec Content-Length si elle est fournie.

Attention : Ne sauvegardez jamais des données partiellement décompressées comme résultat final. Un JSON corrompu a l'air plausible, mais provoquera des erreurs cachées plus loin dans le pipeline.

Décompression manuelle lorsque la bibliothèque ne le fait pas

Si vous avez désactivé la décompression automatique pour une mesure précise ou si vous utilisez un client de bas niveau, vous devrez décompresser manuellement. Exemple en Python :

import gzip, brotli, zlib
def decompress(data, encoding):
if encoding == "gzip":
return gzip.decompress(data)
if encoding == "br":
return brotli.decompress(data)
if encoding == "deflate":
return zlib.decompress(data)
return data

Astuce : Si la décompression deflate échoue, essayez d'appeler zlib.decompress avec le paramètre wbits égal à moins quinze. Certains serveurs envoient du deflate brut sans enveloppe zlib.

Résultat attendu. Vous savez décompresser manuellement n'importe lequel des formats pris en charge et gérez correctement les erreurs de flux.

✅ Vérification : Votre script ne plante pas sur une réponse corrompue, mais répète la requête. La robustesse est atteinte.

Étape 6 : Ce qu'il est inutile de compresser

Objectif de l'étape. Ne pas gaspiller de CPU et de temps à compresser ce qui est déjà compressé. Cela économise des ressources sans perte de gain de trafic.

Formats déjà compressés

Certaines données sont stockées dans des formats qui utilisent déjà une compression en interne. Essayer de les compresser à nouveau est inutile : le gain sera de quelques fractions de pour cent, et le CPU sera chargé inutilement.

• Images : JPEG, PNG, WebP, AVIF sont déjà compressés dans leur format interne.
• Vidéo : MP4, WebM, MKV contiennent un flux vidéo fortement compressé.
• Audio : MP3, AAC, OGG sont compressés par nature.
• Archives : ZIP, RAR, 7z, gz sont déjà des conteneurs compressés.

Pour ces ressources, Accept-Encoding n'apportera aucune économie sur le corps. De plus, le serveur ne les compresse généralement pas non plus, car il est configuré selon une liste de types MIME.

Ce qu'il vaut la peine de compresser

• HTML, CSS, JavaScript.
• Réponses API en JSON et XML.
• Texte brut, CSV, journaux.
• SVG, car c'est essentiellement du texte.

Astuce : Si vous téléchargez principalement des fichiers médias, l'économie de compression sera proche de zéro. Ici, le gain vient d'autre chose : ne demander que les tailles et formats nécessaires, plutôt que la compression elle-même. Mais cela relève de la gestion du trafic, pas de la compression en tant que telle.

Résultat attendu. Vous ne gaspillez pas de ressources à compresser des formats binaires et vous appliquez la compression uniquement là où elle est réellement utile.

✅ Vérification : Vous pouvez dire en une seconde s'il vaut la peine de compresser un type de réponse donné. La compréhension est acquise.

Vérification du résultat

Il est temps de vous assurer que tout est bien configuré. Parcourez la liste de contrôle.

Liste de contrôle de fonctionnalité

1. Votre client envoie l'en-tête Accept-Encoding avec les algorithmes souhaités.
2. La réponse contient Content-Encoding avec l'un de ces algorithmes sur les ressources textuelles.
3. Le script de mesure montre un volume réseau inférieur d'au moins soixante-dix pour cent à la taille non compressée pour le texte.
4. Via le proxy Proxeon, la compression est conservée, les chiffres correspondent à la requête directe.
5. La décompression ne produit aucune erreur et les données se lisent correctement.
6. Vous n'essayez pas de compresser les formats binaires.

Comment tester

1. Prenez trois endpoints différents : un avec JSON, un avec HTML, un avec une image.
2. Exécutez chacun via votre script de mesure.
3. Assurez-vous que sur les deux premiers l'économie est élevée, sur le troisième proche de zéro.

Indicateurs de succès. Pour une API textuelle, vous voyez régulièrement une économie comprise entre soixante-dix et quatre-vingt-dix pour cent. Pour les médias, l'économie est minimale, et c'est normal. Via le proxy, les chiffres ne se dégradent pas.

✅ Vérification : Les six points de la liste de contrôle sont remplis. La compression est configurée et mesurée correctement.

Erreurs courantes et solutions

Voici les problèmes fréquents au format problème, cause, solution.

La réponse n'est pas compressée bien que Accept-Encoding soit envoyé

Cause : le serveur ne prend pas en charge la compression pour ce type de contenu ou pour des réponses de cette taille. Solution : essayez un autre algorithme et assurez-vous que la ressource est textuelle et suffisamment volumineuse.

L'économie avec curl n'est pas visible, size_download ne change pas

Cause : le drapeau --compressed affiche la taille après décompression. Solution : mesurez le volume réseau séparément avec un script sans décompression automatique, comme aux étapes Python et Node.

La bibliothèque renvoie du charabia au lieu du texte

Cause : vous avez désactivé la décompression automatique mais n'avez pas décompressé le flux manuellement. Solution : déterminez Content-Encoding et appliquez la fonction de décompression correspondante.

Erreur lors de la décompression deflate

Cause : le serveur a envoyé du deflate brut sans enveloppe. Solution : appelez la décompression avec le paramètre wbits moins quinze.

La compression disparaît via le proxy

Cause : sur le chemin se trouve un nœud qui modifie les en-têtes, souvent le CDN du site cible. Solution : comparez les requêtes directe et via proxy pour identifier le maillon. Le proxy Proxeon transmet les en-têtes de manière transparente, le problème vient donc généralement du serveur.

Taille de réponse différente lors des mesures répétées

Cause : le contenu est dynamique et change d'une requête à l'autre. Solution : faites la moyenne de plusieurs mesures et comparez avec des paramètres de requête identiques.

Content-Length absent

Cause : le transfert en mode chunked ne donne pas la longueur à l'avance. Solution : comptez les octets manuellement pendant la lecture du flux, comme dans les exemples de scripts.

La double compression gonfle le CPU

Cause : le contenu est compressé deux fois à différents niveaux. Solution : supprimez la compression manuelle là où la bibliothèque ou le serveur le fait déjà.

Fonctionnalités supplémentaires

Une fois le scénario de base maîtrisé, il y a encore des possibilités.

Choix de priorité des algorithmes

Dans l'en-tête Accept-Encoding, vous pouvez indiquer un poids avec des valeurs q, pour suggérer des préférences au serveur. Par exemple

Accept-Encoding: zstd;q=1.0, br;q=0.9, gzip;q=0.8

Mise en cache des données décompressées

Si vous accédez plusieurs fois à la même ressource, mettez en cache le résultat décompressé de votre côté. Cela réduit à la fois le trafic et la charge CPU de la décompression répétée.

Mesure en masse sur une liste d'URL

Enveloppez le script de mesure dans une boucle sur une liste d'endpoints et compilez un tableau des économies. Ainsi, vous trouverez les réponses non compressées les plus lourdes de votre projet et vous vous en occuperez en priorité.

Astuce : Tenez un journal des économies en octets par jour. En multipliant par le prix du gigaoctet, vous obtiendrez un bénéfice monétaire concret de la compression activée lors du travail via un proxy.

✅ Vérification : Vous pouvez créer un tableau récapitulatif des économies pour plusieurs ressources en une seule exécution du script.

FAQ

Faut-il toujours demander brotli plutôt que gzip ?

Si vous ne faites que télécharger, la décompression est rapide pour tous les algorithmes, vous pouvez donc demander le plus efficace. En pratique, indiquez les trois dans Accept-Encoding : gzip, br, zstd. Le serveur choisira le meilleur disponible.

Combien de trafic la compression économise-t-elle sur une API textuelle ?

En général, entre soixante-dix et quatre-vingt-dix pour cent. Une réponse qui pesait un gigaoctet passera sur le réseau comme cent cinquante ou deux cents mégaoctets. L'économie lorsque vous payez par gigaoctet est directe et notable.

La compression affecte-t-elle la vitesse de réponse ?

Un volume de données plus faible se transmet plus rapidement, surtout sur les canaux lents. Le petit délai de compression côté serveur est généralement largement compensé par la réduction du temps de transfert.

Pourquoi curl affiche-t-il la même taille avec et sans compression ?

Parce que --compressed affiche la taille du corps déjà décompressé. Le volume réseau réel est inférieur. Mesurez le flux brut avec un script séparé.

Peut-on compresser le corps d'une requête POST ?

Oui, le client peut placer Content-Encoding dans la requête, mais le serveur doit savoir le décompresser. Tous les serveurs ne le prennent pas en charge, vérifiez donc la documentation de l'API.

La compression fonctionne-t-elle via le proxy Proxeon ?

Oui. Le proxy transmet les en-têtes Accept-Encoding et Content-Encoding de manière transparente, donc toute l'économie est conservée. C'est pourquoi il est avantageux de mesurer directement via le proxy, dans des conditions réelles.

Que faire si le serveur ne fournit pas la compression ?

Assurez-vous que vous demandez la compression et que la ressource est textuelle. Si le serveur reste silencieux, vous ne pouvez pas modifier un serveur tiers, mais vous pouvez choisir un autre endpoint ou compresser les données sur votre propre couche de cache.

Faut-il compresser les images via Accept-Encoding ?

Non. Les formats comme JPEG et WebP sont déjà compressés. Une compression supplémentaire n'apportera aucun gain et ne fera que charger le processeur.

Comment choisir entre zstd et brotli ?

Pour le téléchargement, la différence de trafic est de quelques pour cent. Indiquez les deux dans Accept-Encoding et laissez le serveur décider. S'il ne prend en charge que l'un d'eux, vous l'obtiendrez.

Vary est-il nécessaire côté client ?

En tant que client, vous ne définissez pas Vary, c'est le serveur qui le fait. Mais le comprendre est utile : cela explique pourquoi le cache renvoie parfois une version compressée, parfois non.

Conclusion

Vous avez parcouru le chemin allant de la théorie aux mesures pratiques. Vous comprenez maintenant comment la compression est négociée via Accept-Encoding, Content-Encoding et Vary. Vous savez demander la compression dans curl, Python et Node.js, et surtout mesurer le volume réseau réel avant et après. Vous savez pourquoi une réponse arrive parfois non compressée et comment diagnostiquer les trois causes typiques. Vous avez abordé les pièges : la double compression, les flux corrompus et la décompression manuelle. Et vous ne gaspillez plus de ressources à compresser des images, des vidéos et des archives.

Que faire ensuite. Exécutez le script de mesure sur tous les endpoints principaux de votre projet. Trouvez ceux où la compression n'est pas activée et demandez-la explicitement. Tenez un journal des octets économisés pour voir le bénéfice monétaire lors du travail via le proxy Proxeon. Une fois le scénario de base maîtrisé, passez à la mesure en masse sur une liste d'URL et aux priorités d'algorithmes avec les valeurs q.

La compression est l'un des moyens les plus économiques de réduire votre facture de trafic. Un en-tête correctement envoyé peut réduire le volume de données de plusieurs fois. Cet outil est désormais entre vos mains, et vous pouvez l'appliquer en connaissance de cause et avec des chiffres précis.