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 Art der Übermittlung 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 von Inhalten aus Drittanbieter-Caches.

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. Dadurch kann der Browser die URL der ursprünglichen Website in der Adressleiste anzeigen, anstatt die URL des Servers, von dem die Inhalte gesendet wurden.

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 Sicherheitsnachteile und ist weit davon entfernt, Inhalte wirklich portabel zu machen.

SXG-Format

Eine SXG-Datei 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 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 kann maximal 7 Tage gültig sein. Weitere Informationen zum Signaturheader finden Sie in der Spezifikation für signierte HTTP-Austausche.

Unterstützung für die 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 („bündelte HTTP-Austausche“) die zweite wichtige Komponente der Web Packaging-Spezifikation. 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.

Seitenladezeiten mit Signed Exchanges verkürzen

Wenn Sie signierte Anzeigen aktivieren, lässt sich die Leistung von Webseiten verbessern und damit auch die Core Web Vitals Ihrer Website, insbesondere der 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 renderblockierenden Unterressourcen. Folgen Sie nach der Implementierung diesen Empfehlungen, um den LCP-Vorteil durch das Vorabladen von SXGs zu maximieren. In vielen Fällen kann eine solche Optimierung dazu führen, dass Seiten aus der Google Suche fast sofort geladen werden:

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. So hinterlassen Websites bei Nutzern einen besseren ersten Eindruck und das hat oft positive Auswirkungen auf die Geschäftsmesswerte.

Mehrere globale Marken und Websites profitieren bereits von Signed Exchanges. 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: Seitenladezeit um 21%reduziert

Cloudflare hat festgestellt, dass SXG die TTFB für 98% der getesteten Websites und den LCP für 85% der Websites verbessert hat. Bei Seitenladezeiten, die für SXG infrage kommen, wurde eine mittlere Verbesserung von über 20% erzielt.

Indexierung

Die SXG- und nicht SXG-Darstellungen einer Seite werden in der Google Suche nicht unterschiedlich bewertet oder 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 ihrer kanonischen URL statt ihrer 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 einer SXG-Anfrage im Bereich „Netzwerk“ in den DevTools
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 einem beliebigen ACME-Client automatisch von der Zertifizierungsstelle von Google 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.

SXG-Tools für allgemeine Zwecke

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 dient als Grundlage für das Referenz-Befehlszeilentool gen-signedexchange und die funktionsreicheren Web Packager-Tools.

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 ausliefert. 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.

Update-Cache-API

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“.

Verknüpfung mit SXG

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 das Angebot an verfügbaren Lösungen weiterentwickelt.

Weniger Anfragen

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 sowohl mit als auch ohne Cookies auf Ihrer Website angezeigt werden. So muss die Seite nach der Navigation seltener noch einmal abgerufen werden.

Verbesserung der Seitengeschwindigkeit

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

  • SXGs können Nutzern mit Cookies für Ihre Website präsentiert werden.
  • SXG lädt auch Unterressourcen für Ihre Seiten wie JavaScript, CSS, Schriftarten und Bilder vorab, wenn sie mit einer Link-Überschrift angegeben werden.
  • In naher Zukunft wird das SXG-Prefetching 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