LCP mithilfe von Signed Exchanges optimieren

Signed Exchange-Anzeigen analysieren und optimieren, um sie bestmöglich zu nutzen

Devin Mullins

Mit Signed Exchanges (SXGs) können Sie die Seitengeschwindigkeit verbessern – hauptsächlich mit dem Largest Contentful Paint (LCP). Wenn verweisende Websites (derzeit die Google Suche) auf eine Seite verweisen, können sie die Seite vorab in den Cache des Browsers abrufen, bevor der Nutzer auf den Link klickt.

Es ist möglich, Webseiten zu erstellen, die beim Prefetching kein Netzwerk auf dem kritischen Pfad zum Rendern der Seite erfordern. Bei einer 4G-Verbindung dauert der Seitenaufbau von 2,8 s auf 0,9 s (die verbleibenden 0,9 s hängen hauptsächlich von der CPU-Nutzung ab):

Hinweis:Bisher wurde in diesem Beitrag eine Verbesserung von 6 Sekunden auf 0, 9 Sekunden gezeigt. Das stimmt, aber die zu testende Website war zu diesem Zeitpunkt ungewöhnlich langsam. Sie können jedoch als Beispiel für Seiten mit mehr Unterressourcen, langsameren Servern oder Nutzern mit langsameren Verbindungstypen dienen.

Die meisten Nutzer, die SXGs veröffentlichen, nutzen die benutzerfreundliche Automatic Signed Exchanges (ASX)-Funktion von Cloudflare (auch wenn es auch Open-Source-Optionen gibt):

In vielen Fällen reicht es aus, das Kontrollkästchen zum Aktivieren dieser Funktion zu aktivieren, um die oben gezeigte wesentliche Verbesserung zu erzielen. Manchmal sind noch einige weitere Schritte erforderlich, um sicherzustellen, dass diese SXGs in jeder Phase der Pipeline wie vorgesehen funktionieren, und um die Seiten so zu optimieren, dass sie den Prefetch voll nutzen können.

In den letzten Monaten nach der Einführung von Cloudflare habe ich in verschiedenen Foren Fragen gelesen und beantwortet. Außerdem habe ich gelernt, wie ich Websites beraten kann, wie sie ihre SXG-Bereitstellungen optimal nutzen können. In diesem Beitrag habe ich meine Ratschläge zusammengefasst. Ich werde die einzelnen Schritte durchgehen, um:

• Analysiere die SXG-Leistung mit WebPageTest.
• Fehler in der SXG-Pipeline beheben, wenn der Schritt „Analysieren“ zeigt, dass sie nicht funktioniert.
• Optimieren Sie Seiten für SXG-Prefetch, einschließlich der Festlegung einer optimalen max-age und dem Vorabladen von Unterressourcen, die das Rendering blockieren.
• Messen Sie die SXG-Verbesserung mit Google Analytics, indem Sie geeignete Test- und Kontrollgruppen auswählen.

Einleitung

Eine SXG-Datei ist eine Datei mit einer URL, einer Reihe von HTTP-Antwortheadern und einem Antworttext, die alle kryptografisch von einem Web-PKI-Zertifikat signiert sind. Wenn der Browser einen SXG lädt, prüft er Folgendes:

• Der SXG ist noch gültig.
• Die Signatur entspricht der URL, den Headern, dem Textkörper und dem Zertifikat.
• Das Zertifikat ist gültig und stimmt mit der URL überein.

Wenn die Überprüfung fehlschlägt, bricht der Browser die SXG-Datei ab und ruft stattdessen die signierte URL ab. Wenn die Bestätigung erfolgreich ist, lädt der Browser die signierte Antwort und behandelt sie so, als käme sie direkt von der signierten URL. SXGs können dann auf jedem Server neu gehostet werden, solange sie seit der Signatur nicht abgelaufen oder geändert wurden.

Bei der Google Suche ermöglicht SXG den Vorabruf von Seiten in den Suchergebnissen. Bei Seiten, die SXGs unterstützen, kann die Google Suche die im Cache gespeicherte Kopie der Seite, die auf webpkgcache.com gehostet wird, vorab abrufen. Diese URLs von webpkgcache.com haben keinen Einfluss auf die Anzeige oder das Verhalten der Seite, da der Browser die ursprüngliche, signierte URL akzeptiert. Durch den Vorabruf kann Ihre Seite viel schneller geladen werden.

