Pourquoi Google insiste-t-il sur les en-têtes de cache pour JavaScript ?

Que signifie « en-têtes de cache appropriés » pour JavaScript ?

Un en-tête de cache comme cache-control indique au navigateur combien de temps il peut stocker localement un fichier JavaScript sans redemander au serveur s'il a changé. Sans directive claire, le navigateur fait des allers-retours inutiles, ralentissant l'affichage de la page.

Google mentionne explicitement l'ajout d'un numéro de version dans l'URL (ex: script.js?v=1.2.3 ou script-1.2.3.js). Ce mécanisme permet de cacher agressivement les fichiers tout en forçant une mise à jour immédiate lors d'un changement réel du code.

Pourquoi cette recommandation impacte-t-elle le SEO ?

Les Core Web Vitals, notamment le LCP et le TBT, sont directement influencés par la vitesse de chargement des ressources JavaScript. Un fichier mis en cache localement se charge instantanément, améliorant l'expérience utilisateur et les signaux de performance envoyés à Google.

Côté crawl, Googlebot exécute JavaScript pour indexer certaines pages. Des fichiers JS mis en cache correctement réduisent le temps de traitement par page, ce qui peut indirectement préserver le crawl budget sur les gros sites.

Quels en-têtes utiliser concrètement ?

L'en-tête cache-control: public, max-age=31536000, immutable est idéal pour un fichier versionné dans l'URL. Le navigateur le conserve un an sans vérification. Si le fichier change, l'URL change, invalidant automatiquement le cache.

Sans versioning dans l'URL, on utilisera plutôt cache-control: public, max-age=3600, must-revalidate pour forcer une vérification après une heure. Moins performant, mais nécessaire si on ne maîtrise pas le versioning.

• cache-control est l'en-tête moderne à privilégier (remplace expires)
• Combiner versioning d'URL + cache long = stratégie optimale
• Attention aux CDN qui peuvent ajouter leurs propres directives de cache
• Les fichiers tiers (Google Analytics, etc.) ont généralement leurs propres en-têtes — vérifiez-les aussi

Cette directive est-elle vraiment appliquée par Googlebot ?

Soyons honnêtes : Googlebot ne respecte pas forcément les mêmes règles de cache qu'un navigateur classique. Google peut recrawler un fichier JS même si l'en-tête indique qu'il est valide pendant un an. Le bot a ses propres heuristiques pour décider quand refetch une ressource.

Ce que cette recommandation vise avant tout, c'est l'expérience utilisateur réelle. Les métriques CWV sont collectées via les navigateurs des vrais visiteurs (CrUX), pas via Googlebot. Un JavaScript bien caché améliore le LCP et le TBT mesurés dans le terrain, ce qui influence le classement.

Dans quels cas cette règle devient-elle problématique ?

Le versioning dans l'URL nécessite un système de build robuste. Si votre CMS ou votre pipeline de déploiement ne gère pas automatiquement les noms de fichiers versionnés, vous risquez des erreurs : ancienne version en cache alors que le code a changé, ou pire, URL cassée après une mise à jour.

Sur des sites à fort trafic avec déploiements fréquents, un cache trop agressif sans versioning peut créer un décalage entre utilisateurs : certains voient l'ancienne interface, d'autres la nouvelle. Ça complique le debugging et les tests A/B. [À vérifier] : Google n'indique pas comment gérer la transition entre deux versions d'un même fichier JS critique.

Quelle est la marge d'erreur acceptable ?

Tous les fichiers JS ne méritent pas le même traitement. Un petit script inline de 2 Ko n'a aucun impact si mal caché. En revanche, un bundle React de 300 Ko chargé en bloquant : là, chaque milliseconde compte.

Priorisez les fichiers critiques pour le rendu initial. Les scripts analytics, chatbots ou widgets tiers sont moins sensibles — et d'ailleurs, vous ne contrôlez souvent pas leurs en-têtes. Concentrez vos efforts sur ce qui pèse réellement dans vos métriques PageSpeed.

Que faut-il faire concrètement pour se conformer ?

Première étape : auditer vos fichiers JavaScript. Utilisez les DevTools de Chrome (onglet Network) ou un crawler comme Screaming Frog pour lister tous les JS chargés sur vos pages clés. Notez ceux qui n'ont pas d'en-tête cache-control ou qui ont un max-age trop court (< 1 semaine).

Ensuite, implémentez le versioning dans les URL. La plupart des bundlers modernes (Webpack, Vite, Parcel) le font automatiquement via un hash dans le nom du fichier. Si vous êtes sur WordPress, des plugins comme Autoptimize ou WP Rocket gèrent cette logique. Vérifiez que le numéro de version change bien à chaque modification du code.

Configurez vos en-têtes HTTP côté serveur. Sur Apache : ajoutez dans .htaccess des règles FilesMatch pour les .js. Sur Nginx : utilisez location ~* \.js$ avec add_header Cache-Control. Sur un CDN, configurez les Cache Rules pour respecter les en-têtes origine ou forcer vos propres directives.

Comment vérifier que c'est correctement implémenté ?

Testez en navigation privée pour éviter les faux positifs liés à votre propre cache navigateur. Rechargez la page deux fois : au second chargement, dans l'onglet Network des DevTools, les fichiers JS doivent afficher « (disk cache) » ou « (memory cache) » au lieu d'un nouveau téléchargement.

Utilisez PageSpeed Insights ou GTmetrix : cherchez l'avertissement « Serve static assets with an efficient cache policy ». S'il mentionne vos fichiers JS, c'est que vos en-têtes sont insuffisants. Corrigez jusqu'à ce que l'alerte disparaisse.

Testez aussi la désinvalidation du cache. Modifiez légèrement un fichier JS, redéployez : l'URL doit changer. Rechargez votre page : le nouveau fichier doit être téléchargé immédiatement, pas servi depuis l'ancien cache. Si ce n'est pas le cas, votre versioning ne fonctionne pas.

• Identifier tous les fichiers JS critiques (ceux qui bloquent le rendu initial)
• Configurer cache-control avec max-age ≥ 31536000 pour les fichiers versionnés
• Ajouter un hash ou numéro de version dans chaque URL de fichier JS
• Vérifier que le CDN ou le reverse proxy respecte vos directives cache
• Tester en navigation privée que les fichiers sont bien mis en cache au second chargement
• Automatiser le versioning dans votre pipeline de build/déploiement
• Surveiller PageSpeed Insights pour s'assurer que l'alerte « cache policy » disparaît