Cache HTTP et TTL : fonctionnement, stratégies et impact SEO

Le cache HTTP et le TTL (Time To Live) sont deux concepts fondamentaux de la performance web. Le cache permet de stocker temporairement des ressources (images, CSS, JavaScript) proches de l'utilisateur afin d'éviter de les retélécharger à chaque visite. Le TTL définit combien de temps une ressource peut rester dans ce cache avant d'être considérée périmée. Bien configurés, ces mécanismes réduisent considérablement les temps de chargement, soulagent le serveur d'origine, et améliorent les Core Web Vitals — avec un impact direct sur le SEO.

Qu'est-ce que le cache HTTP ?

Le cache HTTP est un mécanisme qui permet à différents composants de la chaîne de livraison d'une page web de conserver une copie locale des ressources téléchargées. Lorsqu'un navigateur charge une page pour la première fois, il télécharge chaque ressource depuis le serveur. Si ces ressources sont accompagnées d'en-têtes HTTP indiquant qu'elles peuvent être mises en cache, le navigateur (et/ou le CDN) en conserve une copie. Lors des visites suivantes, la ressource est servie depuis ce cache local plutôt que retéléchargée depuis le serveur — ce qui est dramatiquement plus rapide.

Il existe plusieurs niveaux de cache dans la chaîne de livraison d'une ressource web. Le cache navigateur (browser cache) stocke les ressources directement dans l'appareil de l'utilisateur — sur son disque dur ou en mémoire. Le cache CDN (ou cache périphérique, edge cache) stocke les ressources sur les serveurs du réseau de distribution, géographiquement proches des utilisateurs. Le cache serveur (server-side cache ou reverse proxy cache, comme Varnish ou Nginx) stocke les ressources côté hébergement, avant même qu'elles atteignent le réseau.

Les en-têtes Cache-Control : comment définir le comportement du cache

L'en-tête HTTP Cache-Control est le principal mécanisme par lequel un serveur communique ses instructions de mise en cache. Il est envoyé avec chaque réponse HTTP et peut contenir plusieurs directives combinées. Voici les directives les plus importantes :

• max-age=N : la ressource peut être mise en cache pendant N secondes. Exemple : max-age=31536000 = 1 an. Directive la plus utilisée pour les ressources statiques.
• s-maxage=N : comme max-age, mais s'applique uniquement aux caches partagés (CDN, reverse proxies), pas au cache navigateur. Permet des politiques différentes pour CDN et navigateur.
• no-cache : la ressource peut être mise en cache, mais le cache doit toujours vérifier auprès du serveur si elle est encore valide avant de la servir (via ETag ou Last-Modified).
• no-store : la ressource ne doit jamais être mise en cache, nulle part. À utiliser uniquement pour les contenus très sensibles (données personnelles, transactions).
• public : la ressource peut être mise en cache par n'importe quel cache, y compris les caches partagés CDN.
• private : la ressource peut être mise en cache uniquement par le navigateur de l'utilisateur, pas par les caches intermédiaires.
• immutable : indique que la ressource ne changera jamais pendant sa durée de vie (max-age). Le navigateur n'enverra pas de requête de validation même à l'expiration.

Pour les images statiques d'une boutique e-commerce, la directive optimale est généralement : Cache-Control: public, max-age=31536000, immutable. Cette combinaison indique que l'image peut être mise en cache publiquement, pendant un an, et qu'elle ne changera pas. Si l'image change (nouvelle photo produit), l'URL doit changer pour contourner le cache — une technique appelée « cache busting » par versionnage d'URL.

TTL (Time To Live) : combien de temps garder une ressource en cache ?

Le TTL (Time To Live) est la durée pendant laquelle une ressource mise en cache est considérée fraîche (fresh) et peut être servie directement sans vérification auprès du serveur d'origine. Il est exprimé en secondes dans l'en-tête max-age. Passé ce délai, la ressource est considérée périmée (stale) — elle peut encore être servie dans certains cas, mais le cache doit idéalement la revalider.

Le choix du TTL est un équilibre entre deux objectifs contradictoires : maximiser l'utilisation du cache (TTL long = moins de requêtes au serveur) et garantir que les utilisateurs reçoivent des contenus à jour (TTL court = les changements se propagent vite). Pour les ressources qui ne changent pas souvent, comme les images produit, un TTL long (1 an) est optimal. Pour les ressources qui changent fréquemment, comme les prix ou les stocks, un TTL court ou nul est nécessaire.

• 1 an (31 536 000 secondes) : images produit, CSS/JS versionnés, polices web — ressources stables avec versionnage d'URL
• 1 mois (2 592 000 secondes) : images de marque ou de catégorie mises à jour occasionnellement
• 1 heure à 1 jour : contenus semi-dynamiques, pages de catégorie, listes de produits
• 0 ou no-store : pages panier, pages de paiement, données utilisateur connecté — jamais mettre en cache

Invalidation du cache : comment gérer les changements de contenu

La mise en cache à long terme soulève une question évidente : que se passe-t-il quand le contenu change ? Si une image est mise en cache pendant 1 an mais que vous la modifiez après 2 mois, les visiteurs continueront de voir l'ancienne version pendant 10 mois. C'est là qu'interviennent les stratégies d'invalidation de cache.

La stratégie la plus fiable est le versionnage d'URL (URL versioning ou cache busting). Le principe : l'URL de la ressource inclut un identifiant unique qui change chaque fois que la ressource change. Par exemple, /images/produit-chaussure-v2.webp au lieu de /images/produit-chaussure.webp. Ou encore via un paramètre : /images/produit.jpg?v=1705234567. Lorsque l'image change, l'URL change, et le cache traite cette nouvelle URL comme une ressource entièrement nouvelle — sans problème de stale content.

