Signed Exchanges (SXGs)

Ein SXG ist ein Übermittlungsmechanismus, der es ermöglicht, den Ursprung einer Ressource unabhängig von der Art der Übermittlung zu authentifizieren.

Katie Hempenius
Katie Hempenius
X
Devin Mullins
Devin Mullins
X GitHub

Signed Exchange (SXG) ist ein Übermittlungsmechanismus, der es ermöglicht, den Ursprung einer Ressource unabhängig von der Art der Übermittlung zu authentifizieren. Durch die Implementierung von SXG kann der Largest Contentful Paint (LCP) verbessert werden, indem der datenschutzfreundliche ursprungsübergreifende Prefetch aktiviert wird. Außerdem werden durch diese Entkopplung viele Anwendungsfälle wie die Offline-Internetnutzung und die Bereitstellung aus Drittanbieter-Caches unterstützt.

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

Browserkompatibilität

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

Überblick

Für SXG wird in erster Linie ein Cache verwendet, um Inhalte, die vom Ursprung kryptografisch signiert wurden, vorab abzurufen und bereitzustellen. Dadurch wird die ursprungsübergreifende Navigation von Verweis-Websites beschleunigt und gleichzeitig sichergestellt, dass die Seiten unverändert bleiben und ihrem Ursprung korrekt zugeordnet werden. Alle potenziell personenidentifizierbaren Informationen werden verborgen, bis der Nutzer eine Website aufgerufen hat. So wird seine Privatsphäre geschützt. Die Google Suche ist eine der ersten Funktionen für den SXG-Vorabruf. Für Websites, die einen großen Teil ihrer Zugriffe über die Google Suche erhalten, kann SXG ein wichtiges Werkzeug sein, um den Seitenaufbau zu beschleunigen. Wir hoffen, dass im Laufe der Zeit auch weitere Teilnehmende am Empfehlungsprogramm teilnehmen 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 von der Verbreitung überprüfen kann. Dadurch kann der Browser die URL der Ursprungswebsite in der Adressleiste anzeigen und nicht die URL des Servers, über den der Inhalt bereitgestellt wurde.

Diagramm zur Funktionsweise von Signed Exchanges. Browser kommuniziert mit dem Cache, der mit der Zielwebsite kommuniziert

In der Vergangenheit konnte eine Website ihre Inhalte nur über Dritte zur Verteilung ihrer Inhalte unter Beibehaltung der Attribution nutzen, wenn sie ihre SSL-Zertifikate mit dem Distributor teilen. Dies hat Sicherheitsmängel. Darüber hinaus ist es weit entfernt, Inhalte wirklich portabel zu machen.

Das SXG-Format

Ein SXG wird in eine binär codierte Datei gekapselt, die zwei Hauptkomponenten hat: einen HTTP-Austausch und eine Signatur, die den Datenaustausch abdeckt. Der HTTP-Austausch umfasst eine Anfrage-URL, Informationen zu Inhaltsaushandlungen und eine HTTP-Antwort.

Hier 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 expires-Parameter in der Signatur gibt das Ablaufdatum eines SXG an. Ein SXG kann höchstens 7 Tage lang gültig sein. Weitere Informationen zum Signaturheader finden Sie in der Spezifikation für Signed HTTP Exchanges.

Unterstützung für serverseitige Personalisierung

Eine SXG-Datei mit einem Vary: Cookie-Header wird nur Nutzern angezeigt, die keine Cookies für die URL der signierten Anfrage haben. Wenn deine Website angemeldeten Nutzern anderen HTML-Code bietet, kannst du mit dieser Funktion SXGs nutzen, ohne dass sich das ändert. Weitere Informationen zur serverseitigen Personalisierung mit Dynamic SXG finden Sie hier.

Web-Paketerstellung

SXG ist Teil der umfassenden Web Packaging-Spezifikationsangebotsfamilie. Neben SXGs ist die weitere Hauptkomponente der Web Packaging-Spezifikation Web Bundles (gebündelte HTTP-Börsen). Web Bundles sind eine Sammlung von HTTP-Ressourcen und den Metadaten, die zur Interpretation des Bundles erforderlich sind.

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