Hinweis:SXGs sind möglicherweise auch für andere Anwendungsfälle nützlich, die in diesem Artikel nicht behandelt werden. Beispielsweise könnte eine Chat-App einen Link herunterladen, der an einen Nutzer gesendet wurde, sofern die Seite SXG unterstützt. So kann er sich die App später offline ansehen. Liste mit möglichen Anwendungsfällen

Analysieren

Um die Vorteile von SXGs zu erkennen, solltest du zuerst ein Labortool verwenden, um die SXG-Leistung unter wiederholbaren Bedingungen zu analysieren. Sie können WebPageTest verwenden, um Vermittlungsabfolgen – und LCP – mit und ohne SXG-Prefetch zu vergleichen.

Achtung:Die Lab-Ergebnisse können sich von denen im echten Leben unterscheiden, sind aber nützlich, um herauszufinden, wo Optimierungsbedarf besteht, und um schnell zu iterieren. Im Abschnitt Messen erfahren Sie, wie Sie die resultierenden Nutzermesswerte messen können.

So erstellst du einen Test ohne SXG:

• Rufen Sie WebPageTest auf und melden Sie sich an. Wenn du dich anmeldest, wird dein Testverlauf gespeichert, damit du ihn später leichter vergleichen kannst.
• Geben Sie die URL ein, die Sie testen möchten.
• Gehen Sie zu Advanced Configuration (Erweiterte Konfiguration). Für den SXG-Test benötigst du die erweiterte Konfiguration. Wenn du sie hier verwendest, kannst du sicherstellen, dass die Testoptionen identisch sind.
• Im Tab Test Settings (Testeinstellungen) kann es hilfreich sein, die Verbindung auf 4G festzulegen und die Anzahl der auszuführenden Tests auf 7 zu erhöhen.
• Klicken Sie auf Test starten.

Generieren Sie einen Test mit SXG, indem Sie dieselben Schritte wie oben ausführen. Gehen Sie jedoch, bevor Sie auf Test starten klicken, zum Tab Script, fügen Sie das folgende WebPageTest-Skript ein und ändern Sie die beiden navigate-URLs wie angegeben:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

Falls Ihre Seite noch nicht in den Google-Suchergebnissen erscheint, können Sie für die erste navigate-URL diese Prefetch-Seite verwenden, um zu diesem Zweck eine gefälschte Suchergebnisseite zu generieren.

Um die zweite navigate-URL zu ermitteln, rufen Sie Ihre Seite mit der Chrome-Erweiterung „SXG Validator“ auf und klicken Sie auf das Erweiterungssymbol, um die Cache-URL aufzurufen:

Wenn diese Tests abgeschlossen sind, rufen Sie den Testverlauf auf, wählen Sie die beiden Tests aus und klicken Sie auf Vergleichen:

Hängen Sie &medianMetric=LCP an die Vergleichs-URL an, damit WebPageTest die Ausführung mit dem Medianwert des LCP für jede Seite des Vergleichs auswählt. (Standardwert ist der Medianwert für den Geschwindigkeitsindex.)

Maximieren Sie den Abschnitt Wasserfall-Deckkraft und ziehen Sie den Schieberegler, um Wasserfälle zu vergleichen. Wenn Sie sich das Video ansehen möchten, klicken Sie auf Filmstreifeneinstellungen anpassen, scrollen Sie im Dialogfeld nach unten und klicken Sie auf Video ansehen.

Wenn der SXG-Prefetch erfolgreich ist, sehen Sie, dass die Vermittlungsabfolge „mit SXG“ keine Zeile für den HTML-Code enthält und die Abrufe für Unterressourcen früher beginnen. Vergleichen Sie zum Beispiel die Werte "Vorher" und "Nach":

Debuggen

Wenn beim WebPageTest angezeigt wird, dass der SXG Prefetch wird, war er in allen Schritten der Pipeline erfolgreich. Sie können mit dem Abschnitt Optimieren fortfahren, um zu erfahren, wie Sie den LCP weiter verbessern können. Andernfalls müssen Sie herausfinden, an welcher Stelle in der Pipeline der Fehler aufgetreten ist und warum. Wie das geht, erfahren Sie im Folgenden.

Wird veröffentlicht

Achte darauf, dass deine Seiten als SXGs generiert werden. Dazu müsst ihr euch als Crawler ausgeben. Am einfachsten ist es, die Chrome-Erweiterung „SXG Validator“ zu verwenden:

