En général, la mise en cache peut améliorer les performances en stockant des données afin que les futures requêtes pour les mêmes données soient traitées plus rapidement. Par exemple, une ressource mise en cache du réseau peut éviter un aller-retour vers le serveur. Un résultat de calcul mis en cache peut omettre le temps nécessaire pour effectuer le même calcul.
Dans Chrome, le mécanisme de cache est utilisé de différentes manières, et le cache HTTP en est un exemple.
Fonctionnement actuel du cache HTTP de Chrome
À partir de la version 85, Chrome met en cache les ressources extraites du réseau, en utilisant leurs URL de ressources respectives comme clé de cache. (Une clé de cache permet d'identifier une ressource mise en cache.)
L'exemple suivant illustre comment une seule image est mise en cache et traitée dans trois contextes différents:
https://x.example/doge.png }
Un utilisateur consulte une page (https://a.example) qui demande une image (https://x.example/doge.png). L'image est demandée au réseau et mise en cache à l'aide de https://x.example/doge.png comme clé.
https://x.example/doge.png }
Le même utilisateur accède à une autre page (https://b.example), qui demande la même image (https://x.example/doge.png). Le navigateur vérifie son cache HTTP pour voir s'il a déjà mis en cache cette ressource, en utilisant l'URL de l'image comme clé. Le navigateur trouve une correspondance dans son cache. Il utilise donc la version mise en cache de la ressource.
https://x.example/doge.png }
Peu importe que l'image soit chargée depuis un iFrame. Si l'utilisateur visite un autre site Web (https://c.example) avec un iFrame (https://d.example) et que l'iFrame demande la même image (https://x.example/doge.png), le navigateur peut toujours charger l'image à partir de son cache, car la clé de cache est la même pour toutes les pages.
Ce mécanisme fonctionne bien depuis longtemps du point de vue des performances. Toutefois, le temps qu'un site Web met à répondre aux requêtes HTTP peut révéler que le navigateur a accédé à la même ressource par le passé, ce qui le rend vulnérable aux attaques de sécurité et de confidentialité, comme les suivantes:
- Détecter si un utilisateur a consulté un site spécifique: un pirate informatique peut détecter l'historique de navigation d'un utilisateur en vérifiant si le cache contient une ressource pouvant être spécifique à un site ou à une cohorte de sites particuliers.
- Attaque de recherche intersites : un pirate informatique peut détecter si une chaîne arbitraire figure dans les résultats de recherche de l'utilisateur en vérifiant si une image "Aucun résultat de recherche" utilisée par un site Web particulier se trouve dans le cache du navigateur.
- Suivi intersites: le cache peut être utilisé pour stocker des identifiants ressemblant à des cookies en tant que mécanisme de suivi intersites.
Pour réduire ces risques, Chrome partitionnera son cache HTTP à partir de Chrome 86.
Quel est l'impact de la partitionnement du cache sur le cache HTTP de Chrome ?
Le partitionnement du cache permettra d'associer les ressources en cache à de nouvelles "Network Isolation Key" (clés d'isolation réseau) en plus de l'URL de ces ressources. La Network Isolation Key se compose du site de premier niveau et du site du frame actuel.
Revoyez l'exemple précédent pour voir comment la partitionnement du cache fonctionne dans différents contextes:
https://a.example, https://a.example, https://x.example/doge.png }
Un utilisateur accède à une page (https://a.example) qui demande une image (https://x.example/doge.png). Dans ce cas, l'image est demandée au réseau et mise en cache à l'aide d'un tuple composé de https://a.example (le site de niveau supérieur), https://a.example (le site du cadre actuel) et https://x.example/doge.png (l'URL de la ressource) comme clé. (Notez que lorsque la requête de ressource provient du frame racine, le site racine et le site du frame actuel dans la clé d'isolation réseau sont identiques.)
https://b.example, https://b.example, https://x.example/doge.png }
Le même utilisateur accède à une autre page (https://b.example) qui demande la même image (https://x.example/doge.png). Bien que la même image ait été chargée dans l'exemple précédent, comme la clé ne correspond pas, il n'y aura pas de cache hit.
L'image est demandée au réseau et mise en cache à l'aide d'un tuple composé de https://b.example, https://b.example et https://x.example/doge.png comme clé.
https://a.example, https://a.example, https://x.example/doge.png }
L'utilisateur revient maintenant sur https://a.example, mais cette fois, l'image (https://x.example/doge.png) est intégrée dans un iframe. Dans ce cas, la clé est un tuple contenant https://a.example, https://a.example et https://x.example/doge.png, et un succès de cache se produit. (Notez que lorsque le site de premier niveau et l'iFrame sont le même site, la ressource mise en cache avec le frame de premier niveau peut être utilisée.
https://a.example, https://c.example, https://x.example/doge.png }
L'utilisateur est de retour sur https://a.example, mais cette fois, l'image est hébergée dans un iframe à partir de https://c.example.
Dans ce cas, l'image est téléchargée à partir du réseau, car aucune ressource du cache ne correspond à la clé composée de https://a.example, https://c.example et https://x.example/doge.png.
https://a.example, https://c.example, https://x.example/doge.png }
Que se passe-t-il si le domaine contient un sous-domaine ou un numéro de port ? L'utilisateur accède à https://subdomain.a.example, qui intègre un iframe (https://c.example:8080), qui demande l'image.
Étant donné que la clé est créée en fonction de "scheme://eTLD+1", les sous-domaines et les numéros de port sont ignorés. Un succès de cache se produit donc.
https://a.example, https://c.example, https://x.example/doge.png }
Que se passe-t-il si l'iFrame est imbriquée plusieurs fois ? L'utilisateur accède à https://a.example, qui intègre un iFrame (https://b.example), qui intègre un autre iFrame (https://c.example), qui demande finalement l'image.
Étant donné que la clé est extraite du frame supérieur (https://a.example) et du frame immédiat qui charge la ressource (https://c.example), un succès de cache se produit.
Questions fréquentes
Est-elle déjà activée dans Chrome ? Comment vérifier ?
Cette fonctionnalité sera déployée d'ici la fin de l'année 2020. Pour vérifier si votre instance Chrome est déjà compatible:
- Ouvrez
chrome://net-export/, puis appuyez sur Start Logging to Disk (Commencer la journalisation sur disque). - Spécifiez l'emplacement où enregistrer le fichier journal sur votre ordinateur.
- Parcourez le Web dans Chrome pendant une minute.
- Revenez à
chrome://net-export/, puis appuyez sur Stop Logging (Arrêter la journalisation). - Accédez à
https://netlog-viewer.appspot.com/#import. - Appuyez sur Sélectionner un fichier, puis transmettez le fichier journal que vous avez enregistré.
La sortie du fichier journal s'affiche.
Sur la même page, recherchez SplitCacheByNetworkIsolationKey. Si elle est suivie de Experiment_[****], le partitionnement du cache HTTP est activé dans Chrome. Si elle est suivie de Control_[****] ou de Default_[****], elle n'est pas activée.
Comment puis-je tester le partitionnement du cache HTTP dans Chrome ?
Pour tester le partitionnement du cache HTTP dans Chrome, vous devez lancer Chrome avec un indicateur de ligne de commande: --enable-features=SplitCacheByNetworkIsolationKey. Suivez les instructions de la section Exécuter Chromium avec des indicateurs pour savoir comment lancer Chrome avec un indicateur de ligne de commande sur votre plate-forme.
En tant que développeur Web, dois-je prendre des mesures en réponse à ce changement ?
Il ne s'agit pas d'un changement de rupture, mais il peut imposer des considérations de performances pour certains services Web.
Par exemple, ceux qui diffusent de grands volumes de ressources hautement enregistrables sur de nombreux sites (comme les polices et les scripts populaires) peuvent voir leur trafic augmenter. De plus, les personnes qui consomment ces services peuvent être plus dépendantes d'eux.
(Une proposition visant à activer les bibliothèques partagées de manière respectueuse de la confidentialité, appelée Web Shared Libraries (vidéo de présentation), est en cours d'examen.)
Quel est l'impact de ce changement de comportement ?
Le taux global de manque de cache augmente d'environ 3,6%, les modifications apportées à la FCP (First Contentful Paint) sont modestes (environ 0,3%) et la fraction globale d'octets chargés à partir du réseau augmente d'environ 4%. Pour en savoir plus sur l'impact sur les performances, consultez la présentation du partitionnement du cache HTTP.
Est-ce normalisé ? Le comportement des autres navigateurs est-il différent ?
Les "partitions de cache HTTP" sont standardisées dans la spécification de récupération, mais les navigateurs se comportent différemment:
- Chrome: utilise le schéma de premier niveau scheme://eTLD+1 et le schéma de frame scheme://eTLD+1
- Safari: utilise un domaine de premier niveau eTLD+1
- Firefox: prévoit d'implémenter avec le schéma de premier niveau scheme://eTLD+1 et envisage d'inclure une deuxième clé comme Chrome
Comment la récupération des travailleurs est-elle traitée ?
Les nœuds de calcul dédiés utilisent la même clé que leur frame actuel. Les travailleurs de service et les travailleurs partagés sont plus complexes, car ils peuvent être partagés entre plusieurs sites de niveau supérieur. La solution à ce problème est actuellement en cours de discussion.