Échanges signés (SXG)

Un échange signé est 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.

Katie Hempenius

Devin Mullins

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é diffusée. L'implémentation d'un échange signé peut améliorer le Largest Contentful Paint (LCP) en activant le préchargement multi-origine protégeant la confidentialité. En outre, ce découplage fait avancer différents 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 des échanges signés: leur fonctionnement, leurs cas d'utilisation et leurs outils.

Compatibilité du navigateur

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

Présentation

Comme principal cas d'utilisation, 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 la navigation entre les origines à partir des sites référents, tout en garantissant que les pages restent intactes et correctement attribuées à leur origine. Toutes les informations potentiellement permettant d'identifier l'utilisateur sont masquées tant que l'utilisateur n'a pas accédé à un site, ce qui protège la vie privée de l'utilisateur. La recherche Google fait partie des premiers à utiliser les fonctionnalités de préchargement des échanges signés. Pour les sites qui reçoivent une grande partie de leur trafic provenant de la recherche Google, les échanges signés peuvent être un outil important pour accélérer les chargements de page. Nous espérons que cet impact s'appliquera à d'autres parrains 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 comment le contenu a été distribué. Par conséquent, le navigateur peut afficher l'URL de le site d'origine dans la barre d'adresse, et non l'URL du serveur a diffusé le contenu.

Historiquement, le seul moyen pour un site à faire appel à un tiers pour distribuer son contenu tout en maintenant a été le partage des certificats SSL entre le site distributeur. Cela présente des inconvénients en termes de sécurité : De plus, c'est loin ce qui rend le contenu vraiment portable.

Le format SXG

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

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 échange signé. A L'échange signé peut être valide pendant sept jours au maximum. En savoir plus sur l'en-tête de signature dans la boîte de dialogue Signed HTTP Exchanges caractéristiques.

Compatibilité avec la personnalisation côté serveur

Un échange signé contenant un en-tête Vary: Cookie ne sera affiché qu'auprès des utilisateurs des cookies pour l'URL de requête signée. Si votre site présente des codes HTML différents à ses utilisateurs connectés, vous pouvez utiliser cette fonctionnalité pour profiter des échanges signés sans modifier cette expérience. En savoir plus sur la personnalisation côté serveur avec Dynamic SXG.

Mise en package Web

SXG s'inscrit dans le cadre de l'approche globale Famille de propositions de spécifications. En outre, l'autre composant majeur des spécifications du Web Packaging, les Web Bundles ("échanges HTTP groupés"). Les web bundles sont un ensemble de ressources HTTP les métadonnées nécessaires à l'interprétation du bundle.

La relation entre les SXG et les Web Bundles est une source de confusion commune. SXG et Web Bundle sont deux technologies distinctes qui ne dépendent pas de l'une ou l'autre Autre : les bundles Web peuvent être utilisés avec des échanges signés et non signés. Une approche l'objectif avancé par les SXG et les Web Bundles est la création d'un "package Web" qui permet de partager l'intégralité des sites pour une utilisation hors ligne.

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

L'activation des échanges signés peut vous aider à améliorer les performances de vos pages Web et ainsi avoir un impact sur les métriques Core Web Vitals de votre site, en particulier Largest Contentful Paint (LCP). La recherche Google fait partie des premiers utilisateurs de la recherche Google. Elle utilise les échanges signés pour offrir aux utilisateurs une expérience de chargement plus rapide des pages chargées depuis la page de résultats de recherche.

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

Le mécanisme SXG fonctionne mieux en tandem avec d'autres optimisations de performances telles que l'utilisation de CDN et la réduction des sous-ressources qui bloquent 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 des chargements de page presque instantanés en provenance de la recherche Google:

Impact des échanges signés

D'après nos tests précédents, nous avons observé une réduction moyenne de 300 ms à 400 ms du LCP à partir des 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. Étude de cas : voyons comment l'implémentation des échanges signés a permis à RebelMouse, un système de gestion de contenu (CMS), d'améliorer les performances de ses clients. les performances et les métriques commerciales:

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

Cloudflare a constaté que SXG a amélioré le TTFB pour 98% des sites testés, ainsi que le LCP pour 85% des sites, avec une amélioration médiane de plus de 20% pour les chargements de pages éligibles à l'échange.

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. En fin de compte, les échanges signés sont un mécanisme de livraison. modifier le contenu sous-jacent.