Hinweis:SXGs sind für SXG-fähige Crawler gedacht, um den Vorabruf zu ermöglichen. Wenn Nutzer deine Website direkt besuchen, solltest du ihnen keine SXGs senden, da sie nicht per Prefetch abgerufen werden. Dies verursacht nur zusätzlichen Aufwand. Cloudflare ASX führt diese Inhaltsverhandlung automatisch durch.

Die Erweiterung ruft die aktuelle URL mit einem Accept-Anfrageheader ab, der besagt, dass die SXG-Version bevorzugt wird. Wenn neben „Origin“ ein Häkchen (✅) angezeigt wird, wurde ein SXG zurückgegeben. Du kannst dann mit dem Abschnitt Indexierung fortfahren.

Wenn ein Kreuz (❌) angezeigt wird, wurde kein SXG zurückgegeben:

Wenn Cloudflare ASX aktiviert ist, liegt der wahrscheinliche Grund für ein Kreuz (❌) darin, dass dies durch einen Cachesteuerungs-Antwortheader verhindert wird. ASX prüft Header mit den folgenden Namen:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

Enthält einer dieser Header einen der folgenden Werte, wird kein SXG generiert:

• private
• no-store
• no-cache
• max-age kleiner als 120, sofern nicht überschrieben durch s-maxage größer oder gleich 120

ASX erstellt in diesen Fällen kein SXG, da SXGs für mehrere Besuche und mehrere Besucher im Cache gespeichert und wiederverwendet werden können.

Ein weiterer möglicher Grund für ein Kreuz (❌) ist das Vorhandensein eines dieser zustandsorientierten Antwortheader mit Ausnahme von Set-Cookie. ASX entfernt den Set-Cookie-Header, um der SXG-Spezifikation zu entsprechen.

Hinweis: Diese Einschränkungen finden Sie im ASX-Code genauer. So werden beispielsweise Cache-Steuerungsheader durch den Code geprüft, der bestimmt, wann das Signieren erfolgt und wie die Signaturdauer beträgt. Andere Header werden vor dem Signieren durch diese Konfiguration oder über diesen Code entfernt. Andere Header verhindern die Signatur, wenn sie nicht anderweitig entfernt werden.

Eine weitere mögliche Ursache ist das Vorhandensein eines Vary: Cookie-Antwortheaders. Der Googlebot ruft SXGs ohne Anmeldedaten von Nutzern ab und zeigt sie möglicherweise mehreren Besuchern an. Wenn Sie verschiedenen Nutzern ausgehend von ihrem Cookie unterschiedlichen HTML-Code bereitstellen, wird den Nutzern möglicherweise ein Fehler angezeigt, z. B. wenn sie sich abgemeldet haben.

Hinweis:In Zukunft werden Seiten mit Vary: Cookie von SXG unterstützt und nur Besuchern ohne Cookies für deine Website angezeigt. Diese Funktion wurde in Chromium implementiert und wird in der Google Suche aktiviert, sobald diese vollständige Einführung abgeschlossen ist.

Alternativ zur Chrome-Erweiterung können Sie ein Tool wie curl verwenden:

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

oder dump-signedexchange:

dump-signedexchange -verify -uri $URL

Wenn der SXG vorhanden und gültig ist, wird ein visuell lesbarer Ausdruck des SXG angezeigt. Andernfalls wird eine Fehlermeldung angezeigt.

Indexierung

Prüfen Sie, ob Ihre SXGs von der Google Suche indexiert werden. Öffne die Chrome-Entwicklertools und führe eine Google Suche für deine Seite durch. Wenn sie als SXG indexiert wurde, enthält der Link von Google zu Ihrer Seite ein data-sxg-url, das auf die Kopie von webpkgcache.com verweist:

Wenn die Google Suche davon ausgeht, dass der Nutzer wahrscheinlich auf das Ergebnis klicken wird, wird es auch vorab abgerufen:

Mit dem Element <link> wird der Browser angewiesen, die SXG-Datei in den Prefetch-Cache herunterzuladen. Wenn der Nutzer auf das <a>-Element klickt, verwendet der Browser zum Rendern der Seite diesen im Cache gespeicherten SXG.

Einen Nachweis für den Prefetch findest du auch, wenn du in den Entwicklertools auf dem Tab „Network“ (Netzwerk) nach URLs suchst, die webpkgcache enthalten.

Wenn <a> auf webpkgcache.com verweist, funktioniert die Indexierung von Signed Exchange in der Google-Suche. Du kannst zum Abschnitt Datenaufnahme springen.