Beschleunigter Seitenaufbau mit Signed Exchanges

Wenn Sie Signed Exchanges aktivieren, können Sie die Webseitenleistung beschleunigen und dadurch die Core Web Vitals Ihrer Website beeinträchtigen, z. B. beim Largest Contentful Paint (LCP). Als einer der ersten Nutzer der Google Suche nutzt die Google Suche SXG, um Seiten, die über die Suchergebnisseite geladen werden, schneller zu laden.

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

SXG funktioniert am besten in Kombination mit anderen Leistungsoptimierungen wie der Verwendung von CDNs und der Reduzierung von Unterressourcen, die das Rendering blockieren. Folge nach der Implementierung diesen Empfehlungen, um den LCP-Vorteil durch den Vorabruf von SXGs zu maximieren. In vielen Fällen kann eine solche Optimierung dazu führen, dass Seiten fast sofort aus der Google Suche geladen werden:

Auswirkungen von Signed Exchanges

In früheren Tests haben wir festgestellt, dass der LCP-Wert bei SXG-fähigen Prefetches durchschnittlich um 300 bis 400 ms sinkt. Dies trägt dazu bei, dass Websites einen besseren ersten Eindruck bei Nutzern machen, und wirkt sich häufig positiv auf die Geschäftsmesswerte aus.

Mehrere globale Marken und Websites profitieren bereits von Signed Exchanges. Sehen wir uns als Fallstudie an, wie das bekannte Content-Management-System (CMS) RebelMouse durch die Implementierung von Signed Exchanges die Leistung und die Geschäftsmesswerte seiner Kunden verbessern konnte:

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

Cloudflare stellte fest, dass SXG die TTFB bei 98% der getesteten Websites und bei 85% der Websites den LCP-Wert verbesserte. Der Medianwert der Seitenladevorgänge, die für SXG zulässig sind, beträgt über 20 %.

Indexierung

Die SXG- und die Nicht-SXG-Darstellung einer Seite wird von der Google Suche weder unterschiedlich eingestuft noch indexiert. SXG dient letztendlich der Übermittlung – es ändert nichts an den zugrunde liegenden Inhalten.

AMP

AMP-Inhalte können mit SXG übermittelt werden. Mit SXG können AMP-Inhalte über ihre kanonische URL statt über ihre AMP-URL vorab abgerufen und angezeigt werden.AMP hat eigene Tools zum Generieren von SXGs.Unter amp.dev erfahren Sie, wie AMP-Inhalte über Signed Exchanges bereitgestellt werden.

SXGs mit den Chrome-Entwicklertools debuggen

Wenn du dir einen SXG aus erster Hand ansehen möchtest, verwende einen Chromium-Browser, öffne die Entwicklertools, öffne den Bereich „Netzwerk“ und rufe dann diese Beispielsuchseite auf. Signed Exchanges lassen sich an dem Wert signed-exchange in der Spalte Type (Typ) erkennen.

Screenshot einer SXG-Anfrage im Bereich „Network“ der Entwicklertools
Im Bereich Netzwerk in den Entwicklertools

Auf dem Tab Vorschau findest du weitere Informationen zum Inhalt eines SXG.

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

Tools

Bei der Implementierung von SXGs wird der SXG generiert, der einer bestimmten URL entspricht, und diesen SXG dann den Anfragenden (in der Regel Crawler) bereitstellen.

Zertifikate

Zum Generieren eines SXG benötigst du ein Zertifikat, das SXGs signieren kann. Einige Tools erwerben diese jedoch automatisch. Auf dieser Seite sind die Zertifizierungsstellen aufgeführt, die diese Art von Zertifikat ausstellen können. Zertifikate können automatisch über einen beliebigen ACME-Client von der Google-Zertifizierungsstelle erworben werden. Web Packager Server hat einen integrierten ACME-Client. sxg-rs wird bald verfügbar sein.

