Échanges signés (SXG)

Un SXG est un mécanisme de diffusion qui permet d'authentifier l'origine d'une ressource indépendamment de la manière dont elle a été diffusée.

Katie Hempenius
Katie Hempenius
X
Devin Mullins
Devin Mullins
X GitHub

Les échanges signés (SXG) sont un mécanisme de diffusion qui permet d'authentifier l'origine d'une ressource indépendamment de la manière dont elle a été diffusée. L'implémentation de SXG peut améliorer le Largest Contentful Paint (LCP) en activant le préchargement inter-origines respectueux de la confidentialité. De plus, ce découplage favorise divers cas d'utilisation, tels que les expériences Internet hors connexion et la diffusion à partir de caches tiers.

Cet article fournit une présentation complète de SXG : son fonctionnement, ses cas d'utilisation et ses outils.

Compatibilité du navigateur

Les navigateurs basés sur Chromium (à partir des versions Chrome 73, Edge 79 et Opera 64) sont compatibles avec les SXG.

Présentation

Dans son cas d'utilisation principal, SXG utilise un cache pour précharger et diffuser du contenu qui a été signé de manière cryptographique par l'origine. Cela permet d'accélérer les navigations inter-origines à partir des sites référents, tout en veillant à ce que les pages restent inchangées et attribuées correctement à leur origine. Toutes les informations potentiellement identifiantes sont masquées jusqu'à ce que l'utilisateur accède à un site, ce qui protège sa confidentialité. La recherche Google est l'un des premiers à adopter les fonctionnalités de préchargement SXG. Pour les sites qui reçoivent une grande partie de leur trafic de la recherche Google, SXG peut être un outil important pour accélérer le chargement des pages pour les utilisateurs. Nous espérons que cet impact s'étendra à d'autres sites référents au fil du temps.

Fonctionnement

Un site signe une paire requête/réponse (un "échange HTTP") de manière à permettre au navigateur de vérifier l'origine et l'intégrité du contenu, indépendamment du mode de distribution du contenu. Par conséquent, le navigateur peut afficher l'URL du site d'origine dans la barre d'adresse plutôt que l'URL du serveur qui a diffusé le contenu.

Schéma expliquant le fonctionnement des échanges signés. Navigateur communiquant avec le cache, qui communique avec le site de destination

Historiquement, le seul moyen pour un site d'utiliser un tiers pour distribuer son contenu tout en conservant l'attribution était de partager ses certificats SSL avec le distributeur. Cela présente des inconvénients en termes de sécurité. De plus, cela est loin de rendre le contenu vraiment portable.

Format SXG

Un échange signé est encapsulé dans un fichier encodé en binaire qui comporte deux composants principaux: un échange HTTP et une signature qui couvre l'échange. L'échange HTTP se compose d'une URL de requête, d'informations de négociation de contenu et d'une réponse HTTP.

Voici un exemple de fichier SXG décodé.

format version: 1b3
request:
  method: GET
  uri: https://example.org/
  headers:
response:
  status: 200
  headers:
    Cache-Control: max-age=604800
    Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY=
    Expires: Mon, 24 Aug 2020 16:08:24 GMT
    Content-Type: text/html; charset=UTF-8
    Content-Encoding: mi-sha256-03
    Date: Mon, 17 Aug 2020 16:08:24 GMT
    Vary: Accept-Encoding
signature:
    label;cert-sha256=<em>ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=</em>;
    cert-url=&quot;https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE&quot;;
    date=1597680503;expires=1598285303;integrity=&quot;digest/mi-sha256-03&quot;;sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>;
    validity-url=&quot;https://example.org/webpkg/validity&quot;
header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p>

<p>The exchange has a valid signature.
payload [1256 bytes]:</p>
<pre class="prettyprint"><code>&lt;title&gt;SXG example&lt;/title&gt;
&lt;meta charset=&#34;utf-8&#34;&gt;
&lt;meta http-equiv=&#34;Content-type&#34; content=&#34;text/html; charset=utf-8&#34;&gt;
&lt;style type=&#34;text/css&#34;&gt;
body {
    background-color: #f0f0f2;
    margin: 0;
    padding: 0;
}
&lt;/style&gt;
</code></pre>
<div>
    <h1>Hello</h1>
</div>

<p>

Le paramètre expires de la signature indique la date d'expiration d'un SXG. Un SXG ne peut être valide que pendant sept jours maximum. Pour en savoir plus sur l'en-tête de signature, consultez la spécification des échanges HTTP signés.

Compatibilité avec la personnalisation côté serveur

Un SXG contenant un en-tête Vary: Cookie ne s'affichera que pour les utilisateurs qui ne disposent pas de cookies pour l'URL de la requête signée. Si votre site présente un code HTML différent aux utilisateurs connectés, vous pouvez utiliser cette fonctionnalité pour tirer parti des échanges signés sans altérer cette expérience. Pour en savoir plus sur la personnalisation côté serveur avec SXG dynamique, consultez la page correspondante.

Emballage Web