Une autre stratégie est l'API de purge CDN : les CDN modernes exposent une API permettant d'invalider immédiatement des URLs ou des groupes d'URLs spécifiques dans leur cache. Lorsqu'un marchand modifie une image dans son back-office, un appel API au CDN invalide le cache pour cette image. Les visitites suivantes récupèrent la nouvelle version directement depuis le serveur d'origine, qui est ensuite recachée.

Cache CDN vs cache navigateur : complémentarité et différences

Le cache CDN et le cache navigateur sont complémentaires et servent des objectifs différents. Le cache CDN bénéficie à tous les visiteurs, nouveaux et récurrents : une image mise en cache sur le nœud CDN parisien est servie rapidement à n'importe quel visiteur situé en France, qu'il ait déjà visité votre boutique ou non. Le cache navigateur bénéficie uniquement aux visiteurs récurrents, sur leur propre appareil : si un utilisateur a déjà téléchargé l'image lors d'une visite précédente, son navigateur la sert depuis le disque local sans aucune requête réseau.

En pratique, les deux niveaux de cache se complètent : le cache CDN réduit la latence pour le premier chargement d'une page (nouveau visiteur ou cache navigateur expiré), tandis que le cache navigateur élimine complètement le réseau pour les visites répétées sur le même appareil. Une ressource avec max-age=31536000 ne sera requise via le réseau qu'une seule fois par an et par appareil — un gain de performance très significatif pour les visiteurs fidèles.

ETag et Last-Modified : la validation conditionnelle du cache

Même avec un TTL expiré, le navigateur n'est pas forcé de retélécharger une ressource depuis zéro. Il peut envoyer une requête conditionnelle pour vérifier si la ressource a changé : si ce n'est pas le cas, le serveur répond avec un code HTTP 304 (Not Modified) sans corps de réponse — économisant la bande passante tout en confirmant la fraîcheur de la ressource cachée.

L'ETag (Entity Tag) est un identifiant unique généré par le serveur pour une version spécifique d'une ressource — typiquement un hash du contenu du fichier. Quand le navigateur fait une requête conditionnelle, il envoie l'ETag de sa version cachée dans l'en-tête If-None-Match. Si le serveur a le même ETag (la ressource n'a pas changé), il répond 304 ; sinon, il envoie la nouvelle version avec un nouvel ETag.

L'en-tête Last-Modified fonctionne de manière similaire : le serveur indique la date de dernière modification de la ressource, et le navigateur l'envoie dans If-Modified-Since lors des requêtes conditionnelles. Ces mécanismes de validation permettent de maintenir le cache à jour sans gaspiller de bande passante lorsque le contenu n'a pas changé.

Comment Lexiik gère le cache et l'invalidation automatiquement

Lexiik implémente une stratégie de cache optimale pour les images de boutiques PrestaShop, en résolvant automatiquement le problème d'invalidation qui rend le cache longue durée habituellement risqué. Chaque image uploadée sur Cloudflare R2 reçoit des en-têtes Cache-Control: public, max-age=31536000, immutable — un an de cache sur tous les edge nodes Cloudflare et dans les navigateurs des visiteurs.

La problématique d'invalidation est gérée automatiquement par Lexiik via deux mécanismes. D'abord, le versionnage d'URL : les images servies par Lexiik CDN utilisent des identifiants dans leurs URLs qui changent automatiquement lorsque l'image est modifiée dans le back-office PrestaShop. Ensuite, l'appel automatique à l'API de purge Cloudflare : lorsqu'une image change, Lexiik envoie une requête de purge à Cloudflare pour invalider immédiatement le cache CDN pour cette image spécifique, sans affecter les autres images. Les visiteurs reçoivent la nouvelle image dès leur prochaine visite, sans jamais voir une version périmée.

Pourquoi un cache longue durée améliore le SEO

Un TTL d'un an sur les images produit améliore le SEO par plusieurs mécanismes directs et indirects. Directement, les images chargées depuis le cache (CDN ou navigateur) s'affichent en dizaines ou centaines de millisecondes, contre plusieurs secondes pour un téléchargement réseau complet. Cela améliore le LCP — la métrique Core Web Vital la plus liée aux images — et peut faire passer une page d'un score « Mauvais » à « Bon » selon les seuils Google.

Indirectement, un cache efficace réduit le nombre de requêtes HTTP envoyées à votre serveur d'origine. Moins de charge serveur = meilleur TTFB (Time To First Byte) pour le contenu HTML dynamique que votre PrestaShop génère. Un TTFB inférieur à 200 ms est recommandé par Google ; un serveur surchargé de requêtes d'images peut avoir un TTFB dégradé affectant toutes les métriques de performance.

Enfin, pour les visiteurs récurrents — qui sont souvent les plus susceptibles de convertir — un cache navigateur bien configuré crée une expérience de navigation quasi instantanée. Les pages produit semblent s'afficher instantanément, les images sont déjà présentes en mémoire. Cette expérience fluidifie le tunnel d'achat et réduit les abandons, avec un impact positif sur les métriques comportementales que Google peut prendre en compte.

• LCP amélioré : images chargées depuis le cache local ou CDN en quelques millisecondes
• TTFB amélioré : moins de requêtes vers le serveur d'origine = serveur moins chargé = HTML livré plus vite
• Meilleur score PageSpeed : Google Lighthouse pénalise l'absence de politique de cache longue durée
• Économie de bande passante : moins de données transférées = moins de coûts et meilleure performance sur mobile
• Expérience visiteur fidèle améliorée : navigation quasi instantanée pour les clients récurrents