Le cache de Google peut-il fausser le rendu de vos pages JavaScript ?

Pourquoi Google mise autant sur le cache lors du rendu ?

Le rendu JavaScript coûte cher en ressources serveur. Pour ne pas multiplier les requêtes inutiles à chaque crawl, Googlebot réutilise les ressources cacheables (JS, CSS, images) tant qu'elles respectent les headers HTTP de cache (Cache-Control, Expires, ETag).

Concrètement, si votre fichier app.bundle.js affiche un cache de 7 jours, Google ne le re-téléchargera pas pendant cette période même si vous le modifiez côté serveur. Il utilisera la version en cache pour rendre la page. C'est efficace pour Google, moins pour vous si vous déployez souvent.

Qu'est-ce qu'une requête GET cacheable exactement ?

Une requête GET est considérée cacheable si elle retourne un statut 200 ou 301 et qu'elle comporte des headers de cache explicites. Les requêtes POST, PUT, DELETE ne le sont jamais. Les requêtes GET sans header de cache ou avec Cache-Control: no-store ne seront pas mises en cache non plus.

Le piège ? Si vous servez vos assets sans versioning (ex: /main.js au lieu de /main.v12345.js), Google peut rendre une page avec une version obsolète de votre code pendant plusieurs jours. Vous déployez un fix critique sur votre UI, mais le bot continue de voir l'ancienne version jusqu'à expiration du cache.

Que se passe-t-il si une ressource a expiré ou n'est pas cacheable ?

Si le cache expire (dépassement de max-age ou Expires), Google re-télécharge la ressource lors du prochain crawl+rendu. Même logique si la ressource n'était pas cacheable dès le départ : chaque rendu nécessitera une nouvelle requête HTTP.

C'est là que les sites avec Cache-Control: no-cache ou des TTL très courts gagnent en fraîcheur mais perdent en performance côté Googlebot. Le bot fera plus de requêtes, ce qui peut ralentir le rendu et augmenter la latence perçue.

• Google privilégie le cache pour la cohérence : un même rendu produira les mêmes résultats si les ressources sont identiques
• Les ressources GET avec headers de cache seront réutilisées pendant toute la durée du cache
• Si une ressource expire ou n'est pas cacheable, elle sera récupérée à nouveau lors du prochain rendu
• Le versioning d'assets (/main.v123.js) contourne ce problème en forçant un nouveau nom de fichier à chaque déploiement
• Les sites à déploiement continu doivent gérer ce décalage entre la version servie aux users et celle vue par Googlebot

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, et c'est même documenté depuis longtemps dans les best practices de Google. On observe régulièrement des cas où le rendu Mobile-Friendly Test ou la Search Console affichent un DOM différent de celui en production, justement à cause du cache.

Le problème se pose surtout pour les sites qui déploient plusieurs fois par jour sans versioning. Si vous poussez une mise à jour de votre CSS ou JS en prod, Google peut continuer à rendre avec l'ancienne version pendant 24-48h selon vos headers. Résultat : des snapshots incohérents, des tests de rendu qui ne reflètent pas la réalité.

Quelles nuances faut-il apporter à cette affirmation ?

Google ne précise pas explicitement la durée maximale de cache qu'il respecte. On sait qu'il respecte les headers HTTP standards, mais observe-t-on des plafonds internes ? [A vérifier] sur des TTL supérieurs à 30 jours.

Autre angle mort : que se passe-t-il en cas de variation de Vary header (ex: Vary: User-Agent) ? Google utilise-t-il un cache partagé ou dédié au bot mobile vs desktop ? La déclaration reste floue sur ces points. Les tests terrain suggèrent un cache partagé, mais rien d'officiel.

Dans quels cas cette règle ne s'applique-t-elle pas ou pose-t-elle problème ?

Si vous utilisez des Service Workers côté client pour gérer le cache, Google n'en tient pas compte lors du rendu. Le bot ne joue pas les Service Workers de la même manière qu'un navigateur classique. Votre stratégie de cache offline n'impacte donc pas le rendu Googlebot.

Les sites qui font du Server-Side Rendering (SSR) avec du HTML généré dynamiquement peuvent aussi se retrouver piégés. Si le HTML initial est servi sans cache mais que les assets JS/CSS le sont avec un long TTL, vous aurez un mix version fraîche (HTML) + version obsolète (assets). Le rendu peut exploser visuellement.

Que faut-il faire concrètement pour contrôler le cache et éviter les décalages ?

La solution la plus robuste : versioning des assets via hash ou timestamp dans le nom de fichier. Votre build génère /main.a3f2d1c.js au lieu de /main.js. Chaque déploiement crée un nouveau fichier, donc Google ne peut pas servir une version obsolète depuis le cache.

Si vous ne pouvez pas versionner (legacy, contraintes techniques), raccourcissez les TTL de cache à 1-2h maximum sur les assets critiques pour le rendu. Oui, ça augmente les requêtes HTTP côté Googlebot, mais ça réduit le risque de décalage. Utilisez Cache-Control: public, max-age=3600 plutôt qu'un max-age=604800.

Quelles erreurs éviter absolument ?

Ne servez jamais vos assets JS/CSS critiques avec Cache-Control: immutable si vous n'utilisez pas de versioning. Immutable dit au navigateur (et à Google) de ne jamais revalider, même avec F5. Si vous modifiez le fichier sans changer son URL, personne ne verra la mise à jour.

Évitez aussi les cache busters en query string (/main.js?v=123). Google peut ignorer ou normaliser les query strings, surtout si elles ressemblent à des paramètres de tracking. Préférez le hash dans le nom de fichier.

Comment vérifier que mon site est correctement configuré ?

Utilisez l'outil d'inspection d'URL dans la Search Console et comparez le rendu avec votre version prod. Si vous venez de déployer, attendez 24-48h puis re-testez. Un décalage persistant signale un problème de cache.

Vérifiez vos headers HTTP avec curl ou les DevTools : Cache-Control, ETag, Last-Modified. Si vos assets critiques affichent un max-age supérieur à 86400 (24h) sans versioning, vous êtes en zone de risque. Auditez aussi les CDN settings : certains CDN surchargent vos headers avec leurs propres règles de cache.

• Implémenter le versioning d'assets (hash dans le nom de fichier) sur tous les JS/CSS critiques pour le rendu
• Limiter les TTL de cache à 1-2h maximum si le versioning est impossible
• Bannir Cache-Control: immutable sans versioning
• Éviter les cache busters en query string, préférer le hash dans l'URL
• Tester le rendu dans la Search Console après chaque déploiement majeur
• Auditer les headers HTTP de vos assets avec curl ou DevTools