Proxy de préchargement privé dans Chrome

Katie Hempenius
Katie Hempenius
Kenji Baheux
Kenji Baheux
Michael Buettner
Michael Buettner

Accélérer le Largest Contentful Paint (LCP) grâce au préchargement intersites.

À partir de Chrome 103 pour Android, Chrome déploie progressivement une fonctionnalité de proxy de préchargement privé afin d'accélérer de 30% à la médiane les navigations sortantes depuis la recherche Google et d'autres sites Web participants. Cette fonctionnalité de proxy de préchargement privé permet le préchargement du contenu multi-origine sans exposer les informations de l'utilisateur au site Web de destination tant que celui-ci n'y a pas navigué.

Poursuivez votre lecture pour découvrir comment cette fonctionnalité fonctionne et comment elle peut améliorer considérablement les performances de vos sites Largest Contentful Paint (LCP), ou comment les sites Web référents peuvent aider leurs utilisateurs à atteindre leurs objectifs en accélérant les navigations entre les sites.

Fonctionnement du proxy de préchargement privé

Canal de communication sécurisé

Cette fonctionnalité utilise un proxy CONNECT pour établir un canal de communication sécurisé entre Chrome et le serveur hébergeant le contenu à précharger. Ce canal de communication sécurisé empêche le proxy d'inspecter les transferts de données. Il est à noter que même si le proxy de préchargement privé voit nécessairement le nom d'hôte pour établir un canal de communication sécurisé, il ne voit pas les URL complètes ni les ressources elles-mêmes.

<ph type="x-smartling-placeholder">
</ph> Animation montrant le flux de données via le proxy.
Le préchargement des sites Web via un proxy CONNECT empêche la fuite d'informations utilisateur.

De plus, le canal de communication sécurisé étant chiffré de bout en bout, les intermédiaires ne peuvent ni observer les noms d'hôte, ni le contenu des sites préchargés. Enfin, le proxy empêche intrinsèquement le serveur de destination de voir l'adresse IP de l'utilisateur.

Empêcher l'identification des utilisateurs

Au-delà des aspects réseau détaillés précédemment, nous devons également empêcher les serveurs d'identifier un utilisateur au moment du préchargement, par le biais d'informations précédemment stockées sur leur appareil. C'est pourquoi Chrome limite actuellement l'utilisation du proxy de préchargement privé aux sites Web pour lesquels l'utilisateur ne dispose pas de cookies ni d'aucun autre État local. Voici les restrictions qui s'appliquent aux requêtes de préchargement effectuées via le proxy de préchargement privé:

  • Cookies:les demandes de préchargement ne sont pas autorisées à transférer des cookies.
    • S'il existe un cookie pour une ressource, Chrome effectue une extraction sans identifiant, mais n'utilise pas la réponse (voir la section Mise en cache ultérieurement).
    • Bien que les réponses à une requête de préchargement puissent inclure des cookies, ces cookies ne seront enregistrés que si l'utilisateur accède à la page préchargée.
  • Empreinte digitale:les autres surfaces pouvant être utilisées pour le fingerprinting sont également ajustées. Par exemple, l'en-tête User-Agent envoyé par le proxy de préchargement ne contient que des informations limitées.

À l'avenir, nous espérons étendre le proxy de préchargement privé aux liens avec les cookies ou l'état local, tout en conservant les mêmes caractéristiques de confidentialité. Pour en savoir plus, consultez la section Étapes suivantes.

Mise en cache

Chrome précharge les ressources même si elles se trouvent déjà dans le cache, mais elles ne contiendront pas d'en-têtes conditionnels tels que ETag ou If-Modified-Since (qui contiennent des valeurs définies par le serveur qui pourraient être utilisées pour le suivi même sans cookies). Ce préchargement vise à empêcher la fuite de l'état du cache d'un client sur le site Web préchargé. De plus, Chrome ne valide une ressource préchargée dans le cache que si l'utilisateur décide d'accéder au site Web préchargé.

Premiers pas avec le proxy de préchargement privé

Pour les propriétaires de sites Web

Aucune action n'est requise de la part des propriétaires de sites Web pour commencer à bénéficier d'un proxy de préchargement privé sur les liens pour lesquels l'utilisateur n'a pas de cookies ni d'état local. D'après nos tests, il s'agit d'une opportunité intéressante pour la plupart des sites Web. En outre, il est toujours judicieux d'impressionner les nouveaux visiteurs ou les visiteurs occasionnels grâce à une expérience de chargement ultrarapide. D'après nos tests précédents, nous avons constaté qu'elle était 20 à 30 % plus rapide pour les navigations préchargées.