Les échanges signés font partie de la famille plus large des propositions de spécifications de packaging Web. En plus des SXG, l'autre composant majeur de la spécification de packaging Web est les bundles Web ("échanges HTTP groupés"). Les bundles Web sont un ensemble de ressources HTTP et des métadonnées nécessaires pour interpréter le bundle.

La relation entre les SXG et les bundles Web est souvent source de confusion. SXG et les Web Bundles sont deux technologies distinctes qui ne dépendent pas l'une de l'autre. Les Web Bundles peuvent être utilisés avec des échanges signés et non signés. Les SXG et les Web Bundles ont un objectif commun : créer un format de "conditionnement Web" qui permet de partager des sites dans leur intégralité pour une consommation hors connexion.

Accélérer le chargement des pages avec les échanges signés

L'activation des échanges signés peut contribuer à accélérer les performances des pages Web et donc à avoir un impact sur les métriques Core Web Vitals de votre site, en particulier sur la métrique LCP (Largest Contentful Paint). La recherche Google est l'une des premières à utiliser SXG pour offrir aux utilisateurs une expérience de chargement des pages plus rapide à partir de la page de résultats de recherche.

La recherche Google explore et met en cache les SXG lorsqu'ils sont disponibles, et précharge les SXG que l'utilisateur est susceptible de consulter (par exemple, la page correspondant au premier résultat de recherche).

Les SXG fonctionnent mieux en tandem avec d'autres optimisations des performances, telles que l'utilisation de CDN et la réduction des sous-ressources bloquant le rendu. Après l'implémentation, suivez ces recommandations pour maximiser les avantages du préchargement des SXG sur le LCP. Dans de nombreux cas, cette optimisation peut entraîner un chargement presque instantané des pages depuis la recherche Google :

Impact des échanges signés

D'après des tests précédents, nous avons constaté une réduction moyenne de 300 à 400 ms du LCP grâce aux préchargements compatibles avec SXG. Cela aide les sites à faire une meilleure première impression auprès des utilisateurs et a souvent un impact positif sur les métriques d'entreprise.

Plusieurs marques et sites internationaux ont déjà bénéficié des échanges signés. Prenons l'exemple d'RebelMouse, un système de gestion de contenu (CMS) réputé, qui a vu ses performances et ses métriques commerciales s'améliorer grâce à l'implémentation des échanges signés :

  • Narcity a amélioré son LCP de 41%
  • Paper Magazine a enregistré une augmentation de 27 % du nombre de sessions par utilisateur.
  • Le blog MLT a réduit le temps de chargement de la page de 21 %

Cloudflare a constaté que les échanges signés amélioraient le TTFB pour 98 % des sites testés et amélioraient le LCP pour 85 % des sites, avec une amélioration médiane de plus de 20 % pour les chargements de pages éligibles aux échanges signés.

Indexation

Les représentations SXG et non SXG d'une page ne sont pas classées ni indexées différemment par la recherche Google. Le format SXG est avant tout un mécanisme de diffusion. Il ne modifie pas le contenu sous-jacent.

AMP

Le contenu AMP peut être diffusé à l'aide de SXG. Les SXG permettent de précharger et d'afficher le contenu AMP à l'aide de son URL canonique, plutôt que de son URL AMP. AMP dispose de ses propres outils pour générer des SXG. Découvrez comment diffuser des pages AMP à l'aide d'échanges signés sur amp.dev.

Déboguer les échanges signés avec les outils pour les développeurs Chrome

Pour voir un SXG par vous-même, utilisez un navigateur Chromium, ouvrez DevTools, ouvrez le panneau "Réseau", puis accédez à cet exemple de page de recherche. Pour identifier les échanges signés, recherchez signed-exchange dans la colonne Type.

Capture d&#39;écran montrant une requête SXG dans le panneau &quot;Network&quot; (Réseau) de DevTools
Panneau Network (Réseau) dans DevTools

L'onglet Aperçu fournit plus d'informations sur le contenu d'un échange signé.

Capture d&#39;écran de l&#39;onglet &quot;Aperçu&quot; d&#39;une fiche SXG
Onglet Preview (Aperçu) dans DevTools

Outils