Es kann auch sein, dass Google deine Seite seit der Aktivierung von SXG noch nicht neu gecrawlt hat. Probieren Sie das URL-Prüftool der Google Search Console aus:

Wenn ein digest: mi-sha256-03=...-Header vorhanden ist, hat Google die SXG-Version erfolgreich gecrawlt.

Wenn kein digest-Header vorhanden ist, könnte das darauf hindeuten, dass kein SXG für den Googlebot bereitgestellt wurde oder dass der Index seit der Aktivierung von SXGs nicht aktualisiert wurde.

Wenn ein SXG erfolgreich gecrawlt, aber immer noch nicht verknüpft ist, erfüllt es möglicherweise nicht die Anforderungen für den SXG-Cache. Diese werden im nächsten Abschnitt behandelt.

Aufnahme

Wenn ein SXG von der Google Suche indexiert wird, wird seine Kopie an den SXG-Cache von Google gesendet, wo sie anhand der Cache-Anforderungen validiert wird. Die Chrome-Erweiterung zeigt das Ergebnis an:

Wenn Sie ein Häkchen (✅) sehen, können Sie mit Optimieren fortfahren.

Wenn die Anforderungen nicht erfüllt werden, werden ein Kreuz (❌) und eine Warnmeldung mit einer entsprechenden Erklärung angezeigt:

Die Seite funktioniert dann wie vor der Aktivierung von SXG. Google verlinkt die Seite auf ihrem ursprünglichen Host ohne SXG-Prefetch.

Falls die im Cache gespeicherte Kopie abgelaufen ist und im Hintergrund noch einmal abgerufen wird, wird eine Sanduhr angezeigt (⌛):

Das Google-Entwicklerdokument auf SXG enthält auch eine Anleitung zum manuellen Abfragen des Caches.

Optimieren

Wenn bei der Chrome-Erweiterung „SXG Validator“ alle Häkchen (✅) angezeigt werden, hast du eine SXG-Datei, die Nutzern angezeigt werden kann. Im Folgenden erfährst du, wie du deine Webseite so optimieren kannst, dass du mit SXG die beste LCP-Verbesserung erzielst.

max-age

Wenn SXGs ablaufen, ruft der Google-SXG-Cache im Hintergrund eine neue Kopie ab. Während sie auf diesen Abruf warten, werden sie auf die Seite auf ihrem ursprünglichen Host weitergeleitet, der nicht vorab abgerufen wird. Je länger Sie Cache-Control: max-age festlegen, desto seltener findet dieser Hintergrundabruf statt und desto häufiger kann der LCP durch Prefetch verringert werden.

Dabei handelt es sich um einen Kompromiss zwischen Leistung und Aktualität. Mit dem Cache können Websiteinhaber SXGs ein maximales Alter zwischen zwei Minuten und sieben Tagen angeben, um den individuellen Anforderungen der jeweiligen Seite gerecht zu werden. Anekdote:

• max-age=86400 (1 Tag) oder länger eignen sich gut für eine gute Leistung
• max-age=120 (2 Minuten)

Wir hoffen, dass wir mehr über die Werte dazwischen erfahren werden, wenn wir die Daten genauer untersuchen.

Hinweis:Wir planen, diese Abwägung in Zukunft durch das Hinzufügen einer API zum dauerhaften Löschen des Cache zu vereinfachen. Sie wird unter webpackaging-announce bekanntgegeben.

User-Agent

Einmal habe ich einen Anstieg des LCP-Werts bei Verwendung eines Prefetch-SXGs festgestellt. Ich habe WebPageTest ausgeführt und die Medianwerte ohne und mit dem SXG-Prefetch verglichen. Klicken Sie unten auf Nach:

Ich habe gesehen, dass der Prefetch funktioniert. Der HTML-Code wird aus dem kritischen Pfad entfernt, sodass alle Unterressourcen früher geladen werden können. Aber der LCP – die grüne gestrichelte Linie – stieg von 2 Sek. auf 2,1 Sek..

