Premiers pas avec les échanges signés dans la recherche Google

Les échanges signés (SXG) permettent à la recherche Google de précharger votre contenu tout en préservant la confidentialité de l'utilisateur. Dans la pratique, cela signifie que les résultats AMP et les résultats standards qui apparaissent dans la recherche Google peuvent précharger quelques ressources clés (telles que du code HTML, JavaScript, CSS, des images ou des polices) en respectant la confidentialité, si le site Web associé est compatible avec les échanges signés.

Lorsque l'utilisateur clique sur le résultat final, la page Web commence à s'afficher bien plus tôt, car les ressources clés sont déjà disponibles, ce qui optimise l'expérience utilisateur. Cela peut contribuer à améliorer le score LCP (Largest Contentful Paint) pour votre contenu. Même si la recherche Google ne considère pas l'utilisation des échanges signés comme un facteur de classement direct, un LCP plus faible peut influer sur le classement, car l'expérience sur la page fait partie des facteurs de classement.

Mettre en œuvre un échange signé

Pour implémenter un échange signé, suivez le guide détaillé de web.dev. Après leur implémentation, suivez ce guide sur la mesure et l'optimisation de l'amélioration des performances avec les échanges signés.

Pour les pages AMP, reportez-vous au guide détaillé disponible sur amp.dev.

Google utilise un cache d'échanges signés pour précharger votre contenu. Ceux-ci peuvent être diffusés plusieurs fois.

Pour vous assurer que le contenu à jour s'affiche dans la recherche Google, définissez les valeurs d'expiration des échanges signés correctement. En règle générale, assurez-vous que la date d'expiration est inférieure à ces deux dates :

  • Expiration du cache déterminée par vos en-têtes HTTP
  • Un jour après si le contenu est au format JavaScript ou intègre JavaScript (sinon, sept jours après)

Pour vous assurer que le contenu s'affiche correctement sur différents appareils, procédez comme suit :

  1. Migrez le contenu personnalisé, tel que les paniers d'achat, dans des éléments à chargement différé qui se trouvent en dehors de l'échange signé. Vous pouvez également ajouter l'en-tête signé Vary: Cookie. Les SXG avec cet en-tête ne seront visibles qu'auprès des visiteurs sans cookie pour votre site.
  2. Créez les pages à l'aide du Responsive Web Design. Vous pouvez également diffuser des pages pour ordinateur et pour mobile sur des URL distinctes ou annoter les pages pour indiquer qu'elles ne sont pas responsives à l'aide de la balise meta supported-media. Par exemple, dans l'élément <head> de la page, ajoutez la balise suivante : 
    <meta name=supported-media content="only screen and (max-width: 640px)">

Surveiller et déboguer un échange signé

Pour obtenir une liste des outils que vous pouvez utiliser pour déboguer un échange signé, consultez le guide concernant les outils SXG sur web.dev.

Si Googlebot ne parvient pas à analyser un échange signé, il peut explorer de nouveau l'URL sans application/signed-exchange;v=b3 dans l'en-tête Accept afin de récupérer la variante text/html. En cas d'erreur d'indexation des échanges signés, la recherche Google redirige vers l'URL d'origine, sans échange signé.

Pour les pages AMP, utilisez le rapport d'état AMP dans la Search Console pour identifier les erreurs SXG.

Déboguer le cache d'échanges signés Google

Pour déterminer si un échange signé respecte les conditions requises en matière de cache, utilisez l'extension Chrome SXG Validator.

Vous pouvez également interroger directement le cache d'échanges signés Google. Par exemple, si l'URL de l'échange signé est https://signed-exchange-testing.dev/sxgs/valid.html, formulez l'URL du cache correspondante :

https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid.html

L'algorithme permettant de calculer le sous-domaine et le suffixe du chemin de l'URL est identique à celui d'AMP Cache, alors que la chaîne infix /doc/-/ est différente.

Si la réponse correspond à un échange signé, cela signifie que la réponse du serveur d'origine respecte les conditions requises pour le cache d'échanges signés Google. Dans le cas contraire, elle inclut un en-tête HTTP indiquant la raison.

  • S'il existe un en-tête Warning, elle indique une erreur qui empêche l'échange signé de respecter les conditions requises en matière de cache.
  • S'il existe un en-tête Location, elle n'a pas encore été récupérée par le cache. Il ne s'agit pas d'une erreur au niveau de l'échange signé.

Quelle que soit la réponse, le cache met en file d'attente toute requête envoyée à l'URL d'origine pour obtenir une version mise à jour. Plusieurs facteurs déterminent l'échec ou le succès de cette requête et, le cas échéant, le moment où elle a lieu, y compris la vitesse d'exploration de Googlebot pour votre site.

Google ne met pas en cache les fichiers SXG pendant une durée plus longue que la valeur expires de la signature SXG ou que la durée de vie de l'en-tête non signé de la réponse SXG.

Pour les pages AMP, vous pouvez utiliser l'outil d'inspection d'URL pour déboguer les erreurs de mise en cache.

Rester informé

Abonnez-vous à la webpackaging-announceliste de diffusion pour recevoir une notification lors des modifications suivantes :

  • Modifications apportées au cache d'échanges signés Google (ajout ou suppression de fonctionnalités)
  • Modifications majeures apportées au package Web des outils SXG, au module SXG NGINX et à libsxg

Pour toute question concernant les échanges signés dans la recherche Google, consultez le site de la communauté d'aide Search Central.