Signed Exchanges (SXGs)

Ein SXG ist ein Bereitstellungsmechanismus, mit dem der Ursprung einer Ressource unabhängig von der Art und Weise, wie sie bereitgestellt wurde, authentifiziert werden kann.

Katie Hempenius
Katie Hempenius
X
Devin Mullins
Devin Mullins
X GitHub

Signierte Nachrichten (Signed Exchanges, SXG) sind ein Übermittlungsmechanismus, mit dem der Ursprung einer Ressource unabhängig von der Übermittlungsweise authentifiziert werden kann. Durch die Implementierung von SXG lässt sich der LCP-Wert (Largest Contentful Paint) verbessern, da datenschutzfreundlicher plattformübergreifender Prefetch aktiviert wird. Außerdem ermöglicht diese Entkopplung eine Vielzahl von Anwendungsfällen, z. B. die Offlinenutzung des Internets und das Bereitstellen aus Caches von Drittanbietern.

In diesem Artikel erhalten Sie einen umfassenden Überblick über SXG: Funktionsweise, Anwendungsfälle und Tools.

Browserkompatibilität

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

Übersicht

Als primären Anwendungsfall verwendet SXG einen Cache, um Inhalte, die vom Ursprung kryptografisch signiert wurden, vorab abzurufen und bereitzustellen. So wird die plattformübergreifende Navigation von Verweis-Websites beschleunigt und gleichzeitig dafür gesorgt, dass Seiten unverändert bleiben und der richtigen Quelle zugeordnet werden. Potenziell personenidentifizierbare Informationen werden erst angezeigt, wenn der Nutzer eine Website aufruft. So wird die Privatsphäre des Nutzers geschützt. Die Google Suche ist ein früher Anwender der SXG-Prefetch-Funktionen. Für Websites, die einen großen Teil ihrer Zugriffe über die Google Suche erhalten, kann SXG ein wichtiges Tool sein, um Nutzern ein schnelleres Seitenladen zu ermöglichen. Wir hoffen, dass sich diese Auswirkungen mit der Zeit auf weitere Verweisquellen ausweiten.

So gehts

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

Diagramm, das die Funktionsweise von signierten Anzeigenaustauschen veranschaulicht Browser, der mit dem Cache kommuniziert, der mit der Zielwebsite kommuniziert

Bisher war die einzige Möglichkeit für eine Website, Inhalte über einen Drittanbieter zu verteilen und gleichzeitig die Attribution beizubehalten, die SSL-Zertifikate der Website mit dem Distributor zu teilen. Das hat auch Sicherheitsrisiken. Darüber hinaus ist es noch viel weiter, als Inhalte wirklich übertragbar zu machen.

SXG-Format

Eine SXG-Datei ist in einer binär codierten Datei gekapselt, die zwei Hauptkomponenten enthält: 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 sehen Sie 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 ist unter Umständen maximal 7 Tage lang gültig. Weitere Informationen zum Signatur-Header finden Sie in der Spezifikation für signierte HTTP-Austausche.

Unterstützung für serverseitige Personalisierung

Ein SXG mit einem Vary: Cookie-Header wird nur Nutzern angezeigt, die keine Cookies für die signierte Anfrage-URL haben. Wenn auf Ihrer Website für angemeldete Nutzer eine andere HTML-Seite angezeigt wird, können Sie diese Funktion nutzen, um SXGs zu verwenden, ohne die Nutzererfahrung zu ändern. Weitere Informationen zur serverseitigen Personalisierung mit dynamischen SXGs

Web-Verpackung

SXG ist Teil der breiteren Spezifikationsfamilie Web Packaging. Neben SXGs sind Web Bundles („gebündelte HTTP-Austausche“) die andere wichtige Komponente der Spezifikation für Web Packaging. Web-Bundles sind eine Sammlung von HTTP-Ressourcen und die Metadaten, die zur Interpretation des Bundles erforderlich sind.

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

Beschleunigung des Seitenaufbaus mit Signed Exchanges

Wenn Sie Signed Exchanges aktivieren, kann die Leistung von Webseiten beschleunigt und damit die Core Web Vitals Ihrer Website beeinträchtigt werden, insbesondere Largest Contentful Paint (LCP). Als Early Adopter nutzt die Google Suche SXG, um Nutzern einen schnelleren Seitenaufbau für Seiten zu bieten, die über die Suchergebnisseite geladen werden.

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

SXG funktioniert am besten in Kombination mit anderen Leistungsoptimierungen wie der Verwendung von CDNs und der Reduzierung von Unterressourcen, die das Rendering blockieren. Folgen Sie nach der Implementierung diesen Empfehlungen, um den LCP-Vorteil durch den Vorabruf von SXGs zu maximieren. In vielen Fällen führt eine solche Optimierung dazu, dass die Seite nahezu sofort über die Google Suche geladen wird:

Auswirkungen von Signed Exchanges

In früheren Tests konnten wir eine durchschnittliche LCP-Reduzierung von 300 ms bis 400 ms durch SXG-fähige Prefetches feststellen. Dies trägt dazu bei, dass Websites einen besseren ersten Eindruck bei den Nutzern machen, und wirkt sich häufig positiv auf die Geschäftskennzahlen aus.

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

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