Zur Diagnose habe ich mir die Filmstreifen angesehen. Ich habe festgestellt, dass die Seite in SXG anders gerendert wurde. Bei reinem HTML-Code stellte Chrome fest, dass der Anzeigentitel das „größte Element“ für LCP war. In der SXG-Version wurde auf der Seite jedoch ein Lazy-Loading-Banner hinzugefügt, durch das der Anzeigentitel „below the fold“ (mit Scrollen sichtbar) verschoben wurde. Das neue wichtigste Element war der Dialog zur Einholung von Einwilligungen für Cookies. Alles wird schneller gerendert als zuvor, aber eine Layoutänderung hat dazu geführt, dass der Messwert sie als langsamer anzeigt.

Ich habe mir weitere Informationen angeschaut und herausgefunden, dass der Grund für den Layoutunterschied darin bestand, dass die Seite von User-Agent variiert und dass es einen Fehler in der Logik gab. Es wurde eine Desktopseite bereitgestellt, obwohl im SXG-Crawling-Header eine mobile Version angegeben war. Nachdem das Problem behoben worden war, erkannte der Browser den Titel der Seite wieder korrekt als das größte Element.

Beim Klicken auf „Nach“ habe ich gesehen, dass der Prefetch-LCP auf 1,3 s sinkt:

SXGs sind für alle Formfaktoren verfügbar. Stellen Sie daher sicher, dass eine der folgenden Bedingungen zutrifft:

• Ihre Seite Vary nicht bis zum User-Agent (z.B. durch responsives Design oder separate mobile/Desktop-URLs).
• Wenn für Ihre Seite die dynamische Bereitstellung verwendet wird, wird sie mithilfe von <meta name=supported-media content=...> als nur für Mobilgeräte oder Computer gekennzeichnet.

Unterressourcen

SXGs können verwendet werden, um Unterressourcen (einschließlich Bilder) zusammen mit dem HTML-Code im Voraus abzurufen. Cloudflare ASX scannt den HTML-Code nach Same-Origin-<link rel=preload>-Elementen (Erstanbieter) und konvertiert sie in SXG-kompatible Link-Header. Details finden Sie hier und im Quellcode.

Wenn es funktioniert, sehen Sie zusätzliche Prefetches aus der Google Suche:

Zur Optimierung für LCP sollten Sie sich Ihre Vermittlungsabfolge genau ansehen und herausfinden, welche Ressourcen sich auf dem kritischen Pfad zum Rendern des größten Elements befinden. Wenn sie nicht vorab abgerufen werden können, überlegen Sie, ob sie aus dem kritischen Pfad entfernt werden können. Halten Sie Ausschau nach Skripts, die die Seite ausblenden, bis sie vollständig geladen sind.

Im Google SXG-Cache können bis zu 20 Unterressourcen vorab geladen werden. ASX stellt sicher, dass dieses Limit nicht überschritten wird. Es besteht jedoch das Risiko, wenn zu viele Vorabladevorgänge von Unterressourcen hinzugefügt werden. Der Browser verwendet vorab geladene Unterressourcen nur, wenn alle Ressourcen abgerufen wurden, um websiteübergreifendes Tracking zu verhindern. Je mehr Unterressourcen vorhanden sind, desto unwahrscheinlicher ist es, dass der Prefetch abgeschlossen ist, bevor der Nutzer auf Ihre Seite klickt.

Hinweis: ASX unterstützt derzeit nur den Prefetch für Same-Origin-Unterressourcen (Erstanbieter). Wenn Sie Drittanbieter von Unterressourcen kennen, die SXG unterstützen, teilen Sie uns dies über diesen Fehler mit, damit wir die ursprungsübergreifende Unterstützung priorisieren können.

SXG Validator überprüft derzeit keine Unterressourcen. Verwende in der Zwischenzeit curl oder dump-signedexchange, um Fehler zu beheben.

Messen

Nachdem du unter WebPageTest die LCP-Verbesserung optimiert hast, ist es hilfreich, die Auswirkungen des SXG-Vorabrufs auf die Gesamtleistung deiner Website zu messen.

Serverseitige Messwerte

Wenn Sie serverseitige Messwerte wie Time to First Byte (TTFB) messen, sollten Sie beachten, dass Ihre Website SXGs nur für Crawler bereitstellt, die dieses Format akzeptieren. Beschränken Sie die Messung von TTFB auf Anfragen von echten Nutzern und nicht auf Bots. Sie werden möglicherweise feststellen, dass durch die Generierung von SXGs die TTFB für Crawler-Anfragen länger wird. Dies hat jedoch keine Auswirkungen auf die Nutzererfahrung.

Clientseitige Messwerte

