Signed Exchanges (SXGs)

SXG ist ein Übermittlungsmechanismus, mit dem der Ursprung einer Ressource unabhängig von der Art der Übermittlung authentifiziert werden kann.

Katie Hempenius
Katie Hempenius
X
Devin Mullins
Devin Mullins
X GitHub

Signed Exchanges (SXG) sind ein Bereitstellungsmechanismus, mit dem der Ursprung einer Ressource unabhängig von der Art der Bereitstellung authentifiziert werden kann. Durch die Implementierung von SXG kann der Largest Contentful Paint (LCP) verbessert werden, da ein datenschutzfreundliches ursprungsübergreifendes Prefetching ermöglicht wird. Außerdem ermöglicht diese Entkopplung eine Vielzahl von Anwendungsfällen, z. B. Offline-Internetnutzung und Bereitstellung aus Caches von Drittanbietern.

Dieser Artikel bietet einen umfassenden Überblick über SXG: Funktionsweise, Anwendungsfälle und Tools.

Browser-Kompatibilität

SXG wird von Chromium-basierten Browsern unterstützt (ab Chrome 73, Edge 79 und Opera 64).

Übersicht

Der primäre Anwendungsfall von SXG ist die Verwendung eines Cache, um Inhalte, die vom Ursprung kryptografisch signiert wurden, vorab abzurufen und bereitzustellen. So können ursprungsübergreifende Navigationen von Referrer-Websites beschleunigt werden. Gleichzeitig wird sichergestellt, dass die Seiten unverändert bleiben und ihrem Ursprung korrekt zugeordnet werden. Alle potenziell personenidentifizierbaren Informationen werden ausgeblendet, bis der Nutzer eine Website aufruft. So wird die Privatsphäre des Nutzers geschützt. Die Google Suche ist einer der ersten Nutzer der SXG-Prefetch-Funktionen. Für Websites, die einen großen Teil ihres Traffics über die Google Suche erhalten, kann SXG ein wichtiges Tool sein, um Nutzern schnellere Seitenaufbauten zu bieten. Wir hoffen, dass sich diese Auswirkungen im Laufe der Zeit auf weitere Referrer ausweiten werden.

Funktionsweise

Eine Website signiert ein Anfrage/Antwort-Paar (einen „HTTP-Austausch“) so, dass der Browser den Ursprung und die Integrität des Inhalts unabhängig davon überprüfen kann, wie der Inhalt verteilt wurde. Dadurch kann der Browser die URL der Ursprungswebsite in der Adressleiste anzeigen, anstatt die URL des Servers, der den Inhalt bereitgestellt hat.

Diagramm, das die Funktionsweise von Signed Exchanges erklärt. Browser, der mit dem Cache kommuniziert, der wiederum mit der Zielwebsite kommuniziert

In der Vergangenheit bestand die einzige Möglichkeit für eine Website, ihre Inhalte über einen Drittanbieter zu verbreiten und gleichzeitig die Zuordnung beizubehalten, darin, ihre SSL-Zertifikate mit dem Distributor zu teilen. Dies hat Sicherheitsnachteile und ist weit davon entfernt, Inhalte wirklich portabel zu machen.

Das SXG-Format

Ein SXG ist in einer binär codierten Datei gekapselt, die zwei Hauptkomponenten hat: einen HTTP-Austausch und eine Signatur, die den Austausch abdeckt. Der HTTP-Austausch besteht aus einer Anfrage-URL, Informationen zur Inhaltsverhandlung und einer HTTP-Antwort.

Hier ist ein Beispiel für eine decodierte SXG-Datei.

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>

Der Parameter expires in der Signatur gibt das Ablaufdatum einer SXG an. Ein SXG kann maximal 7 Tage lang gültig sein. Weitere Informationen zum Signatur-Header findest du in der Spezifikation für Signed HTTP Exchanges.

Unterstützung für serverseitige Personalisierung

