Le problème du cache froid
Un cache froid désigne l'état d'une page dont la copie en cache est absente ou vient d'expirer. La requête suivante ne peut pas être servie depuis le cache : le serveur d'origine doit reconstruire la page depuis zéro (requêtes base de données, rendu de template, exécution complète), ce qui explique pourquoi le premier accès après un vidage est nettement plus lent qu'une réponse mise en cache.
À chaque fois que votre cache est vidé (après un déploiement, une mise à jour de contenu ou une expiration planifiée), le prochain visiteur tombe sur une page non mise en cache. Votre serveur doit tout reconstruire depuis zéro : requêtes base de données, rendu de template, exécution PHP complète.
Sur l'ensemble des runs exécutés par CacheBoost, une réponse en cache froid renvoie typiquement son premier octet en 800 à 2 000 ms, contre moins de 200 ms une fois la même page préchauffée. L'écart exact dépend de votre stack, mais la forme est toujours la même : le premier accès après un vidage est le lent, et quelqu'un doit le payer.
C'est mauvais pour vos utilisateurs. Mais c'est aussi mauvais pour votre SEO, et pour deux raisons distinctes qu'il vaut mieux ne pas confondre.
Pourquoi Google s'intéresse au TTFB
Le TTFB (Time to First Byte) est le temps écoulé entre l'envoi d'une requête HTTP par le navigateur et la réception du premier octet de la réponse du serveur. Il mesure la réactivité brute du serveur et constitue la base sur laquelle repose le LCP (Largest Contentful Paint) de Google : un TTFB lent retarde tout ce qui s'affiche ensuite.
Un cache froid atteint Google par deux mécanismes distincts. On les amalgame souvent, alors qu'ils se comportent très différemment.
1. Ce sont vos utilisateurs qui alimentent le signal de ranking
Les Core Web Vitals, et le LCP (Largest Contentful Paint) en particulier, sont un signal de classement. Mais les chiffres sur lesquels Google classe sont des données terrain : ils proviennent du Chrome UX Report (CrUX), qui agrège ce que les vrais utilisateurs Chrome ont réellement vécu sur votre site. Les temps de réponse mesurés par Googlebot n'alimentent pas cette métrique.
Le chemin vers le ranking passe donc par vos visiteurs, pas par le crawler :
Vidage du cache → un vrai utilisateur tombe sur un MISS → TTFB lent → LCP dégradé
→ cet échantillon entre dans votre distribution CrUX → signal d'expérience affaibliChaque accès froid encaissé par un humain est un mauvais échantillon dans votre 75e centile. Préchauffer, c'est faire encaisser ce coup à la machine plutôt qu'à un utilisateur, pour que l'échantillon lent n'entre jamais dans CrUX.
2. Le rythme de crawl de Googlebot réagit à votre serveur
Côté crawler, le mécanisme est tout autre. Google ajuste l'intensité de son crawl en fonction de la façon dont votre serveur répond. D'après la documentation Google sur le budget de crawl : si un site ralentit ou renvoie des erreurs serveur, la limite de crawl baisse et Googlebot explore moins ; si les temps de réponse restent stables ou s'améliorent, la limite remonte et Google utilise davantage de connexions.
Un site qui sert systématiquement des pages froides à Googlebot obtient donc moins de pages explorées par jour, ce qui signifie une découverte plus lente des nouvelles URLs et des copies plus périmées de celles que vous venez de mettre à jour. C'est un problème de fraîcheur et de couverture, pas un problème de Core Web Vitals, et aucun réglage de LCP ne le corrigera.
Une précision sur les chiffres de conversion
On cite souvent l'étude d'Akamai selon laquelle 100 ms de temps de chargement supplémentaire étaient corrélées à une baisse de 7 % du taux de conversion (State of Online Retail Performance, printemps 2017). C'est un bon argument pour se soucier de la latence, mais c'est une statistique de conversion mesurée sur des sites e-commerce, pas une statistique de ranking. Utilisez-la pour justifier le chantier auprès d'une direction, pas comme preuve du fonctionnement du classement Google.
La solution : le préchauffage de cache
Le préchauffage de cache (cache warming) consiste à envoyer proactivement des requêtes vers les pages d'un site juste après un vidage de cache, avant l'arrivée des vrais visiteurs ou des crawlers, afin que toute requête suivante soit servie depuis un cache chaud plutôt que de déclencher une reconstruction lente et non mise en cache.
Le préchauffage de cache consiste à précharger vos pages avant que les visiteurs (ou les crawlers) n'arrivent. Au lieu d'attendre la première requête pour construire le cache, vous envoyez une requête de warm-up vers chaque URL après chaque vidage, remplissant le cache pour que toutes les requêtes suivantes obtiennent la version rapide et mise en cache.
Déploiement → Vidage du cache → CacheBoost préchauffe les URLs → Le premier vrai visiteur arrive sur un cache chaudAvec CacheBoost, cela se passe automatiquement :
- Vous configurez un boost pointant vers votre sitemap XML
- Vous définissez un planning (expression cron) ou le déclenchez via l'API après chaque déploiement
- CacheBoost crawle toutes vos URLs depuis une ou plusieurs régions, remplissant le cache
Ce qui est préchauffé
Une configuration typique préchauffe :
- Toutes les pages listées dans votre sitemap XML
- Plusieurs variantes de user-agent (desktop, mobile, Googlebot, GPTBot), lorsque votre clé de cache varie effectivement selon le user-agent
- Depuis plusieurs régions géographiques si vous avez un CDN
Variantes de user-agent : seulement si votre clé de cache varie
Préchauffer avec un user-agent Googlebot ou GPTBot n'a d'intérêt que si le user-agent fait partie de votre clé de cache. Vérifiez si votre origine envoie un Vary: User-Agent, ou si votre CDN est configuré pour un cache par classe d'appareil (mobile redirect chez Cloudflare, séparation mobile/desktop dans Varnish, clé $device dans Nginx).
Si ce n'est pas le cas, tous les user-agents pointent vers le même objet en cache et une seule variante les préchauffe tous. Préchauffer quatre user-agents sur une clé de cache indifférente au UA ne rend pas le cache plus chaud : cela multiplie simplement votre quota d'URLs par quatre.
Un autre point de vigilance : une requête qui se déclare Googlebot depuis une IP dont le reverse DNS ne vérifie pas est précisément ce que les WAF et les solutions de bot management sont faits pour bloquer. Si vous préchauffez avec des user-agents de bots, whitelistez d'abord les IP de préchauffage CacheBoost dans votre WAF, sinon vos requêtes de warm-up seront challengées ou rejetées et le cache restera froid.
Préchauffage régional : le cache est par PoP
Un cache CDN n'est pas un cache. C'est un cache par point de présence, et un HIT à Paris ne vous dit rien sur Ashburn.
Cela compte plus qu'il n'y paraît, à cause de la provenance des crawlers. La documentation Google sur les pages adaptées à la langue et au pays précise que les adresses IP par défaut du crawler Googlebot semblent basées aux États-Unis. Google opère également un crawl géo-distribué depuis des IP hors États-Unis, mais le défaut américain reste ce que la plupart des sites observent la plupart du temps.
Conséquence pour un site européen derrière un CDN : votre PoP de Paris peut être parfaitement chaud, vos visiteurs français peuvent obtenir des réponses en 100 ms, et Googlebot peut malgré tout tirer des pages froides via un PoP américain et mesurer votre origine au pire moment. Préchauffer depuis une seule région masque complètement le problème : le tableau de bord est au vert pendant que le crawler est servi depuis un edge froid.
Si votre CDN sert plusieurs régions, préchauffez depuis plusieurs régions, et assurez-vous que l'une d'elles se trouve là où sont réellement vos crawlers.
Et les crawlers IA (GEO) ?
Les mêmes mécanismes de cache froid s'appliquent à GPTBot, ClaudeBot, PerplexityBot et aux fetchers déclenchés par l'utilisateur derrière ChatGPT, Claude et Perplexity. Mais les éditeurs documentent bien moins leur comportement que Google, et certaines habitudes du SEO classique ne se transposent pas. Nous avons détaillé ce qui est documenté et ce qui ne l'est pas dans un article dédié : Comment les crawlers IA gèrent les pages lentes et le cache froid.
Mesurer l'impact
Le taux de cache hit (cache hit ratio) est le pourcentage de requêtes servies directement depuis le cache plutôt que par le serveur d'origine. Un taux supérieur à 90 % signifie que la plupart des visiteurs et des crawlers obtiennent la version rapide et mise en cache d'une page.
Après avoir activé le préchauffage de cache, voici où chaque chiffre se trouve réellement :
| Ce que vous cherchez | Où le trouver |
|---|---|
| TTFB terrain (ce qu'ont vécu les vrais utilisateurs) | PageSpeed Insights, section « Découvrez ce que vivent vos utilisateurs réels », ou l'API CrUX / le dataset BigQuery |
| LCP | Search Console, rapport Core Web Vitals (Signaux web essentiels) |
| Temps de réponse moyen vu par Googlebot | Search Console, Paramètres, rapport Statistiques d'exploration |
| Taux de cache hit | Le tableau de bord de votre CDN ou reverse proxy |
Une erreur fréquente : le rapport Expérience sur la page de la Search Console n'affiche pas de TTFB. Il restitue l'état des Core Web Vitals, pas le temps de réponse serveur. Pour le TTFB terrain il faut passer par CrUX, et pour ce que Googlebot a mesuré il faut le rapport Statistiques d'exploration. Ce sont deux chiffres différents issus de deux populations différentes, et les deux méritent d'être suivis.
Pourquoi cela prend quelques semaines. CrUX est calculé sur une fenêtre glissante de 28 jours : un correctif déployé aujourd'hui entre immédiatement dans le jeu de données, mais ne remplace complètement les anciens échantillons qu'au bout de quatre semaines. Attendez-vous à une amélioration progressive plutôt qu'à une marche d'escalier, et ne jugez pas le résultat avant que la fenêtre ait tourné.
Les statistiques d'exploration, à l'inverse, bougent en quelques jours : c'est généralement là que vous verrez le préchauffage payer en premier.
Démarrer
CacheBoost propose un plan gratuit avec 500 URLs par mois, de quoi commencer avec n'importe quel site de petite ou moyenne taille. Ajoutez votre sitemap, configurez votre premier boost, et votre cache reste chaud automatiquement.