SXGs liefern den größten Geschwindigkeitsvorteil bei clientseitigen Messwerten, insbesondere bei LCP. Zum Messen der Auswirkungen können Sie einfach Cloudflare ASX aktivieren, warten, bis der Googlebot das nächste Mal gecrawlt wird, weitere 28 Tage auf die Core Web Vitals-Zusammenfassung (CWV) warten und sich dann die neuen CWV-Werte ansehen. Unter Umständen ist die Änderung jedoch unter all den anderen Änderungen in diesem Zeitraum schwer zu erkennen.

Stattdessen finde ich es hilfreich, auf die potenziell betroffenen Seitenladevorgänge zu zoomen und sie wie folgt darzustellen: „SXGs wirken sich auf X% der Seitenaufrufe aus und verbessern ihren LCP um Y Millisekunden im 75. Perzentil.“

Derzeit ist der SXG-Prefetch nur unter bestimmten Bedingungen möglich:

• Chromium-Browser (z.B. Chrome oder Edge, außer iOS), Version M98 oder höher
• Referer: google.com oder andere Domains der Google Suche. Hinweis: In Google Analytics gilt ein Verweis-Tag für alle Seitenaufrufe während einer Sitzung, während der SXG-Prefetch nur für den ersten Seitenaufruf gilt, der direkt über die Google Suche verknüpft ist.

Hinweis:Es ist geplant, die Kontexte, in denen SXG-Prefetch verwendet werden kann, in der Google Suche auszuweiten, darunter auch Computerbetriebssysteme. Dadurch kann sich der X %-Wert im Laufe der Zeit erhöhen. Außerdem empfiehlt es sich, die Messwerte entsprechend zu aktualisieren. In diesem Fall sollte es unter webpackaging-announce bekannt gegeben werden.

Weitere Informationen zur Messung von „X% der Seitenaufrufe“ und „Verbessern des LCP-Werts um Y Millisekunden“ finden Sie im Abschnitt zu zeitgenössischen Studien.

Zeitgenössische Studie

Wenn Sie sich echte RUM-Daten (User Monitoring) ansehen, sollten Sie den Seitenaufbau in SXG- und Nicht-SXG-Seiten aufteilen. In diesem Fall ist es wichtig, die Anzahl der Seitenladevorgänge einzuschränken, die du dir ansiehst, damit die Nicht-SXG-Seite die Voraussetzungen für SXG erfüllt, um Auswahlverzerrungen zu vermeiden. Andernfalls würden alle der folgenden Elemente nur in der Gruppe von Nicht-SXG-Seitenladevorgängen vorhanden sein, die an sich einen anderen LCP-Wert haben können:

• iOS-Geräte:Aufgrund von Unterschieden in der Hardware- oder Netzwerkgeschwindigkeit der Nutzer dieser Geräte.
• Ältere Chromium-Browser:Aus den gleichen Gründen.
• Desktop-Geräte: aus denselben Gründen oder weil das Seitenlayout dazu führt, dass ein anderes „größtes Element“ ausgewählt wird.
• Navigation auf derselben Website (Besucher, die innerhalb der Website auf Links klicken), da sie im Cache gespeicherte Unterressourcen aus dem vorherigen Seitenaufbau wiederverwenden können.

Erstellen Sie in Google Analytics (UA) zwei benutzerdefinierte Dimensionen mit dem Umfang „Treffer“, eine mit dem Namen „isSXG“ und eine mit dem Namen „referrer“. Da die integrierte Dimension „Quelle“ auf Sitzungsumfang festgelegt ist, werden Navigationen auf derselben Website nicht ausgeschlossen.

Erstellen Sie ein benutzerdefiniertes Segment mit dem Namen „SXG kontrafaktisch“ und verknüpfen Sie die folgenden Filter mit einer AND-Verknüpfung:

• referrer beginnt mit https://www.google.
• Browser stimmt genau überein mit Chrome
• Browser Version stimmt mit Regex ^(9[8-9]|[0-9]{3}) überein
• isSXG stimmt genau überein mit false

Erstellen Sie eine Kopie dieses Segments mit dem Namen „SXG“. Achten Sie darauf, dass „isSXG“ genau mit true übereinstimmt.

Fügen Sie in Ihrer Websitevorlage das folgende Snippet oberhalb des Google Analytics-Snippets ein. Das ist eine besondere Syntax, die ASX beim Generieren eines SXG false zu true ändert:

<script data-issxg-var>window.isSXG=false</script>

