É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 façon dont elle a été diffusée. L'implémentation de SXG peut améliorer le Largest Contentful Paint (LCP) en activant le préchargement interorigine protégeant la confidentialité. De plus, ce découplage permet de prendre en charge différents cas d'utilisation, tels que les expériences Internet hors connexion et la diffusion à partir de caches tiers.

Cet article présente de manière exhaustive les SXG : leur fonctionnement, leurs cas d'utilisation et les outils associés.

Compatibilité du navigateur

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

Présentation

Le principal cas d'utilisation des échanges signés consiste à utiliser un cache pour précharger et diffuser du contenu signé de manière cryptographique par l'origine. Cela permet d'accélérer les navigations interorigines à partir des sites référents, tout en garantissant que les pages ne sont pas modifiées et qu'elles sont correctement attribuées à leur origine. Toute information permettant potentiellement d'identifier l'utilisateur est masquée jusqu'à ce qu'il accède à un site, ce qui protège sa confidentialité. La recherche Google est l'un des utilisateurs de la première heure des fonctionnalités de préchargement SXG. Pour les sites qui reçoivent une grande partie de leur trafic de la recherche Google, les SXG peuvent être un outil important pour accélérer le chargement des pages pour les utilisateurs. À terme, nous espérons que cet impact s'étendra à d'autres sites référents.

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 de la façon dont il a été distribué. 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.

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

Auparavant, la seule façon 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 ne permet pas de rendre le contenu véritablement portable.

Le format SXG

Un SXG 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 peut être valide pendant sept jours au maximum. Pour en savoir plus sur l'en-tête de signature, consultez la spécification des échanges HTTP signés.

Prise en charge de la personnalisation côté serveur

Un SXG contenant un en-tête Vary: Cookie ne sera visible que par les utilisateurs qui n'ont 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 profiter des SXG sans modifier cette expérience. Consultez les détails sur la personnalisation côté serveur avec les SXG dynamiques.

Web Packaging

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

La relation entre les SXG et les Web Bundles est une source de confusion fréquente. Les 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. Un objectif commun aux SXG et aux Web Bundles est la création d'un format de "package Web" qui permet de partager des sites dans leur intégralité pour une utilisation 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, par conséquent, à améliorer les métriques Core Web Vitals de votre site, en particulier le Largest Contentful Paint (LCP). En tant qu'utilisateur de la première heure, la recherche Google utilise les SXG pour offrir aux utilisateurs une expérience de chargement de page plus rapide pour les pages chargées à 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 lorsqu'ils sont associés à d'autres optimisations des performances, telles que l'utilisation de CDN et la réduction des sous-ressources bloquant l'affichage. Après l'implémentation, suivez ces recommandations pour maximiser l'avantage du LCP en préchargeant les SXG. Dans de nombreux cas, une telle optimisation peut entraîner un chargement de page presque instantané provenant de la recherche Google :

Impact des échanges signés

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

Plusieurs marques et sites internationaux ont déjà bénéficié des échanges signés. À titre d'exemple, voyons comment l'implémentation des échanges signés a aidé RebelMouse, un système de gestion de contenu (CMS) de premier plan, à améliorer les performances et les métriques commerciales de ses clients :

  • Narcity a amélioré le LCP de 41 %
  • Paper Magazine a constaté une augmentation de 27 % du nombre de sessions par utilisateur.
  • Le temps de chargement des pages a diminué de 21 % sur le blog MLT.

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

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 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 d'échanges signés. Les échanges signés permettent de précharger le contenu AMP et de l'afficher à l'aide de son URL canonique, plutôt que de son URL AMP.AMP dispose de ses propres outils pour générer des échanges signés.Découvrez comment diffuser des pages AMP à l'aide d'échanges signés sur amp.dev.

Déboguer les SXG avec les outils pour les développeurs Chrome

Pour voir un SXG, utilisez un navigateur Chromium, ouvrez les outils pour les développeurs, ouvrez le panneau "Réseau", puis accédez à cet exemple de page de recherche. Les échanges signés sont identifiés par la mention signed-exchange dans la colonne Type.

