Le cache JavaScript de Google fonctionne-t-il vraiment par origine et non par domaine ?

Quelle est la différence technique entre cache par origine et cache par domaine ?

Une origine combine trois éléments : le protocole (https), le domaine (exemple.com) et le port (443 par défaut). Deux URLs avec des sous-domaines différents constituent donc deux origines distinctes. Ainsi, https://www.exemple.com et https://cdn.exemple.com représentent deux origines séparées du point de vue de la sécurité web et — selon Martin Splitt — du cache Google.

Cette distinction n'est pas anodine. Beaucoup de SEO pensaient que Google pouvait partager un cache de ressources communes (React, jQuery, Bootstrap) entre sites différents utilisant le même CDN public. L'affirmation de Splitt ferme cette porte : chaque origine dispose de son propre espace de stockage pour les ressources JavaScript, CSS et autres assets. Pas de mutualisation, pas de raccourci.

Pourquoi cette architecture de cache impacte-t-elle le crawl et le rendu ?

Googlebot crawle les pages et télécharge les ressources nécessaires au rendu pour comprendre le contenu généré en JavaScript. Si votre site charge du JS depuis plusieurs origines différentes, Google va télécharger et mettre en cache ces ressources séparément pour chaque origine. Pas de réutilisation même si le fichier est strictement identique.

Cela signifie que disperser vos ressources sur plusieurs sous-domaines ou CDN peut augmenter le volume de requêtes et ralentir le processus de rendu côté Googlebot. Pour un site avec un crawl budget limité, chaque requête supplémentaire compte. Plus vous fragmentez vos origines, plus vous consommez de bande passante et de temps de traitement.

Est-ce que cette logique s'applique aussi aux ressources tierces courantes ?

Oui, et c'est là que ça coince. Imaginons que votre site charge jQuery depuis cdnjs.cloudflare.com. Des millions de sites font pareil. On pourrait penser que Google garde cette bibliothèque en cache et la réutilise d'un site à l'autre. Faux. Selon Splitt, chaque origine (ici cdnjs.cloudflare.com pour votre site, mais isolée du cache d'autres sites) a son propre cache.

Cela remet en question l'idée reçue selon laquelle utiliser un CDN public populaire accélérerait le traitement par Google. Le bénéfice existe pour vos visiteurs humains dont les navigateurs partagent effectivement le cache entre sites, mais pas pour Googlebot. Cette nuance change la donne sur l'arbitrage self-hosting vs CDN tiers.

• Origine = protocole + domaine + port, pas seulement le domaine racine
• Pas de partage de cache entre sites différents même pour des ressources identiques
• Chaque sous-domaine constitue une origine distincte avec son propre cache
• La dispersion des ressources sur plusieurs origines peut augmenter le temps de rendu Googlebot
• L'utilisation de CDN publics n'accélère pas le traitement côté Google contrairement aux navigateurs classiques

Cette déclaration est-elle cohérente avec les observations terrain ?

Difficile de répondre avec certitude. Nous n'avons pas accès aux logs internes de Google pour vérifier si le comportement de cache correspond exactement à ce que Splitt décrit. Les tests empiriques sur le temps de rendu montrent des variations, mais isoler la variable « cache par origine » reste complexe dans un système aussi opaque.

Certains SEO rapportent que regrouper les ressources sur une seule origine améliore effectivement la vitesse de rendu perçue dans Search Console. D'autres ne constatent aucune différence mesurable. [A vérifier] avec des tests A/B rigoureux sur des sites à fort volume pour obtenir des données statistiquement significatives. En attendant, on navigue entre théorie officielle et empirisme.

Pourquoi Google n'adopterait-il pas un cache partagé pour les ressources communes ?

Soyons honnêtes : techniquement, Google pourrait tout à fait implémenter un cache global pour des bibliothèques ultra-répandues comme React ou jQuery. Les navigateurs le font depuis des années. Pourquoi Google s'en prive-t-il ? Plusieurs hypothèses — et c'est là que la déclaration de Splitt manque de substance.