Passen Sie Ihr Google Analytics-Berichtsskript wie empfohlen für die Aufzeichnung des LCP an. Wenn Sie gtag.js verwenden, ändern Sie den Befehl 'config', um die benutzerdefinierte Dimension festzulegen. Ersetzen Sie dabei 'dimension1' und 'dimension2' durch die in Google Analytics vorgegebenen Namen:

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

Wenn Sie analytics.js verwenden, ändern Sie den 'create'-Befehl wie hier dokumentiert.

Warten Sie einige Tage, bis Daten erfasst wurden. Rufen Sie dann den Google Analytics-Bericht „Ereignisse“ auf und fügen Sie eine Aufschlüsselung für das SXG-Segment hinzu. Dies sollte das X für „SXGs beeinflussen X% der Seitenaufrufe“ ausfüllen:

Rufen Sie schließlich den Web Vitals-Bericht auf, wählen Sie „Segmente auswählen“ und dann „SXG-Kontrafaktik“ und „SXG“ aus.

Klicken Sie auf „Senden“. Jetzt sollten die LCP-Verteilungen für die beiden Segmente angezeigt werden. Dadurch sollte Y für „Verbesserung des LCP-Werts um Y Millisekunden beim 75. Perzentil“ ausgefüllt werden:

Wichtige Hinweise

Nachdem du alle oben genannten Filter angewendet hast, sollte beim Laden von kontrafaktischen SXG-Seiten Folgendes Folgendes passieren:

• Cache-Fehler:Wenn es im Google-SXG-Cache für eine bestimmte URL keine neue Kopie des SXG-Codes gibt, wird der Nutzer zur ursprünglichen URL auf Ihrer Website weitergeleitet.
• Andere Ergebnistypen:Derzeit unterstützt die Google Suche für Standardwebergebnisse nur SXG und einige andere Typen. Andere, wie hervorgehobene Snippets und das Karussell mit Schlagzeilen, verlinken auf die ursprüngliche URL auf Ihrer Website.
• Unzulässige URLs:Falls einige Seiten Ihrer Website nicht für SXG geeignet sind (z.B. weil sie nicht im Cache gespeichert werden können), erscheinen sie möglicherweise in der Liste.

Zwischen den Ladevorgängen von SXG-Seiten und den oben genannten Nicht-SXG-Seiten kann es weiterhin Verzerrungen geben, diese sollten jedoch kleiner sein als die Verzerrungen, die oben im Abschnitt zu zeitgenössischen Studien erwähnt werden. So sind etwa Ihre nicht im Cache speicherbaren Seiten langsamer oder schneller als Ihre im Cache speicherbaren Seiten. Wenn Sie vermuten, dass dies ein Problem sein könnte, sollten Sie sich die Daten ansehen, die auf eine bestimmte für SXG zulässige URL beschränkt sind, um festzustellen, ob die Ergebnisse mit der Gesamtstudie übereinstimmen.

Wenn Ihre Website AMP-Seiten hat, werden diese durch die Aktivierung von SXG wahrscheinlich keine Leistungsverbesserungen erzielen, da sie bereits aus der Google Suche abgerufen werden können. Sie können einen Filter hinzufügen, um solche Seiten auszuschließen, um die relevanten Änderungen genauer zu betrachten.

Und schließlich besteht das Risiko, dass die LCP-Verbesserungen in den RUM-Statistiken wie Verschlechterungen erscheinen, selbst wenn alle Auswahlverzerrungen berücksichtigt werden. In diesem Artikel wird dieses Risiko ausführlich erläutert. Außerdem empfiehlt es sich, mit einem Ausstiegsmesswert zu prüfen, ob das tatsächlich der Fall ist.

Vorher/Nachher der Studie

Zur Bestätigung der Ergebnisse der aktuellen Studie kann ein Vergleich des LCP vor und nach der Aktivierung von SXG hilfreich sein. Beschränke dich nicht auf SXG-Seitenaufrufe, um die oben genannten potenziellen Verzerrungen zu beseitigen. Sieh dir stattdessen die für SXG geeigneten Ergebnisse an – die oben aufgeführten Segmentdefinitionen, aber ohne die isSXG-Beschränkung.

Beachte, dass es mehrere Wochen dauern kann, bis alle Seiten deiner Website in der Google Suche neu gecrawlt wurden und SXG für sie aktiviert wurde. In diesen Wochen können weitere mögliche Verzerrungen auftreten:

