Chrome va partitionner le cache : ce que votre stratégie de performance doit changer
Le partitionnement du cache dans Chrome limite les gains des ressources tierces. Impacts concrets et priorités pour préserver la performance web.
Le cache HTTP de Chrome est déjà partitionné : une ressource chargée sur un site ne peut généralement pas être réutilisée depuis le cache du navigateur lorsqu’un autre site demande la même URL. N’appuyez donc pas la performance sur l’idée qu’un visiteur a déjà téléchargé ailleurs votre bibliothèque JavaScript, votre police ou un tag tiers.
Cette évolution ne vide pas le cache de votre CDN. Elle limite le cache partagé dans le navigateur entre différents sites afin qu’un site ne puisse pas déduire les visites précédentes d’un utilisateur en observant l’état du cache.
Ce qui change pour les ressources tierces
Chrome a annoncé le partitionnement de son cache HTTP avec Chrome 86. Une entrée de cache est notamment associée au site de premier niveau qui a déclenché la requête, plutôt que d’être réutilisable universellement par toute origine demandant la même URL.
Ainsi, si https://cdn.exemple.net/ui.js est chargé sur site-a.fr, son téléchargement ne garantit pas un hit de cache lorsque la même URL est appelée depuis site-b.fr. La documentation de Chrome décrit ce mécanisme dans son article sur le partitionnement du cache HTTP.
Vos propres pages peuvent toujours réutiliser des ressources stables mises en cache. Une image, une feuille CSS ou un bundle JavaScript partagé entre des pages de www.votresite.fr reste utile si ses en-têtes HTTP le permettent.
Un CDN reste également utile : son cache en périphérie réduit le travail du serveur d’origine et améliore la distribution des fichiers. En revanche, une bibliothèque publique, une police externe, un tag marketing ou un widget ne doit plus être retenu pour un supposé cache navigateur déjà chaud sur d’autres sites.
Il n’est pas nécessaire de tout auto-héberger. Un tiers peut apporter une sécurité, des mises à jour automatiques ou un service difficile à opérer en interne, mais son choix doit reposer sur sa valeur fonctionnelle, son poids et son effet sur le rendu.
Mesurer avant d’optimiser
Dans Chrome DevTools, utilisez l’onglet Network avec un cache vide pour observer la taille transférée, la priorité, les dépendances et le moment où chaque fichier retarde le rendu. Testez aussi une navigation entre plusieurs pages de votre domaine afin de vérifier la réutilisation effective des ressources first-party.
- LCP : l’image héro, le CSS, les polices et le JavaScript critiques ne doivent pas attendre une cascade de tiers.
- INP : un script tiers exécuté trop tôt peut monopoliser le thread principal, même s’il ne bloque pas le premier rendu.
- CLS : le cache n’en est pas la cause directe, mais une police ou un composant chargé tardivement peut créer un décalage visible.
Complétez ces tests par des données réelles, avec la bibliothèque web-vitals ou votre solution de RUM. Elles reflètent la diversité des appareils, réseaux et parcours, contrairement à un navigateur de développement déjà rempli de cache.
Attention : l’API Resource Timing fournit des informations limitées pour une ressource cross-origin sans en-tête Timing-Allow-Origin. Demandez cet en-tête au fournisseur si vous devez attribuer précisément le coût d’un script ou d’une image tierce.
Privilégier le cache first-party et un chemin critique léger
Servez des fichiers versionnés, dont l’URL change lorsque le contenu change, et appliquez une longue durée de cache aux actifs immuables. Par exemple, Cache-Control: public, max-age=31536000, immutable convient à un fichier dont le nom contient un hash de contenu.
Pour le HTML, adoptez une politique de validation ou une durée de vie adaptée à votre fréquence de publication. Ce document référence les nouveaux actifs : le mettre en cache pendant un an n’a de sens que si votre architecture le prévoit.
Réduisez d’abord les dépendances sans valeur mesurable sur le parcours, puis différez les scripts non critiques. Chargez les widgets au consentement ou à l’interaction lorsque cela est pertinent, et évitez de placer un tag tiers sur le chemin de rendu initial.
Réservez preload aux ressources indispensables au rendu initial. Pour des navigations probables, les Speculation Rules peuvent être évaluées séparément, en surveillant le volume transféré.