Première hypothèse : la sécurité et l'isolation. Partager un cache entre origines peut créer des vecteurs d'attaque par timing ou par pollution de cache. Google privilégie peut-être une architecture hermétique. Deuxième hypothèse : la simplicité technique. Maintenir un cache partagé à l'échelle du web exige une infrastructure complexe. Troisième hypothèse, plus cynique : pas d'incitation commerciale forte pour Google à optimiser le crawl de ressources tierces.

Dans quels cas cette règle pourrait-elle souffrir d'exceptions ?

Splitt parle de « système de cache » sans préciser si cette logique s'applique uniformément à tous les types de ressources. Les polices web, par exemple, suivent-elles le même modèle ? Et les images hébergées sur des CDN tiers ? La déclaration reste vague sur le périmètre exact.

Par ailleurs, Google a des mécanismes d'optimisation internes (resource hints, preload, HTTP/2 push) qui peuvent court-circuiter ou compléter le cache classique. Il n'est pas impossible que certaines ressources critiques bénéficient d'un traitement préférentiel non documenté. Sans transparence complète, on ne peut qu'émettre des hypothèses prudentes.

Que faut-il faire concrètement avec cette information ?

Auditer la dispersion de vos ressources constitue la première étape. Listez toutes les origines depuis lesquelles votre site charge du JavaScript, du CSS, des polices, des images. Si vous comptez plus de 3-4 origines différentes pour des ressources critiques au rendu, vous pourriez optimiser.

Ensuite, évaluez le rapport coût/bénéfice. Regrouper tout sur une seule origine peut simplifier le cache Googlebot, mais si votre CDN tiers offre une latence bien inférieure à votre serveur principal, le gain de cache ne compensera pas la perte de vitesse réseau. Testez, mesurez, comparez. Search Console et les outils de rendu mobile vous donneront des indices sur le temps de traitement réel.

Quelles erreurs éviter dans la réorganisation des ressources ?

Ne tombez pas dans le piège du self-hosting aveugle. Héberger jQuery ou React sur votre propre serveur pour « consolider l'origine » n'a de sens que si votre infrastructure est performante, avec HTTP/2, compression Brotli, et une bande passante confortable. Sinon, vous dégraderez les performances pour vos utilisateurs humains sans gain réel côté Googlebot.

Autre erreur courante : multiplier les sous-domaines sans raison. Créer cdn1.exemple.com, cdn2.exemple.com, assets.exemple.com juste pour « équilibrer la charge » ou « faire pro » fragmente inutilement vos origines. Si vous utilisez un seul serveur derrière, cette dispersion n'apporte aucun bénéfice technique et complique le cache selon la logique de Splitt.

Comment vérifier que votre architecture est optimale pour le rendu Google ?

Utilisez l'outil Inspection d'URL dans Search Console et examinez le rapport de rendu. Google vous montre les ressources chargées et le temps nécessaire. Si vous voyez des délais anormalement longs pour des ressources hébergées sur des origines secondaires, c'est un signal.

Comparez également les performances avant/après une migration d'origine. Si vous centralisez vos JS critiques sur votre domaine principal, surveillez les métriques Core Web Vitals et le taux d'indexation des pages JavaScript-heavy. Une amélioration même légère peut valider l'hypothèse. En cas de dégradation, rollback immédiat et réévaluation de la stratégie.

• Auditer toutes les origines tierces utilisées pour les ressources critiques au rendu
• Consolider les ressources JavaScript et CSS sur un nombre minimal d'origines (idéalement 1-2 maximum)
• Vérifier que votre serveur principal supporte HTTP/2, compression Brotli et a une latence acceptable
• Éviter la multiplication de sous-domaines sans justification technique réelle
• Tester l'impact sur le rendu via Search Console Inspection d'URL avant et après modification
• Surveiller les Core Web Vitals et le taux d'indexation des pages JS pour valider les changements