Échanges signés (SXG)

Un échange signé est un mécanisme de livraison qui permet d'authentifier l'origine d'une ressource indépendamment de la manière dont elle a été fournie.

Katie Hempenius
Katie Hempenius
X
Devin Mullins
Devin Mullins
X GitHub

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

Cet article offre une présentation complète de l'échange signé: son fonctionnement, ses cas d'utilisation et ses outils.

Compatibilité du navigateur

L'échange signé est compatible avec les navigateurs basés sur Chromium (à partir des versions: Chrome 73, Edge 79 et Opera 64).

Présentation

Dans son principal cas d'utilisation, l'échange signé utilise un cache pour précharger et diffuser le contenu portant une signature cryptographique par l'origine. Cela permet d'accélérer les navigations entre différentes origines à partir des sites référents tout en garantissant que les pages restent inchangées et correctement attribuées à leur origine. Toute information d'identification potentielle est masquée jusqu'à ce que l'utilisateur accède au site, ce qui protège la vie privée de l'utilisateur. La recherche Google est l'un des premiers utilisateurs des fonctionnalités de préchargement d'échanges signés. Pour les sites qui reçoivent une grande partie de leur trafic en provenance de la recherche Google, l'échange signé peut s'avérer un outil important pour accélérer le chargement des pages. Nous espérons que cette mesure s'étendra progressivement à d'autres parrains.

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 manière dont celui-ci 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.

Schéma expliquant le fonctionnement des échanges signés. Le navigateur communique avec le cache, lequel communique avec le site de destination.

Auparavant, le seul moyen pour un site de faire appel à un tiers pour distribuer son contenu tout en conservant l'attribution consistait à partager ses certificats SSL avec le distributeur. Cette approche présente des inconvénients en termes de sécurité. De plus, la portabilité du contenu est loin d'être étendue.

Le format SXG

Un échange signé est encapsulé dans un fichier encodé en binaire comportant deux composants principaux: un échange HTTP et une signature qui couvre l'échange. Il 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 dans la signature indique la date d'expiration d'un échange signé. Un mécanisme SXG ne peut pas être valide pendant sept jours maximum. Pour en savoir plus sur l'en-tête de signature, consultez la spécification Signed HTTP Exchanges.

Prise en charge de la personnalisation côté serveur

Un échange signé contenant un en-tête Vary: Cookie ne sera visible qu'auprès des utilisateurs qui n'ont pas de cookies pour l'URL de 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 modifier cette expérience. Consultez les détails sur la personnalisation côté serveur avec Dynamic SXG.

Empaquetage Web

Le mécanisme SXG fait partie de la famille de propositions de spécification Web Packaging plus large. Outre les échanges SXG, l'autre composant majeur de la spécification des packages Web est les Web bundles ("échanges HTTP groupés"). Les Web bundles sont un ensemble de ressources HTTP et les métadonnées nécessaires à l'interprétation du bundle.

La relation entre les échanges signés et les bundles Web est un point de confusion courant. Les authentifications signés et les bundles Web 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 échanges signés et les bundles Web ont souvent pour objectif de créer un format de "package Web" qui permet de partager l'intégralité des sites pour une utilisation hors connexion.

Accélérer le chargement des pages grâce aux échanges signés

L'activation des échanges signés peut améliorer les performances des pages Web et, de ce fait, avoir un impact sur 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 l'échange signé pour offrir aux utilisateurs un processus de chargement plus rapide des pages chargées à partir de la page de résultats de recherche.

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

L'échange signé fonctionne mieux lorsqu'il est associé à d'autres optimisations de 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 les avantages du LCP du préchargement des échanges signés. Dans de nombreux cas, cette optimisation peut entraîner un chargement quasi instantané des pages depuis la recherche Google:

Impact des échanges signés

D'après les tests précédents, nous avons observé une réduction moyenne de 300 à 400 ms du LCP des préchargements compatibles avec les échanges signés. Cela permet aux sites d'offrir une meilleure première impression aux utilisateurs, ce qui a souvent un impact positif sur les métriques commerciales.

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

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

Cloudflare a constaté que le SXG a amélioré le TTFB pour 98 % des sites et a amélioré le LCP pour 85 % des chargements de pages en moyenne

Indexation

Les représentations SXG et non SXG d'une page ne sont pas classées ni indexées différemment dans la recherche Google. En fin de compte, l'échange signé est un mécanisme de diffusion : il ne modifie pas le contenu sous-jacent.

AMP