Ein SXG, das einen Vary: Cookie-Header enthält, wird nur Nutzern angezeigt, die keine Cookies für die signierte Anfrage-URL haben. Wenn auf deiner Website für angemeldete Nutzer ein anderes HTML angezeigt wird, kannst du diese Funktion verwenden, um SXGs zu nutzen, ohne dass sich die Darstellung ändert. Weitere Informationen finden Sie unter Serverseitige Personalisierung mit dynamischem SXG.

Web Packaging

SXG ist Teil der umfassenderen Spezifikationsvorschläge für Web-Packaging. Neben SXGs sind Web-Bundles („gebündelte HTTP-Austausche“) die andere wichtige Komponente der Web Packaging-Spezifikation. Web-Bundles sind eine Sammlung von HTTP-Ressourcen und den Metadaten, die zum Interpretieren des Bundles erforderlich sind.

Die Beziehung zwischen SXGs und Web-Bundles ist häufig ein Grund für Verwirrung. SXG und Web-Bundles sind zwei unterschiedliche Technologien, die nicht voneinander abhängen. Web-Bundles können sowohl mit signierten als auch mit nicht signierten Exchanges verwendet werden. Ein gemeinsames Ziel von SXGs und Web Bundles ist die Erstellung eines „Web-Packaging“-Formats, mit dem Websites vollständig für die Offlinenutzung freigegeben werden können.

Seitenaufbau mit Signed Exchanges beschleunigen

Wenn Sie Signed Exchanges aktivieren, kann das die Leistung von Webseiten beschleunigen und sich so auf die Core Web Vitals Ihrer Website auswirken, insbesondere auf den Largest Contentful Paint (LCP). Als einer der ersten Nutzer verwendet die Google Suche SXG, um Nutzern ein schnelleres Laden von Seiten zu ermöglichen, die über die Suchergebnisseite aufgerufen werden.

Die Google Suche crawlt und speichert SXGs im Cache, sofern verfügbar, und ruft SXGs vorab ab, die der Nutzer wahrscheinlich besuchen wird, z. B. die Seite, die dem ersten Suchergebnis entspricht.

SXG funktioniert am besten in Kombination mit anderen Leistungsoptimierungen, z. B. der Verwendung von CDNs und der Reduzierung von renderblockierenden Unterressourcen. Halte dich nach der Implementierung an diese Empfehlungen, um den LCP-Vorteil durch das Prefetching von SXGs zu maximieren. In vielen Fällen kann eine solche Optimierung dazu führen, dass Seiten, die über die Google Suche aufgerufen werden, fast sofort geladen werden:

Auswirkungen von Signed Exchanges

In früheren Tests haben wir festgestellt, dass sich der LCP durch SXG-fähiges Prefetching im Durchschnitt um 300 bis 400 ms verringert. So können Websites einen besseren ersten Eindruck bei Nutzern hinterlassen, was sich oft positiv auf die Geschäftsmesswerte auswirkt.

Mehrere globale Marken und Websites haben bereits von Signed Exchanges profitiert. Sehen wir uns als Fallstudie an, wie die Implementierung von signierten Austauschen RebelMouse, einem bekannten Content-Management-System (CMS), geholfen hat, die Leistung und die Geschäftsmesswerte seiner Kunden zu verbessern:

  • Narcity verbesserte den LCP um 41 %
  • Paper Magazine verzeichnete einen Anstieg der Sitzungen pro Nutzer um 27 %.
  • MLT Blog konnte die Seitenladezeit um 21 % reduzieren

Cloudflare hat festgestellt, dass SXG die TTFB für 98 % der getesteten Websites und den LCP für 85 % der Websites verbessert hat. Bei SXG-fähigen Seitenaufbauten lag die Verbesserung im Median bei über 20 %.

Indexierung

Die SXG- und Nicht-SXG-Darstellungen einer Seite werden von der Google Suche nicht unterschiedlich eingestuft oder indexiert. SXG ist letztendlich ein Bereitstellungsmechanismus, der den zugrunde liegenden Inhalt nicht ändert.

