Inhaltsverzeichnis

Stelle AMP via Signed Exchanges bereit

Important: this documentation is not applicable to your currently selected format stories!

AMP bietet Geschwindigkeitsvorteile weit über das Format hinaus. Dazu werden Methoden wie Caching und Vorladen eingesetzt. Doch diese Vorteile können auch Nachteile haben: So werden z. B. zusätzliche URLs angezeigt, wenn die Seite in einem AMP Viewer eingebettet ist. Um solche Probleme zu vermeiden, kannst du ein neues Web Plattform Feature nutzen und AMP Inhalte über Signed Exchanges bereitstellen.

Ein Signed Exchange besteht aus einem gültigen AMP Dokument und der ursprünglichen URL des Contents. Diese Informationen sind durch digitale Signaturen geschützt, die das Dokument auf sichere Weise an die zugehörige URL binden. Auf diese Weise können Browser die ursprüngliche URL sicher in der URL Zeile anstelle des Hostnamens des Computers anzeigen, der die Bytes an den Browser übermittelt hat.

Signierte AMP Inhalte werden zusätzlich zu (und nicht anstelle von) regulären AMP Inhalten bereitgestellt.

Diese Funktion wird derzeit in Chrome unterstützt. Die Implementierung ist jedoch bereits für weitere Browser geplant.

Kann auch ich Signed Exchanges verwenden?

Um Signed Exchanges zu implementieren, musst du die folgenden Anforderungen erfüllen:

Es muss möglich sein, die von deinem Server generierten HTTP Header zu konfigurieren und zu steuern. (Die meisten rein webbasierten Hosting Lösungen wie Blogger sind nicht mit Signed Exchanges kompatibel.)
Es muss möglich sein, AMP Signed Exchanges zu generieren, z. B. durch Ausführen von amppackager, als Go Binärdatei oder innerhalb einer Docker VM.
Der Packager muss alle sechs Wochen aktualisiert werden.
Es muss möglich sein, Vary in den Headern Accept und AMP-Cache-Transform auf Edge HTTP Servern zu verwenden und verschiedene Inhalte für die gleiche URL zurückzugeben.
Das System, auf dem amppackager ausgeführt wird, muss in der Lage sein, ausgehende Netzwerkanforderungen an die folgenden Empfänger zu stellen:
die Zertifizierungsstelle, die dein Zertifikat ausstellt,
den Publisher Server, auf dem die zu signierenden AMP Dokumente gehostet werden,
cdn.ampproject.org, um die aktuelle Version von AMP abzurufen.
Ein permanentes Dateisystem mit gemeinsam genutztem Speicher zwischen allen Instanzen von amppackager, die im selben Rechenzentrum ausgeführt werden, muss vorhanden sein.

Implementierung von Signed Exchanges

Nachfolgend findest du eine vorgeschlagene Implementierungsreihenfolge, um Signed Exchanges für deine AMP Dokumente zu unterstützen.

Beziehe ein unterstütztes TLS Zertifikat

Um Signed Exchanges zu ermöglichen, benötigst du ein TLS Zertifikat mit der Erweiterung CanSignHttpExchanges. Im April 2019 war DigiCert der einzige Anbieter dieser Erweiterung (weitere Informationen dazu).

Um das Zertifikat zu generieren, benötigt die Certificate Authority (CA) ein Certificate Signing Request (CSR), welches mit openssl erzeugt werden kann. Hier ist ein Beispiel für ein CSR für ampbyexample.com:

# generate private key (if necessary)

$ openssl ecparam -out ampbyexample-packager.key -name prime256v1 -genkey
# generate CSR (the file ampbyexample-packager.csr)

$ openssl req -new -key ampbyexample-packager.key -nodes -out ampbyexample-packager.csr -subj "/C=US/ST=California/L=Mountain View/O=Google LLC/CN=ampbyexample.com"

Bestimme, welche URLs signiert werden sollen

Du musst ein URL Muster erstellen, das festlegt, welche Dokumente signiert werden sollen. Es ist wichtig, dass private Inhalte wie personalisierte Informationen nicht signiert werden, um den Versand irreführender oder falscher Inhalte zu verhindern.

Für bessere Leistung sollten dem Packager nur gültige AMP Dokumente als Eingabe übergeben werden. Die Übermittlung einiger ungültiger AMP Dokumente ist akzeptabel, falls unbedingt erforderlich, aber du solltest es vermeiden, den gesamten Datenverkehr über den Packager zu senden.

Stelle den Packager auf einem Staging Server bereit

Zunächst solltest du Signed Exchanges auf einem Staging Server einrichten, um zu überprüfen, ob dein Setup korrekt ist, bevor du zur Produktion übergehst.

Wir empfehlen die Verwendung von amppackager zur Generierung von Signed Exchanges. Wenn dies jedoch nicht zu deiner Produktionsumgebung passt, kannst du stattdessen die Befehlszeilenclients transform und gen-signedexchange nutzen und die mit Content Negotiation und Zertifikatsverwaltung verbundenen Aufgaben selbst übernehmen.

Die folgende Anleitung gilt für Bereitstellungen mit amppackager.

Konfiguration

Die Konfigurationsdatei von amppackager (amppkg.toml) fordert eine CertFile und eine KeyFile an.

Die KeyFile ist der private Schlüssel (ampbyexample-packager.key im obigen Beispiel) und sollte das folgende Format haben (Hinweis: Teile deinen eigenen privaten Schlüssel mit niemandem und schütze ihn vor unbeabsichtigter Veröffentlichung!):

Die CertFile ist das öffentliche Zertifikat. Wenn DigiCert das Zertifikat bereitgestellt hat, kann diese Datei durch Verketten des von DigiCert bereitgestellten ursprungsspezifischen Zertifikats und der Datei DigiCertCA.crt erstellt werden.