Cloudflare stellte fest, dass SXG die TTFB für 98% der getesteten Websites und den LCP für 85% der Websites verbesserte, wobei der Medianwert für den Seitenaufbau, der für SXG geeignet ist, um mehr als 20% verbessert wurde.

Indexierung

Die SXG- und Nicht-SXG-Darstellungen einer Seite werden von der Google Suche weder unterschiedlich eingestuft noch indexiert. SXG ist letztendlich ein Bereitstellungsmechanismus – die zugrunde liegenden Inhalte werden nicht geändert.

AMP

AMP-Inhalte können mit SXG ausgeliefert werden. Mit SXG können AMP-Inhalte vorab abgerufen und anhand der kanonischen URL statt der AMP-URL angezeigt werden. AMP hat eigene Tools zum Generieren von SXGs. Informationen zum Bereitstellen von AMP mithilfe von Signed Exchanges finden Sie auf amp.dev.

SXGs mit Chrome-Entwicklertools debuggen

Wenn Sie sich ein SXG selbst ansehen möchten, verwenden Sie einen Chromium-Browser, öffnen Sie die DevTools, öffnen Sie den Bereich „Netzwerk“ und rufen Sie diese Beispielsuchseite auf. Unterzeichnete Anzeigenaufträge sind in der Spalte Typ durch den Wert signed-exchange gekennzeichnet.

Screenshot mit einer SXG-Anfrage im Bereich „Network“ der Entwicklertools
Der Bereich Netzwerk in den DevTools

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

Screenshot des Tabs „Vorschau“ für eine SXG
Tab Vorschau in den DevTools

Tools

Die Implementierung von SXGs besteht darin, das SXG für eine bestimmte URL zu generieren und dann für Anfragende (in der Regel Crawler) bereitzustellen.

Zertifikate

Zum Generieren eines SXG benötigen Sie ein Zertifikat, mit dem SXGs signiert werden können. Einige Tools erwerben diese automatisch. Auf dieser Seite sind die Zertifizierungsstellen aufgeführt, die diese Art von Zertifikat ausstellen können. Zertifikate können mit jedem ACME-Client automatisch von der Google-Zertifizierungsstelle abgerufen werden. Der Web Packager Server hat einen integrierten ACME-Client und sxg-rs wird demnächst einen haben.

Plattformspezifische SXG-Tools

Diese Tools unterstützen bestimmte Technologiestacks. Wenn Sie bereits eine Plattform verwenden, die von einem dieser Tools unterstützt wird, ist die Einrichtung möglicherweise einfacher als bei einem allgemeinen Tool.

Allzweck-SXG-Tools

sxg-rs-HTTP-Server

Der sxg-rs http_server fungiert als Reverse-Proxy für das Bereitstellen 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 Alternative zum sxg-rs http_server, der in Go geschrieben wurde. Eine Anleitung zum Einrichten des Web Packager-Servers findest du unter How to set up signed exchanges using Web Packager (nur auf Englisch verfügbar).

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 müssen Sie 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 dient als Grundlage für das NGINX SXG-Modul und den Envoy SXG-Filter.

  • go/signed-exchange ist eine minimale Go-Bibliothek, die von der Webpaketspezifikation als Referenzimplementierung zum Generieren von SXGs bereitgestellt wird. Es wird als Basis für das Referenz-CLI-Tool gen-signedexchange und die leistungsfähigeren 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 das, dass ein Ursprungsserver SXG an Crawler, aber nicht an Browser sendet. Viele der oben genannten Tools tun dies standardmäßig. Bei anderen Tools kann der folgende reguläre Ausdruck verwendet werden, um den Accept-Header von Anfragen abzugleichen, die als SXG gesendet 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 bietet 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 für „update cache“.

Mit SXG verknüpfen

Jede Website kann SXGs der Seiten, auf die sie verlinkt, mithilfe der - und -Tags im Cache speichern, ausliefern und vorab abrufen, sofern verfügbar: 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 gezeigt, wie Sie SXGs mit nginx verteilen.

Einzigartige Vorteile

SXG ist eine von vielen möglichen Technologien, die plattformübergreifendes Prefetching 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 der möglichen Lösungen bietet. Diese Faktoren können sich im Laufe der Zeit ändern, wenn sich die verfügbaren Lösungen weiterentwickeln.

Weniger Anfragen zur Auslieferung

Bei websiteübergreifendem Prefetching muss Ihr Server möglicherweise zusätzliche Anfragen bedienen. Dies entspricht Fällen, in denen eine Seite vorab abgerufen wurde, der Nutzer die Seite 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. So können viele Vorab-Ladevorgänge ausschließlich vom Cache-Server verarbeitet werden.
  • SXGs können Nutzern mit und ohne Cookies auf Ihrer Website angezeigt werden. Auf diese Weise muss die Seite nach der Navigation seltener abgerufen werden.

Verbesserung der Seitengeschwindigkeit

Möglicherweise lässt sich die Seitenladegeschwindigkeit durch die derzeit unterstützten Oberflächen und Funktionen für das Prefetching weiter verbessern:

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

Fazit

Signierte Anzeigenaufträge sind ein Übermittlungsmechanismus, mit dem der Ursprung und die Gültigkeit einer Ressource unabhängig davon überprüft werden kann, wie die Ressource übermittelt wurde. So können SXGs von Drittanbietern verteilt werden, während die vollständige Publisher-Attribution beibehalten wird.

Weitere Informationen