AMP

AMP-Inhalte können über SXG bereitgestellt werden. Mit SXG können AMP-Inhalte vorab abgerufen und mit ihrer kanonischen URL anstelle ihrer AMP-URL angezeigt werden.AMP hat eigene Tools zum Generieren von SXGs.Informationen zum Bereitstellen von AMP mit Signed Exchanges findest du auf amp.dev.

SXGs mit den Chrome-Entwicklertools debuggen

Wenn ihr euch ein SXG ansehen möchtet, öffnet in einem Chromium-Browser die Entwicklertools und den Netzwerkbereich und ruft diese Beispielsuchseite auf. Signierte Austausche sind in der Spalte Typ mit signed-exchange gekennzeichnet.

Screenshot einer SXG-Anfrage im Bereich „Netzwerk“ in den Entwicklertools
Der Bereich Netzwerk in den Entwicklertools

Auf dem Tab Vorschau finden Sie weitere Informationen zum Inhalt einer SXG.

Screenshot des Tabs „Vorschau“ für ein SXG
Der Tab Vorschau in den Entwicklertools

Tools

Die Implementierung von SXGs besteht darin, das SXG für eine bestimmte URL zu generieren und dieses SXG dann an Anfragende (normalerweise Crawler) zu senden.

Zertifikate

Zum Generieren eines SXG benötigen Sie ein Zertifikat, mit dem SXGs signiert werden können. Einige Tools rufen diese jedoch automatisch ab. Auf dieser Seite sind die Zertifizierungsstellen aufgeführt, die diesen Zertifikatstyp ausstellen können. Zertifikate können mit einem beliebigen ACME-Client automatisch von der Google-Zertifizierungsstelle abgerufen werden. Der Web Packager-Server hat einen integrierten ACME-Client und sxg-rs wird bald einen haben.

Plattformspezifische SXG-Tools

Diese Tools unterstützen bestimmte Technologie-Stacks. Wenn Sie bereits eine Plattform verwenden, die von einem dieser Tools unterstützt wird, ist die Einrichtung möglicherweise einfacher als bei einem Tool für allgemeine Zwecke.

SXG-Tools für allgemeine Zwecke

sxg-rs-HTTP-Server

Der sxg-rs http_server fungiert als Reverse-Proxy für die Bereitstellung von SXGs. Bei Anfragen von SXG-Crawlern signiert http_server die Antworten vom Backend und antwortet mit einem SXG. Eine Installationsanleitung finden Sie in der README-Datei.

Web Packager-Server

Der Web Packager Server, webpkgserver, ist eine in Go geschriebene Alternative zu sxg-rs http_server. Eine Anleitung zum Einrichten des Web Packager Servers finden Sie unter How to set up signed exchanges using Web Packager.

Web Packager-Befehlszeile

Die Web Packager-Befehlszeile generiert ein SXG, das einer bestimmten URL entspricht.

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

Nachdem die SXG-Datei generiert wurde, laden Sie sie auf Ihren Server hoch und stellen Sie sie mit dem MIME-Typ application/signed-exchange;v=b3 bereit. Außerdem musst du das SXG-Zertifikat als application/cert-chain+cbor bereitstellen.

SXG-Bibliotheken

Mit diesen Bibliotheken können Sie Ihren eigenen SXG-Generator erstellen:

  • sxg_rs ist eine Rust-Bibliothek zum Generieren von SXGs. Sie ist die SXG-Bibliothek mit den meisten Funktionen und dient als Grundlage für die Tools cloudflare_worker und fastly_compute.

  • libsxg ist eine minimale C-Bibliothek zum Generieren von SXGs. Es wird als Grundlage für das NGINX-SXG-Modul und den Envoy-SXG-Filter verwendet.

  • go/signed-exchange ist eine minimale Go-Bibliothek, die von der Webpackage-Spezifikation als Referenzimplementierung zum Generieren von SXGs bereitgestellt wird. Es wird als Grundlage für das Referenz-Befehlszeilentool gen-signedexchange und die funktionsreicheren Web Packager-Tools verwendet.

