Réduire sa consommation de Go : images, compression, cache

Les proxys résidentiels et mobiles sont facturés au trafic, et trois choix techniques — ce que l'on charge, ce que l'on compresse et ce que l'on met en cache — pèsent plus sur la facture que le choix du canal le moins cher. Voyons ce qu'il faut bloquer en priorité, comment fonctionne la compression des réponses, à quoi sert un cache conservé entre les exécutions et où se situe la limite au-delà de laquelle l'économie fausse la vérification elle-même.

Blocage des images, des polices, des vidéos et des trackers

Quatre types de ressources concentrent l'essentiel des économies. Les images constituent le poste le plus lourd sur une fiche produit : 2 à 5 Mo par page. Les polices pèsent moins à l'unité, mais elles se chargent par lots — quelques familles suffisent à ajouter un mégaoctet à chaque page. Les vidéos à lecture automatique forment une catégorie à part : des dizaines de mégaoctets par minute en flux continu, et un fil d'actualité qui défile sans s'arrêter épuise un forfait de trafic plus vite que n'importe quel autre élément. Les trackers et les scripts publicitaires sont légers en eux-mêmes, mais ils entraînent une chaîne de dizaines de requêtes supplémentaires vers des domaines tiers.

Le blocage se configure au niveau de l'outil d'automatisation : en interceptant les requêtes selon le type de ressource (image, media, font) ou selon le domaine des réseaux connus d'analyse et de publicité. Pour les tâches où seul le texte compte — prix, disponibilité, statut —, bloquer ces quatre types ne change pas le résultat : les données utiles se trouvent dans le HTML ou dans la réponse de l'API, pas dans les fichiers multimédias eux-mêmes.

Compression des réponses

L'en-tête Accept-Encoding avec les valeurs gzip, deflate, br indique au serveur que le client accepte une réponse compressée ; la plupart des serveurs compressent les formats texte — HTML, JSON, CSS, JS — mais ne touchent pas aux formats déjà compressés comme JPEG et MP4, car une recompression n'apporte aucun gain. D'où une conclusion pratique : la compression économise surtout du trafic sur les pages textuelles et les réponses d'API, et non sur les fiches avec images, où l'essentiel du poids vient déjà des médias.

Le canal proxy ne compresse pas le trafic par lui-même : la compression se configure côté serveur et côté client. Le rôle du proxy est ici passif — il transmet la réponse telle quelle, compressée ou non —, de sorte que le gain de la compression ne remplace pas celui du blocage des médias : les deux s'additionnent.

Cache entre les exécutions et abandon du rechargement des pages

Une automatisation qui démarre chaque exécution avec un profil de navigateur vierge retélécharge toutes les ressources statiques — polices, scripts de bibliothèques, CSS — qui n'ont pas changé depuis la dernière exécution. Un répertoire de cache persistant, réutilisé d'une exécution à l'autre, supprime cette redondance : le navigateur récupère les fichiers répétitifs sur le disque local au lieu de les redemander via le proxy.

La seconde part de l'économie consiste à ne pas demander deux fois la même page au sein d'une même tâche. Les requêtes conditionnelles avec les en-têtes If-Modified-Since et If-None-Match permettent au serveur de renvoyer le statut 304 sans corps de réponse si la page n'a pas changé depuis la dernière vérification — ce qui économise presque tout le trafic sur les pages inchangées lors d'une surveillance répétée. Pour intégrer le proxy dans l'automatisation elle-même, consultez l'article proxys pour les automatisations de navigateur.

Comment mesurer l'économie « avant / après » sur une tâche réelle

L'effet doit être évalué non pas sur un test synthétique, mais sur une tâche réelle avec un ensemble de pages fixe. Passage « avant » : paramètres par défaut, chargement complet de toutes les ressources, consommation relevée dans l'espace client pour un passage. Passage « après » : le même ensemble de pages, avec le blocage des médias et le cache activés, et le même compteur de trafic. L'écart entre les deux chiffres est l'économie réelle pour cette tâche précise, et non une moyenne tirée du cas d'un autre.

Il faut comparer non seulement le volume de trafic, mais aussi le nombre de requêtes échouées et de nouvelles tentatives : si l'économie de volume s'accompagne d'une hausse des nouvelles tentatives, une partie du gain est reperdue. La liste des indicateurs pour ce contrôle figure dans l'article comment vérifier la qualité des proxys.

Quand l'économie fausse la vérification elle-même

Chaque technique a un seuil au-delà duquel l'économie de trafic se substitue au résultat de la tâche. Les images bloquées faussent la vérification lorsque la tâche est elle-même visuelle : contrôle d'une bannière, capture d'écran d'une vitrine, test de mise en page adaptative. Les scripts désactivés cassent l'analyse des données si le contenu se charge via JavaScript après le chargement HTML initial — sans exécution des scripts, la page reste vide.

Un cache périmé constitue un risque à part : si l'on vérifie un prix ou une disponibilité à jour, une réponse mise en cache affichera les données d'hier comme si elles étaient fraîches. Il convient de désactiver l'économie sur les médias et le cache là où la tâche vérifie précisément ce que cette économie masque : un prix dynamique, l'état visuel d'une page ou un contenu dépendant de l'actualité des données. Courir après le canal le moins cher au lieu de régler l'économie avec discernement produit souvent l'effet inverse — pour en savoir plus, voir l'article proxys bon marché ou haut de gamme.

Questions fréquentes

Combien de trafic le blocage des images et des vidéos permet-il réellement d'économiser ?

Sur les fiches avec médias, de 3 à 10 fois selon le nombre d'images d'origine ; sur les fils vidéo, un ordre de grandeur de plus, car la lecture automatique sans blocage consomme des dizaines de mégaoctets par minute. Seul un passage « avant / après » sur votre propre tâche donne le chiffre exact — les estimations moyennes issues d'autres projets ne tiennent pas compte de la structure de vos pages.

Peut-on compresser à la volée, via le proxy, des images déjà chargées ?

Les proxys ordinaires ne transcodent ni ne recompressent les médias : ils transmettent la réponse du serveur telle quelle. Des services de transformation du trafic existent, mais il s'agit d'un autre type de produit, et non d'une propriété d'un canal résidentiel ou mobile ; il est moins cher et plus fiable de ne simplement pas charger les médias inutiles au résultat.

Comment savoir si le cache ou le blocage des médias a faussé la vérification au lieu d'économiser du trafic ?

Comparez le résultat de la tâche, et pas seulement le volume de trafic : si, après optimisation, le prix, la disponibilité ou le statut obtenus ne correspondent plus à ce que l'on voit manuellement sur le site, l'économie a touché ce qui devait rester intact. Ce contrôle doit être régulier, et non effectué une seule fois lors de la configuration.

Le choix du canal selon la tâche — adresses résidentielles et mobiles facturées au trafic, ou adresses de datacenter au mois — est disponible dans la rubrique proxys.