Plattformspezifische SXG-Tools

Diese Tools unterstützen bestimmte Technology Stacks. Wenn Sie bereits eine Plattform verwenden, die von einem dieser Tools unterstützt wird, ist die Einrichtung möglicherweise einfacher als die Einrichtung eines universellen Tools.

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 aus dem Back-End und antwortet mit einem SXG. Installationsanweisungen finden Sie in der Readme-Datei.

Web Packager-Server

Der Web Packager Server, webpkgserver, ist eine Alternative zum in Go geschriebenen 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-CLI generiert einen SXG, der 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 kannst du deinen eigenen SXG-Generator erstellen:

  • sxg_rs ist eine Rust-Bibliothek zum Generieren von SXGs. Sie ist die leistungsstärkste SXG-Bibliothek und bildet die Grundlage für die cloudflare_worker- und fastly_compute-Tools.

  • 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. Sie wird als Grundlage für das Referenz-CLI-Tool gen-signedexchange und die funktionsreichen Web Packager-Tools verwendet.

Aushandlung von Inhalten

Server sollten SXG liefern, wenn der Header Accept anzeigt, 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 das, dass ein Ursprungsserver SXG für Crawler bereitstellt, nicht jedoch für Browser. Viele der oben genannten Tools tun dies standardmäßig. Bei anderen Tools kann der folgende reguläre Ausdruck verwendet werden, um den Header „Accept“ 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.

Cache API aktualisieren

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 abgelaufen sind. Weitere Informationen finden Sie in der Referenz zur Cache-API-Aktualisierung.

Mit SXG verknüpfen

Jede Website kann die SXGs der verlinkten Seiten 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 erfahren Sie, wie Sie SXGs mit nginx verteilen.

Einzigartige Vorteile

SXG ist eine von vielen möglichen Technologien, die ursprungsübergreifenden Prefetch ermöglichen. Bei der Entscheidung, welche Technologie Sie verwenden möchten, müssen Sie möglicherweise Kompromisse bei der Optimierung verschiedener Aspekte eingehen. In den folgenden Abschnitten werden einige der eindeutigen Werte beschrieben, die SXG im Hinblick auf mögliche Lösungen bietet. Diese Faktoren können sich im Laufe der Zeit ändern, wenn sich die verfügbaren Lösungen weiterentwickeln.

Weniger zu verarbeitende Anfragen

Beim websiteübergreifenden Vorabruf muss Ihr Server möglicherweise zusätzliche Anfragen verarbeiten. Das entspricht in Fällen, in denen eine Seite per Prefetch abgerufen wurde, der Nutzer sie aber nicht besucht hat oder die vorab abgerufenen Bytes dem Nutzer nicht angezeigt werden konnten. Bei SXG können diese zusätzlichen nicht verwendeten Anfragen deutlich 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 auf deiner Website sowohl mit als auch ohne Cookies angezeigt werden. Dadurch gibt es weniger Fälle, in denen die Seite nach der Navigation noch einmal abgerufen werden muss.

Verbesserung der Seitengeschwindigkeit

Aufgrund der derzeit unterstützten Prefetch-Oberflächen und ‐Funktionen kann die Seitengeschwindigkeit weiter verbessert werden:

  • SXGs können Nutzern mit Cookies für deine Website angezeigt werden.
  • SXG ruft außerdem Unterressourcen für Ihre Seiten wie JavaScript, CSS, Schriftarten und Bilder vorab ab, wenn dies mit einem Link-Header angegeben wird.
  • In naher Zukunft wird der SXG-Vorabruf aus der Google Suche bei weiteren Suchergebnistypen verfügbar sein.

Fazit

Signed Exchanges sind ein Übermittlungsmechanismus, mit dem der Ursprung und die Gültigkeit einer Ressource unabhängig von ihrer Zustellung geprüft werden können. Infolgedessen können SXGs unter Beibehaltung der vollständigen Publisher-Zuordnung von Drittanbietern vertrieben werden.

Weitere Informationen