La mise en cache est l'une des fonctions les plus anciennes du proxy : au lieu de télécharger encore et encore le même contenu, en conserver une copie et répondre localement aux requêtes suivantes. Avec la généralisation du HTTPS, la portée de cette fonction s'est réduite, mais elle n'a pas totalement disparu — et elle reste une source d'économies sérieuse dans votre propre chaîne de collecte de données.
Flux de base
En cas de hit de cache, le serveur d'origine n'est jamais sollicité. C'est un gain en vitesse, en bande passante et en charge sur le serveur cible.
Qui décide de ce qui est stocké ?
C'est le serveur qui décide et l'indique via l'en-tête Cache-Control :
| Directive | Signification | Comportement du proxy |
|---|---|---|
public | Un cache partagé peut le stocker | Stocke |
private | Seul le navigateur doit le stocker | Ne stocke pas |
no-store | Ne rien stocker | Ne stocke pas |
no-cache | Peut être stocké mais doit être validé à chaque utilisation | Effectue une requête conditionnelle |
max-age=3600 | Considéré comme frais pendant 3600 secondes | Ne va pas à la source pendant ce délai |
s-maxage=600 | Durée distincte pour les caches partagés | Prime sur cette valeur |
no-cachene signifie pas « ne stocke pas du tout » — mais « stocke, mais valide avant utilisation ». L'équivalent de « ne stocke pas du tout » est no-store.
Requêtes conditionnelles : 304 Not Modified
Lorsque la copie en cache devient obsolète, le proxy n'est pas obligé de retélécharger le contenu depuis le début. Il demande au serveur : « la version dont je dispose est-elle encore valide ? »
Une réponse 304 ne contient pas de corps ; seuls les en-têtes sont renvoyés. Cela revient à ramener une page de 500 Ko à 300 octets.
Utiliser ce mécanisme dans votre propre chaîne de collecte de données le coût de bande passante le réduit sensiblement.
Quel impact le HTTPS a-t-il eu sur le cache ?
Une fois le tunnel CONNECT établi, le proxy ne voit pas le contenu — il ne peut donc pas le mettre en cache. Comme la quasi-totalité du web est passée au HTTPS, la mise en cache proxy classique est devenue largement inopérante.
C'est pourquoi la mise en cache moderne a quitté la couche proxy pour se déplacer vers le CDN et la couche client.
Mettre en place votre propre cache
Si la mise en cache proxy n'est pas exploitable, vous pouvez obtenir le même gain dans votre propre application. Dans les chaînes de collecte de données, c'est très efficace :
Cette couche simple vous évite de retélécharger sans cesse des pages qui changent peu. Sur des ressources facturées au Go comme les residential proxies, l'économie se répercute directement sur la facture.
Quand la mise en cache est-elle une erreur ?
Cache adapté
- Pages produit et catégorie qui changent peu.
- Données de référence statiques.
- Traitements qui récupèrent la même page plusieurs fois par jour.
- Phase de développement et de test (préserve le quota).
Cache inadapté
- Suivi des prix et des stocks en temps réel.
- Contenus personnalisés.
- Pages nécessitant une session.
- Travaux SEO qui suivent l'évolution des classements.
Travailler avec des données périmées issues du cache peut produire de plus mauvais résultats que ne rien collecter du tout. Dans les domaines sensibles au temps comme les prix et les stocks, gardez une durée de cache très courte ou n'en utilisez pas du tout.
Résumé
Avec la généralisation du HTTPS, la mise en cache proxy a largement perdu sa fonction au sens classique, car dans un tunnel CONNECT le proxy ne voit pas le contenu. En revanche, il reste tout à fait possible — et très utile — de reproduire la même logique dans votre propre couche applicative. Les requêtes conditionnelles basées sur ETag éliminent la quasi-totalité du trafic sur les contenus qui changent peu. Pour les données sensibles au temps, en revanche, il faut éviter le cache. Pour le calcul de consommation, notre article sur la bande passante vous pouvez le consulter.