Le contenu AMP peut être diffusé à l'aide d'un échange signé. L'échange signé permet de précharger le contenu AMP et de l'afficher à l'aide de son URL canonique plutôt que via son URL AMP.AMP dispose de ses propres outils distincts 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 échanges signés avec les outils pour les développeurs Chrome

Pour voir un échange signé, utilisez le navigateur Chromium, ouvrez les outils de développement, ouvrez le panneau "Network" (Réseau), puis accédez à cet exemple de page de recherche. Les échanges signés peuvent être identifiés en recherchant signed-exchange dans la colonne Type.

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

L'onglet Preview (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;un échange signé
Onglet Preview (Aperçu) des outils de développement

Outils

L'implémentation d'un échange signé consiste à générer l'échange signé 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 échange signé, vous avez besoin d'un certificat capable de signer les échanges signés, bien que certains outils les acquièrent automatiquement. Cette page liste les autorités de certification qui peuvent délivrer ce type de certificat. Les certificats peuvent être obtenus automatiquement auprès de l'autorité de certification Google à l'aide de n'importe quel client ACME. Web Packager Server dispose d'un client ACME intégré, et sxg-rs le sera bientôt.

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 peut être plus facile de configurer qu'un outil à usage général.

Outils SXG à usage général

Serveur HTTP sxg-rs

Le serveur http_server sxg-rs agit comme un proxy inverse pour diffuser les échanges signés. Pour les requêtes des robots d'exploration SXG, http_server signe les réponses du backend et répond par un échange signé. Pour obtenir des instructions d'installation, consultez le fichier README.

Serveur Web Packager

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

CLI Web Packager

La CLI Web Packager génère un échange signé 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. En outre, 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 d'échanges signés:

  • sxg_rs est une bibliothèque Rust permettant de générer des échanges signés. Il s'agit de la bibliothèque SXG la plus complète, utilisée comme base pour les 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 NGINX SXG et au filtre SXG Envoy.

  • go/signed-exchange est une bibliothèque Go minimale fournie par la spécification du package webpackage en tant qu'implémentation de référence pour générer des échanges signés. Il est utilisé comme base pour son outil CLI de référence, gen-signedexchange, et les outils Web Packager, plus riches en fonctionnalités.

Négociation de contenu

Les serveurs doivent diffuser des échanges signés lorsque l'en-tête Accept indique que la valeur q de l'échange signé est supérieure ou égale à la valeur q de texte/html. En pratique, cela signifie qu'un serveur d'origine diffusera un échange signé aux robots d'exploration, mais pas aux navigateurs. La plupart des outils ci-dessus le font par défaut, mais pour d'autres, l'expression régulière suivante peut être utilisée pour mettre en correspondance l'en-tête Accept des requêtes devant être diffusées en tant qu'échanges signés : 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

Google SXG Cache dispose d'une API que les propriétaires de sites peuvent utiliser pour supprimer les échanges signés 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 du cache de mise à jour.

Association à un échange signé

Tous les sites peuvent mettre en cache, diffuser et précharger les échanges signés des pages vers lesquelles ils renvoient, 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 échanges signés.

Avantages uniques

Le mécanisme SXG est l'une des nombreuses technologies possibles pour permettre le préchargement multi-origine. Au moment de choisir la technologie à utiliser, vous devrez peut-être trouver un compromis entre l'optimisation de différents aspects. Les sections suivantes illustrent quelques-unes des valeurs uniques fournies par les échanges signés dans le domaine des solutions possibles. Ces facteurs peuvent changer à mesure que l'espace des solutions disponibles évolue.

Moins de requêtes à traiter

Avec le préchargement intersite, votre serveur peut avoir besoin de diffuser 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 présentés à l'utilisateur. Pour l'échange signé, le nombre de requêtes inutilisées supplémentaires peut être considérablement réduit:

  • Les échanges signés 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 échanges signés peuvent être présentés aux utilisateurs avec et sans cookies sur votre site. Ainsi, la page devra être récupérée à nouveau après la navigation.

Amélioration de la vitesse de chargement des pages

Vous constaterez peut-être une amélioration de la vitesse des pages en raison des surfaces et des 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 les sous-ressources de vos pages, telles que JavaScript, CSS, les polices et les images, lorsqu'elles sont spécifiées à l'aide d'un en-tête Link.
  • Le préchargement d'échanges signés depuis la recherche Google sera bientôt 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 la manière dont elle a été diffusée. Par conséquent, les échanges signés peuvent être distribués par des tiers tout en conservant une attribution complète de l'éditeur.

Complément d'informations