À l'avenir, nous espérons étendre cette fonctionnalité aux liens vers les cookies ou l'état local tout en préservant ses caractéristiques de confidentialité. Le problème avec les cookies, c'est qu'ils peuvent être utilisés pour modifier l'expérience utilisateur de façon difficile à prévoir. Les propriétaires de sites Web devront donc très probablement activer ou modifier leur site pour bénéficier du proxy de préchargement privé pour les liens contenant des cookies.

Concrètement, alors que les requêtes de préchargement resteront sans identifiant, la page Web aura accès aux cookies et à d'autres états locaux lorsque l'utilisateur y accédera. Les développeurs peuvent en profiter pour réintégrer la personnalisation et les modifications en fonction des cookies ou de l'état local. Les développeurs peuvent également souhaiter déclarer que certaines ressources sont parfaitement adaptées au préchargement et à l'utilisation telles quelles, sans cookies (c'est-à-dire les ressources qui ne dépendent d'aucun cookie). Consultez la section Étapes suivantes pour en savoir plus et élaborer notre plan d'action.

Contenu ou services géodépendants

Si votre site Web se comporte différemment (contenu différent ou accès sélectif, par exemple) selon les marchés en fonction de l'adresse IP de l'utilisateur, vous vous demandez peut-être comment gérer les requêtes de préchargement du proxy de préchargement privé. Il est important de savoir que le proxy de préchargement privé est alimenté par plusieurs serveurs répartis dans le monde entier et que l'adresse IP du proxy se géolocalise dans le pays à partir duquel l'utilisateur a initié le préchargement.

En gardant cela à l'esprit, voici ce que nous recommandons:

  1. Identifiez les requêtes de préchargement du proxy de préchargement privé grâce à la présence d'un en-tête HTTP Sec-Purpose: Prefetch; anonymous-client-ip.
  2. Recherchez la géolocalisation du proxy de préchargement privé qui a émis la requête via son adresse IP. Consultez cette ressource pour obtenir la liste à jour des zones géographiques déployées et des adresses IP correspondantes.
  3. Diffusez les ressources en fonction du marché associé à cette géolocalisation spécifique.

Contrôle du trafic

D'après nos tests précédents, nous savons que cette fonctionnalité entraîne généralement moins de 2% de demandes supplémentaires pour les ressources principales (par exemple, des documents HTML). Cela dit, si vous faites preuve de prudence, vous pouvez utiliser le champ de fraction des conseils de trafic pour contrôler la quantité de trafic que le proxy de préchargement privé doit laisser passer. Vous pouvez commencer par une petite fraction, par exemple 0,3 (soit 30%), puis l'augmenter progressivement jusqu'à 1,0 (c'est-à-dire 100%) en ajoutant le code JSON suivant à un fichier /.well-known/traffic-advice, qui doit être diffusé avec le type MIME application/trafficadvice+json:

[{
  "user_agent": "prefetch-proxy",
  "fraction": 0.3
}]

Le champ fraction est une valeur flottante comprise entre 0.0 (aucun préchargement) et 1.0 (100% des requêtes de préchargement aboutissent).

Il est également possible de désactiver complètement cette fonctionnalité avec la configuration suivante:

[{
  "user_agent": "prefetch-proxy",
  "disallow": true
}]

Le fichier /.well-known/traffic-advice est récupéré par le proxy, et non par le client, et mis en cache au niveau du proxy conformément à la sémantique habituelle du cache HTTP. Pour plus de flexibilité, par exemple lors d'un pic soudain d'accès intensif, vous pouvez refuser temporairement les requêtes de préchargement (Sec-Purpose: prefetch;anonymous-client-ip) associées à un code d'état 503 et définir l'en-tête Cache-Control: no-store sur la réponse. Vous pouvez également ajouter l'en-tête Retry-After pour indiquer à Chrome le temps d'attente avant de relancer les requêtes de préchargement.

Pour les propriétaires de sites Web de provenance

Si vous gérez un site Web comportant de nombreux liens vers d'autres sites Web, la fonctionnalité de proxy de préchargement privé peut vous intéresser pour accélérer ces navigations multi-origines. Vous devez ajouter des règles de spéculation à vos pages pour que Chrome sache quelle page devrait être préchargée via le proxy de préchargement privé. Voici un exemple simple:

<script type="speculationrules">
{
  "prefetch": [
    "source": "list",
    "urls": ["https://example.com/index.html"],
    "requires": ["anonymous-client-ip-when-cross-origin"]
  ]
}
</script>

Étape suivante

Ce lancement n'est qu'une première étape. Nous espérons la développer et l'améliorer en fonction des centres d'intérêt et des commentaires de la communauté. Par exemple, nous aimerions connaître votre avis sur la façon d'étendre les liens avec les cookies et l'état local de manière à réduire les frictions pour les développeurs, ou sur la façon de rendre cette fonctionnalité plus utile pour les sites Web de provenance.

Lire la suite