Inhaltsverhandlung

Server sollten SXG bereitstellen, wenn der Accept-Header angibt, dass der q-Wert für application/signed-exchange größer oder gleich dem q-Wert für text/html ist. In der Praxis bedeutet dies, dass ein Ursprungsserver SXG an Crawler, aber nicht an Browser liefert. Viele der oben genannten Tools tun dies standardmäßig. Für andere Tools kann der folgende reguläre Ausdruck verwendet werden, um den Accept-Header von Anfragen abzugleichen, die als SXG bereitgestellt werden sollen: http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/

Diese Empfehlung enthält Beispiele für Apache und nginx.

Update Cache API

Der Google SXG-Cache hat eine API, mit der Websiteinhaber SXGs aus dem Cache entfernen können, bevor sie aufgrund von Cache-Control: max-age ablaufen. Weitere Informationen finden Sie in der API-Referenz zum Aktualisieren des Cache.

Verlinkung zu SXG

Jede Website kann SXGs der Seiten, auf die sie verlinkt, im Cache speichern, bereitstellen und vorab abrufen, sofern verfügbar. Dazu werden die Tags und verwendet: html <a href="https://example.com/article.html.sxg"> <link rel="prefetch" as="document" href="https://example.com/article.html.sxg"> In diesem Artikel wird veranschaulicht, wie SXGs mit nginx verteilt werden.

Einzigartige Vorteile

SXG ist eine von vielen möglichen Technologien, um ursprungsübergreifendes Prefetching zu ermöglichen. Bei der Entscheidung, welche Technologie Sie verwenden möchten, müssen Sie möglicherweise einen Kompromiss zwischen der Optimierung verschiedener Aspekte eingehen. In den folgenden Abschnitten werden einige der einzigartigen Werte veranschaulicht, die SXG im Bereich möglicher Lösungen bietet. Diese Faktoren können sich im Laufe der Zeit ändern, da sich die verfügbaren Lösungen weiterentwickeln.

Weniger Anfragen, die verarbeitet werden müssen

Beim websiteübergreifenden Prefetching muss Ihr Server möglicherweise zusätzliche Anfragen verarbeiten. Das entspricht Fällen, in denen eine Seite vorab abgerufen wurde, der Nutzer die Seite aber entweder nicht besucht hat oder die vorab abgerufenen Byte dem Nutzer nicht angezeigt werden konnten. Bei SXG können diese zusätzlichen ungenutzten Anfragen erheblich reduziert werden:

  • SXGs werden im Cache gespeichert und können an Nutzer gesendet werden, bis sie ablaufen. Daher können viele Prefetches ausschließlich vom Cache-Server verarbeitet werden.
  • SXGs können Nutzern sowohl mit als auch ohne Cookies auf deiner Website angezeigt werden. Daher muss die Seite nach der Navigation seltener neu abgerufen werden.

Verbesserung der Seitengeschwindigkeit

Aufgrund der derzeit unterstützten Prefetch-Oberflächen und ‑Funktionen kann sich die Seitengeschwindigkeit weiter verbessern:

  • SXGs können Nutzern mit Cookies für deine Website angezeigt werden.
  • SXG ruft auch Unterressourcen für Ihre Seiten vorab ab, z. B. JavaScript, CSS, Schriftarten und Bilder, wenn diese mit einem Link-Header angegeben werden.
  • In naher Zukunft wird das SXG-Prefetching aus der Google Suche für weitere Suchergebnistypen verfügbar sein.

Fazit

Signed Exchanges sind ein Bereitstellungsmechanismus, mit dem sich der Ursprung und die Gültigkeit einer Ressource unabhängig davon überprüfen lassen, wie die Ressource bereitgestellt wurde. Daher können SXGs von Drittanbietern verteilt werden, während die vollständige Zuordnung zum Publisher erhalten bleibt.

Weitere Informationen