L'implémentation d'un échange signé consiste à générer le SXG correspondant à une URL donnée, puis à le diffuser aux demandeurs (généralement des robots d'exploration).

Certificats

Pour générer un SXG, vous avez besoin d'un certificat pouvant signer des SXG, bien que certains outils les acquièrent automatiquement. Cette page liste les autorités de certification qui peuvent émettre ce type de certificat. Vous pouvez obtenir automatiquement des certificats auprès de l'autorité de certification Google à l'aide de n'importe quel client ACME. Web Packager Server intègre un client ACME, qui sera bientôt compatible avec sxg-rs.

Outils SXG spécifiques à la plate-forme

Ces outils sont compatibles avec des piles technologiques spécifiques. Si vous utilisez déjà une plate-forme compatible avec l'un de ces outils, vous trouverez peut-être plus facile de la configurer qu'un outil à usage général.

Outils SXG à usage général

Serveur HTTP sxg-rs

sxg-rs http_server agit en tant que proxy inverse pour la diffusion des SXG. Pour les requêtes des robots d'exploration SXG, http_server signe les réponses du backend et envoie un SXG. Pour obtenir des instructions d'installation, consultez le fichier README.

Serveur de packageur Web

Le serveur Web Packager, webpkgserver, est une alternative à sxg-rs http_server, écrite en Go. Pour obtenir des instructions sur la configuration du serveur Web Packager, consultez Configurer des échanges signés à l'aide de Web Packager.

CLI Web Packager

La CLI Web Packager génère un SXG correspondant à une URL donnée.

webpackager \
    --private\_key=private.key \
    --cert\_url=https://example.com/certificate.cbor \
    --url=https://example.com

Une fois le fichier SXG généré, importez-le sur votre serveur et diffusez-le avec le type MIME application/signed-exchange;v=b3. De plus, vous devez diffuser le certificat SXG en tant que application/cert-chain+cbor.

Bibliothèques SXG

Vous pouvez utiliser ces bibliothèques pour créer votre propre générateur SXG :

  • sxg_rs est une bibliothèque Rust permettant de générer des SXG. Il s'agit de la bibliothèque SXG la plus complète. Elle sert de base aux outils cloudflare_worker et fastly_compute.

  • libsxg est une bibliothèque C minimale permettant de générer des échanges signés. Il sert de base au module SXG NGINX et au filtre SXG Envoy.

  • go/signed-exchange est une bibliothèque Go minimale fournie par la spécification de webpackage en tant qu'implémentation de référence de la génération de fichiers SXG. Il sert de base à son outil de référence de la CLI, gen-signedexchange, et aux outils de packager Web plus complets.

Négociation de contenu

Les serveurs doivent diffuser un échange signé lorsque l'en-tête Accept indique que la valeur q de l'application/de l'échange signé est supérieure ou égale à la valeur q de text/html. En pratique, cela signifie qu'un serveur d'origine transmet les échanges signés aux robots d'exploration, mais pas aux navigateurs. De nombreux outils ci-dessus le font par défaut, mais pour d'autres outils, l'expression régulière suivante peut être utilisée pour faire correspondre l'en-tête "Accept" des requêtes qui doivent être diffusées en tant que SXG : http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/

Cette recommandation inclut des exemples pour Apache et nginx.

Mettre à jour l'API de cache

Le cache Google SXG dispose d'une API que les propriétaires de sites peuvent utiliser pour supprimer les SXG du cache avant qu'ils n'expirent en raison de Cache-Control: max-age. Pour en savoir plus, consultez la documentation de référence de l'API update-cache.

Associer à SXG

Tout site peut mettre en cache, diffuser et précharger les SXG des pages auxquelles il renvoie, le cas échéant, à l'aide des balises et  : html <a href="https://example.com/article.html.sxg"> <link rel="prefetch" as="document" href="https://example.com/article.html.sxg"> cet article explique comment utiliser nginx pour distribuer des SXG.

Avantages uniques

SXG est l'une des nombreuses technologies permettant le préchargement multi-origine. Lorsque vous décidez quelle technologie utiliser, vous devrez peut-être faire des compromis entre les différents aspects de l'optimisation. Les sections suivantes illustrent quelques-unes des valeurs uniques offertes par les échanges signés dans l'espace des solutions possibles. Ces facteurs peuvent changer au fil du temps à mesure que l’espace des solutions disponibles évolue.

Moins de requêtes à diffuser

Avec le préchargement intersites, votre serveur peut être amené à traiter des requêtes supplémentaires. Cela correspond aux cas où une page a été préchargée, mais que l'utilisateur ne l'a pas consultée ou que les octets préchargés n'ont pas pu être affichés. Pour les échanges signés, ces requêtes supplémentaires inutilisées peuvent être considérablement réduites :

  • Les SXG sont mis en cache et peuvent être envoyés aux utilisateurs jusqu'à leur expiration. Ainsi, de nombreux préchargements peuvent être gérés uniquement par le serveur cache.
  • Les SXG peuvent être diffusées auprès des utilisateurs avec ou sans cookies sur votre site. Ainsi, la page devra être récupérée moins souvent après la navigation.

Amélioration de la vitesse des pages

Vous pouvez constater une amélioration supplémentaire de la vitesse des pages grâce aux surfaces et fonctionnalités de préchargement actuellement compatibles :

  • Les échanges signés peuvent être présentés aux utilisateurs avec des cookies pour votre site.
  • SXG précharge également des sous-ressources pour vos pages, telles que JavaScript, CSS, les polices et les images, si elle est spécifiée à l'aide d'un en-tête Link.
  • Bientôt, le préchargement des échanges signés à partir de la recherche Google sera disponible pour d'autres types de résultats de recherche.

Conclusion

Les échanges signés sont un mécanisme de distribution qui permet de vérifier l'origine et la validité d'une ressource indépendamment de son mode de distribution. Par conséquent, les SXG peuvent être distribués par des tiers tout en conservant une attribution complète à l'éditeur.

Documentation complémentaire