Installation

Befolge diese Anleitung, um amppackager für deine Website einzurichten.

In packager.js (verwendet von amp.dev) findest du ein Beispiel für die serverseitigen Änderungen, die du vornehmen musst, um die erforderlichen Anfragen an amppkg weiterzuleiten.

Tests

Stelle sicher, dass deine Staging Website mit Inhalt mit dem MIME Typ application/signed-exchange antwortet, wenn dies in der HTTP Anfrage angegeben ist. Ein Beispiel (ersetze staging.example.com durch deinen Staging Server):

$ curl -si -H 'amp-cache-transform: google;v="1..100"' -H 'accept: application/signed-exchange;v=b3;q=0.9,*/*;q=0.8' https://staging.example.com/ | less

Die Ausgabe muss folgende Zeile enthalten:

content-type: application/signed-exchange;v=b3

Das Element v="1..100" in der Anfrage ist ein Platzhalter. Suche nicht nach Übereinstimmungen anhand dieses konkreten Wertes. Überprüfe stattdessen (wie in der Installationsanleitung von amppackager beschrieben), ob der Header amp-cache-transform vorhanden ist, und ignoriere den Wert.

Die Versionszeichenfolge v=b3 in der Antwort ist die Version vom August 2019. Diese Version unterliegt Änderungen.

Der Großteil der Antwort sollte aus deiner AMP Seite bestehen (im Klartext). Sie besitzt einen kleinen binären Header und enthält hier und da noch einige Binärbytes, falls die Seite größer ist als 16 KB.

Das Tool dump-signedexchange kann dazu verwendet werden, die Antwort zu überprüfen:

$ curl -s --output - -H 'amp-cache-transform: google;v="1..100"' -H 'accept: application/signed-exchange;v=b3;q=0.9,*/*;q=0.8' https://staging.example.com/ > example.sxg
$ dump-signedexchange -i example.sxg
format version: 1b3

(Beachte, dass der Schalter -verify zu diesem Zeitpunkt nicht funktioniert, da sich die erforderlichen Zertifikate nicht auf dem Server https://example.com/ befinden.)

Stelle sicher, dass die Antwort immer den Header Vary mit dem Wert Accept,AMP-Cache-Transform enthält (unabhängig davon, ob der MIME Typ text/html, application/signed-exchange oder ein anderer ist):

$ curl -si https://staging.example.com/ | less

Die Ausgabe muss folgende Zeile enthalten:

vary: Accept,AMP-Cache-Transform

Stelle den Packager in der Produktion bereit

Installation

Passe die oben genannten Bereitstellungsschritte für Staging an deine Produktionsumgebung an.

Tests

Mit Befehlszeilentools

Führe die gleichen Tests wie oben durch. dump-signedexchange -verify sollte jetzt erfolgreich sein.

Mit Chrome

Du kannst den Test auch in Chrome mithilfe der Erweiterung ModHeader durchführen. Installiere sie aus dem Chrome Webstore und konfiguriere die Request Headers für amp-cache-transform mit google als Value.

Nach der Anforderung von https://example.com/ stellt dein Server ein Signed Exchange bereit, welches jedoch genauso aussehen und sich genauso verhalten muss wie zuvor. Überprüfe über die DevTools Konsole, ob ein Signed Exchange korrekt zurückgegeben wird.

Klicke auf dem Tab Network auf deinen Domänennamen und überprüfe, ob Signed HTTP exchange unter Preview angezeigt wird.

Mit dem Google AMP Cache

Stelle sicher, dass die Signed Exchanges mit dem Google AMP Cache kompatibel sind. Das ist für ihre Auffindbarkeit in Suchmaschinen wie der Google-Suche relevant.

Um Signed Exchanges im Google AMP Cache zu testen, öffne die Registerkarte "Network" in DevTools, aktiviere "Preserve log" und rufe eine URL wie https://example-com.cdn.ampproject.org/wp/s/example.com/ auf.

DevTools zeigt eine 200 mit der Zeile signed-exchange sowie die Zeile from signed-exchange an, falls die Anfrage erfolgreich war.

Wenn dies fehlschlägt, fehlen die Zeilen "signed-exchange" oder werden rot hervorgehoben. Es kann auch sein, dass der Header warning mit zusätzlichen Informationen vorhanden ist.

Signed Exchanges in der Google-Suche

Wenn deine AMP Seiten erfolgreich als Signed Exchanges verteilt wurden, wird in den Suchergebnissen wie zuvor der AMP Blitz angezeigt. Ein Antippen der Ergebnisse zeigt jedoch in der URL Zeile anstelle einer URL, die mit https://www.google.com/amp/…. beginnt, die URL https://example.com an. Außerdem wird die Leiste viewer nicht angezeigt.

In der DevTools Konsole siehst du im Tab network in der Spalte type den Eintrag signed-exchange.

Anbieter von Signed Exchange Diensten

Hier ist eine Liste mit CDNs und Hosting Anbietern, die umfassende Unterstützung für Signed Exchanges bieten. Das ist die einfachste Methode für die ersten Schritte mit Signed Exchanges:

AMP Packager Google Cloud Click-to-Deploy Installer AMP Packager ist ein Tool, das AMP URLs optimiert, indem AMP mithilfe von Signed Exchanges bereitgestellt wird. Erfahre mehr im AMP Blog.
Cloudflare AMP Real URL. Cloudflare ist eines der größten Netzwerke der Welt. Unternehmen, gemeinnützige Organisationen, Blogger und sonstige Personen mit Internetpräsenz haben heute dank Cloudflare schnellere und sicherere Websites und Apps.

Written by @CrystalOnScript