• Neue Browserversionen oder Verbesserungen an der Hardware der Nutzer können das Laden von Seiten beschleunigen.
• Ein wichtiges Ereignis wie z. B. ein Feiertag kann dazu führen, dass die Zugriffe von normalen Ereignissen abweichen.

Zur Bestätigung der oben genannten Studien ist es auch hilfreich, sich davor und danach den gesamten 75. Perzentil des LCP anzusehen. Wenn wir Daten über eine Untergruppe lernen, sagt das nicht unbedingt über die Gesamtbevölkerung aus. Ein Beispiel: SXG verkürzt 10% der Seitenaufrufe um 800 ms.

• Wenn diese Seiten bereits 10% am schnellsten geladen wurden, wirkt sich das überhaupt nicht auf das 75. Perzentil aus.
• Wenn die Seitenladevorgänge mit 10% am langsamsten waren, sie aber mehr als 800 ms unter dem 75. Perzentil langsamer waren als der LCP-Wert des 75. Perzentils, hat dies keine Auswirkungen auf das 75. Perzentil.

Dies sind extreme Beispiele, die zwar wahrscheinlich nicht die Realität widerspiegeln, aber hoffentlich veranschaulichen das Problem hoffentlich. In der Praxis ist es wahrscheinlich, dass SXG bei den meisten Websites das 75. Perzentil beeinflusst. Die Websiteübergreifende Navigation ist in der Regel am langsamsten und Verbesserungen durch den Vorabruf sind in der Regel erheblich.

Einige URLs deaktivieren

Eine Möglichkeit zum Vergleich der SXG-Leistung besteht darin, SXG für eine Untergruppe von URLs auf deiner Website zu deaktivieren. Du kannst beispielsweise einen CDN-Cache-Control: no-store-Header festlegen, um zu verhindern, dass Cloudflare ASX ein SXG generiert. Ich raten davon ab.

Sie birgt wahrscheinlich ein größeres Risiko für Auswahlverzerrungen als andere Studienmethoden. Beispielsweise kann es einen großen Unterschied machen, ob die Startseite Ihrer Website oder eine ähnlich beliebte URL in die Kontrollgruppe oder die Testgruppe aufgenommen wird.

Holdback-Studie

Die ideale Methode zur Messung der Auswirkungen wäre die Durchführung einer Holdback-Studie. Leider sind solche Tests derzeit nicht möglich. Wir planen, diesen Test in Zukunft zu unterstützen.

Eine Holdback-Studie hat die folgenden Eigenschaften:

• In der Testgruppe wird ein zufälliger Anteil der Seitenaufrufe, die SXG wären, „zurückgehalten“ und stattdessen als Nicht-SXG angezeigt. So können Sie vergleichbare Nutzer, Geräte, Szenarien und Seiten vergleichen.
• Diese zurückgehaltenen (auch kontrafaktischen) Seitenaufrufe werden in Analytics als solche gekennzeichnet. Dadurch wird eine herangezoomte Ansicht der Daten ermöglicht, in der wir die SXG-Seitenladevorgänge in der Kontrollgruppe mit den kontrafaktischen SXG-Daten im Test vergleichen können. Dies wiederum reduziert das Rauschen der anderen Seitenladevorgänge, das vom SXG-Prefetch nicht betroffen wäre.

Dies würde die oben genannten möglichen Quellen von Auswahlverzerrungen eliminieren, obwohl dadurch nicht das Risiko einer LCP-Überlebensverzerrung eliminiert würde. Für beide Eigenschaften ist entweder der Browser oder die Referrer-URL erforderlich, um aktiviert zu werden.

Fazit

Geschafft! Das war ganz schön viel. Hoffentlich erhalten Sie damit ein umfassenderes Bild davon, wie Sie die SXG-Leistung in einem Labortest testen, die Leistung mithilfe des Labortests in einem engen Feedbackschleife optimieren und schließlich wie sich die Leistung in der Praxis messen lässt. Wenn du all das zusammenfasst, kannst du SXGs optimal nutzen und dafür sorgen, dass deine Website und deine Nutzer davon profitieren.

Wenn du weitere Tipps dazu hast, wie du die Leistung deines SXG aufzeichnen kannst, kannst du dich jederzeit gern an uns wenden. Melden Sie Fehler auf developer.chrome.com mit Ihren Verbesserungsvorschlägen.

Weitere Informationen zu Signed Exchanges finden Sie in der Dokumentation zu web.dev und in der Dokumentation zur Google Suche.