Capture d'écran montrant une requête SXG dans le panneau &quot;Réseau&quot; des outils de développement
Le panneau Réseau dans les outils de développement

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

Capture d'écran de l'onglet &quot;Aperçu&quot; pour un SXG
Onglet Aperçu dans les outils de développement

Outils

La mise en œuvre des SXG consiste à générer le SXG correspondant à une URL donnée, puis à le diffuser auprès des demandeurs (généralement des robots d'exploration).

Certificats

Pour générer un SXG, vous aurez besoin d'un certificat capable de signer les 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. Le serveur Web Packager dispose d'un client ACME intégré, et sxg-rs en aura bientôt un.

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, il vous sera peut-être plus facile de le configurer qu'un outil polyvalent.

Outils SXG à usage général

Serveur HTTP sxg-rs

Le http_server sxg-rs agit comme un proxy inverse pour diffuser des SXG. Pour les requêtes provenant de robots d'exploration SXG, http_server signera les réponses du backend et répondra avec un SXG. Pour obtenir des instructions d'installation, consultez le fichier README.

Serveur Web Packager

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 avec 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 devrez diffuser le certificat SXG en tant que application/cert-chain+cbor.

Bibliothèques SXG

Ces bibliothèques peuvent être utilisées pour créer votre propre générateur de 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 SXG. 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 du package Web en tant qu'implémentation de référence pour la génération de SXG. Il sert de base à son outil de CLI de référence, gen-signedexchange, et aux outils Web Packager plus complets.

Négociation de contenu

Les serveurs doivent diffuser des fichiers SXG lorsque l'en-tête Accept indique que la valeur q pour application/signed-exchange est supérieure ou égale à la valeur q pour text/html. En pratique, cela signifie qu'un serveur d'origine diffusera des SXG aux robots d'exploration, mais pas aux navigateurs. La plupart des outils ci-dessus le font par défaut, mais pour les 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 au format SXG : http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/

Cette recommandation inclut des exemples pour Apache et nginx.

API Update cache

Le cache d'échanges signés Google dispose d'une API que les propriétaires de sites peuvent utiliser pour supprimer les échanges signés du cache avant leur expiration en raison de Cache-Control: max-age. Pour en savoir plus, consultez la documentation de référence de l'API de mise à jour du cache.

Associer à un SXG

Tout site peut mettre en cache, diffuser et précharger les SXG des pages vers lesquelles 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

Le mécanisme SXG est l'une des nombreuses technologies permettant le préchargement interorigine. Lorsque vous choisissez la technologie à utiliser, vous devrez peut-être faire un compromis entre l'optimisation de différents aspects. Les sections suivantes illustrent quelques-unes des valeurs uniques que les SXG fournissent dans l'espace des solutions possibles. Ces facteurs peuvent changer au fil du temps, à mesure que l'éventail des solutions disponibles évolue.

Moins de requêtes à traiter

Avec la prérécupération intersites, votre serveur peut avoir à traiter des requêtes supplémentaires. Cela correspond aux cas où une page a été préchargée, mais où l'utilisateur ne l'a pas consultée ou les octets préchargés n'ont pas pu lui être présentés. Pour les SXG, 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 de cache.
  • Les SXG peuvent être présentés aux utilisateurs avec et 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 de chargement des pages

Vous constaterez peut-être une amélioration supplémentaire de la vitesse de chargement des pages grâce aux surfaces et aux fonctionnalités de préchargement actuellement prises en charge :

  • Les SXG peuvent être présentés aux utilisateurs disposant de cookies pour votre site.
  • Les SXG préchargent également les sous-ressources de vos pages, telles que les fichiers JavaScript, CSS, les polices et les images, lorsqu'elles sont spécifiées à l'aide d'un en-tête Link.
  • Dans un avenir proche, le préchargement SXG depuis la recherche Google sera disponible pour d'autres types de résultats de recherche.

Conclusion

Les échanges signés sont un mécanisme de diffusion qui permet de vérifier l'origine et la validité d'une ressource, indépendamment de la manière dont elle a été diffusée. Par conséquent, les SXG peuvent être distribués par des tiers tout en conservant l'attribution complète de l'éditeur.

Documentation complémentaire