AMP

Le contenu AMP peut être diffusé via un échange signé. L'échange signé permet le préchargement du contenu AMP et s'affiche à l'aide de son URL canonique plutôt que de son URL AMP.AMP dispose de son propre outils permettant de 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 "Réseau", puis accédez à cet exemple de page de recherche. Vous pouvez identifier les échanges signés en recherchant signed-exchange dans la colonne Type.

</ph>

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

</ph>

Outils

L'implémentation des échanges signés consiste à générer le lien annexe correspondant à une URL donnée puis de transmettre ce SXG aux demandeurs (généralement des robots d'exploration).

Certificats

Pour générer un échange signé, vous aurez besoin d'un certificat capable de signer un échange signé, bien que certains outils les acquièrent automatiquement. Cette page liste les autorités de certification qui peuvent émettre ce type de certificat. Les certificats peuvent être obtenus automatiquement auprès de l’autorité de certification Google en utilisant n’importe quel client ACME. Web Packager Server dispose d'un client ACME intégré, et sxg-rs en disposera bientôt.

Outils SXG spécifiques à la plate-forme

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

• sxg-rs/cloudflare_worker sur des nœuds de calcul Cloudflare.

• sxg-rs/fastly_compute s'exécute sur Fastly Compute@Edge.

• Signature automatique Places de marché est un Fonctionnalité Cloudflare qui acquiert et génère automatiquement les certificats Échanges signés

• Le module NGINX SXG génère et diffuse des SXG pour les sites qui utilisent nginx. Configuration consultez ces instructions.

• Envoy SXG Filtre génère et diffuse des échanges signés pour les sites utilisant Envoy :

Outils SXG à usage général

Serveur HTTP sxg-rs

Les sxg-rs http_server sert de proxy inverse pour et desservent des échange signés. Pour les requêtes provenant de robots d'exploration SXG, http_server signe le des réponses du backend et répondre avec un échange signé. Installation instructions, consultez les README

Serveur Web Packager

Web Packager serveur, webpkgserver est une alternative à sxg-rs http_server, écrite en Go. Pour pour la configuration du serveur Web Packager, consultez la section Comment configurer un places de marché à 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 le type MIME application/signed-exchange;v=b3. De plus, vous devez afficher 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 conçue pour la génération d'échanges signés. Il s'agit de la bibliothèque SXG la plus complète. Elle est utilisée pour les outils cloudflare_worker et fastly_compute.

• libsxg est une bibliothèque C minimale pour la génération d'échanges signés. Il est utilisé comme base pour le module NGINX SXG et Filtre SXG Envoy.

• go/signed-exchange est une bibliothèque Go minimale fournie par la spécification webpackage sous forme de référence l'implémentation de la génération d'échanges signés. Il est utilisé comme base pour son outil CLI de référence, gen-signedexchange et les outils Web Packager plus fonctionnels.

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. 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 correspondre à l'en-tête Accept des requêtes qui doivent être diffusées en tant qu'échange signé: http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/

Cette recommandation inclut des exemples pour Apache et nginx.

Mettre à jour l'API cache

Google SXG Cache dispose d'une API qui permet aux propriétaires de sites de 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 Update Cache.

Association à un échange signé

Chaque site peut mettre en cache, diffuser et précharger les échanges signés avec les pages vers lesquelles il renvoie, le cas échéant, à l'aide des tags 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 distribuer des SXG à l'aide de nginx.

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 avoir besoin de 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 présentés à l'utilisateur. Pour les échanges signés, le nombre de demandes 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 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 moins souvent après la navigation.

Amélioration de la vitesse des pages

Vous constaterez peut-être une amélioration supplémentaire de la vitesse de chargement 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 la manière dont livrés. Par conséquent, les échanges signés peuvent être distribués par des tiers, tandis que et conserver l'attribution complète de l'éditeur.

Documentation complémentaire

• Brouillon de spécification pour les échanges HTTP signés
• Explications sur le Web Packaging
• Premiers pas avec les échanges signés dans la recherche Google
• Configurer des échanges signés à l'aide de Web Packager
• Démonstration des échanges signés