LCP mithilfe von Signed Exchanges optimieren

Signed Exchanges messen und optimieren, um sie bestmöglich zu nutzen

Devin Mullins

Mit Signed Exchanges (SXGs) – hauptsächlich Largest Contentful Paint (LCP), kannst du die Geschwindigkeit deiner Seite verbessern. Wenn verweisende Websites (derzeit die Google Suche) auf eine Seite verweisen, können sie diese im Browser-Cache vorab abrufen, bevor der Nutzer auf den Link klickt.

Es ist möglich, Webseiten zu erstellen, die beim Vorabruf kein Netzwerk auf dem kritischen Pfad zum Rendern der Seite benötigen. Bei einer 4G-Verbindung geht der Seitenaufbau von 2,8 s auf 0,9 s (die verbleibenden 0,9 s werden hauptsächlich durch die CPU-Nutzung verursacht):

<ph type="x-smartling-placeholder">

</ph>

Hinweis:In diesem Beitrag wurde bereits eine Verbesserung von 6 Sek. auf 0, 9 Sek. gezeigt. Das stimmte, aber die zu testende Website war damals ungewöhnlich langsam. Es kann jedoch als Beispiel für Seiten mit mehr Unterressourcen, langsamen Servern oder Nutzern mit langsamen Verbindungstypen dienen.

Heutzutage verwenden die meisten Verlage und Webpublisher von SXGs die nutzerfreundliche Funktion Automatic Signed Exchanges (ASX) von Cloudflare (auch wenn es Open-Source-Optionen gibt):

In vielen Fällen reicht es aus, das Kästchen zur Aktivierung dieser Funktion anzuklicken, um die oben gezeigte wesentliche Verbesserung zu erzielen. Manchmal sind einige weitere Schritte erforderlich, um sicherzustellen, dass diese SXGs in jeder Phase der Pipeline wie vorgesehen funktionieren, und die Seiten zu optimieren, um den Prefetch optimal zu nutzen.

In den letzten Monaten nach der Einführung von Cloudflare habe ich in verschiedenen Foren Fragen gelesen und beantwortet. Außerdem lerne ich, wie ich Websites beraten kann, wie sie SXG-Bereitstellungen optimal nutzen können. Dieser Beitrag fasst meine Ratschläge zusammen. Ich gehe die Schritte durch:

• Analysiere die SXG-Leistung mit WebPageTest.
• Fehler in der SXG-Pipeline beheben, wenn im Schritt „Analysieren“ festgestellt wird, dass sie nicht funktioniert.
• Optimiere Seiten für den SXG-Prefetch, z. B. durch Festlegen eines optimalen max-age und Vorabladen von Unterressourcen, die das Rendering blockieren.
• Miss die SXG-Verbesserung mit Google Analytics, indem du geeignete Test- und Kontrollgruppen auswählst.

Einführung

Ein SXG ist eine Datei, die eine URL, eine Reihe von HTTP-Antwortheadern und einen Antworttext enthält – alle kryptografisch von einem Web-PKI-Zertifikat signiert. Wenn der Browser einen SXG lädt, werden alle folgenden Elemente überprüft:

• Die SXG ist noch nicht abgelaufen.
• Die Signatur stimmt mit der URL, den Headern, dem Text und dem Zertifikat überein.
• Das Zertifikat ist gültig und stimmt mit der URL überein.

Wenn die Bestätigung 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. Dadurch können SXGs auf jedem Server neu gehostet werden, solange er nicht abgelaufen ist oder seit der Signatur nicht geändert wurde.

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 webpkgcache.com-URLs haben keinen Einfluss auf die Anzeige oder das Verhalten der Seite, da der Browser die ursprüngliche, signierte URL respektiert. Durch einen 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. Sie können beispielsweise die Verbindungsstabilität ermöglichen: Eine Chat-App könnte im Voraus einen Link herunterladen, der an den Nutzer gesendet wird, wenn die Seite SXG unterstützt, damit er sich später offline ansehen kann. Hier finden Sie eine längere Liste mit möglichen Anwendungsfällen.

Analysieren

Um die Vorteile von SXGs zu sehen, solltest du zuerst ein Lab-Tool verwenden, um die SXG-Leistung unter wiederholbaren Bedingungen zu analysieren. Mit WebPageTest kannst du Vermittlungsabfolgen und LCP mit und ohne SXG-Prefetch vergleichen.

Achtung:Labergebnisse können von der tatsächlichen Nutzererfahrung abweichen. Sie sind jedoch ein nützliches Tool, um zu ermitteln, wo Optimierungsbedarf besteht und wo sie schnell iteriert werden müssen. Wie Sie die daraus resultierenden Messwerte für echte Nutzer messen, erfahren Sie im Abschnitt „Messen“.

Generiere so einen Test ohne SXG:

• Rufen Sie WebPageTest auf und melden Sie sich an. Durch die Anmeldung wird dein Prüfungsverlauf gespeichert, damit du ihn später leichter vergleichen kannst.
• Geben Sie die URL ein, die Sie testen möchten.
• Gehen Sie zu Erweiterte Konfiguration. Für den SXG-Test ist die erweiterte Konfiguration erforderlich. Wenn Sie sie hier verwenden, können Sie sicherstellen, dass die Testoptionen identisch sind.
• Im Tab Testeinstellungen kann es hilfreich sein, „Verbindung auf 4G“ festzulegen und die Anzahl der auszuführenden Tests zu erhöhen. bis 7.
• Klicken Sie auf Start Test (Test starten).

Erstelle einen Test mit SXG. Führe dazu dieselben Schritte wie oben aus. Bevor du jedoch auf Test starten klickst, rufe den Tab Skript auf, füge das folgende WebPageTest-Skript ein und ändere 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

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

Um die zweite navigate-URL zu ermitteln, rufe deine Seite mithilfe der Chrome-Erweiterung für den SXG Validator auf und klicke auf das Erweiterungssymbol, um die Cache-URL aufzurufen:

Rufen Sie nach Abschluss dieser Tests 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 einem Medianwert für den LCP für jede Seite des Vergleichs auswählt. Der Standardwert ist ein Medianwert für den Geschwindigkeitsindex.

Wenn Sie Wasserfälle vergleichen möchten, maximieren Sie den Bereich Wasserfall-Deckkraft und ziehen Sie den Schieberegler. Wenn Sie sich das Video ansehen möchten, klicken Sie auf Filmstreifen-Einstellungen anpassen, scrollen Sie im Dialogfeld nach unten und klicken Sie auf Video ansehen.

Wenn der SXG-Prefetch erfolgreich war, siehst du, dass „mit SXG“ Die Vermittlungsabfolge enthält keine Zeile für den HTML-Code und die Abrufe für Unterressourcen beginnen früher. Vergleichen Sie z. B. „Vorher“ und „Nachher“ hier:

Fehlerbehebung

Wenn WebPageTest anzeigt, dass der SXG vorab abgerufen wird, waren alle Schritte der Pipeline erfolgreich. In diesem Fall können Sie mit dem Abschnitt Optimieren fortfahren, um zu erfahren, wie Sie den LCP weiter verbessern können. Andernfalls müssen Sie herausfinden, wo in der Pipeline er fehlgeschlagen ist und warum. lesen Sie weiter, um zu erfahren, wie.

Wird veröffentlicht

Deine Seiten müssen als SXGs generiert werden. Dazu müssen Sie sich als ein Crawler ausgeben. Am einfachsten ist es, wenn du die Chrome-Erweiterung „SXG Validator“ verwendest:

<ph type="x-smartling-placeholder">

</ph>

Hinweis:SXGs sind für SXG-fähige Crawler gedacht, die den Vorabruf ermöglichen. Wenn Nutzer Ihre Website direkt besuchen, sollten Sie für sie keine SXGs ausliefern, da sie nicht vorab abgerufen werden. Dies erhöht nur den Aufwand. Cloudflare ASX führt diese Inhaltsverhandlung automatisch durch.

Die Erweiterung ruft die aktuelle URL mit einem Accept-Anfrageheader ab, der angibt, dass die SXG-Version bevorzugt wird. Wenn neben „Ursprung“ ein Häkchen (✅) angezeigt wird, wurde eine SXG-Karte zurückgegeben. können Sie mit dem Abschnitt Indexierung fortfahren.

Wenn ein Kreuz (❌) angezeigt wird, wurde keine SXG-Datei zurückgegeben:

Wenn Cloudflare ASX aktiviert ist, liegt der wahrscheinlichste Grund für ein Kreuz (❌) darin, dass ein Antwortheader der Cache-Steuerung dies verhindert. ASX sucht nach Headern mit den folgenden Namen:

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

Wenn einer dieser Header einen der folgenden Headerwerte enthält, wird kein SXG generiert:

• private
• no-store
• no-cache
• max-age ist kleiner als 120, es sei denn, sie wird durch s-maxage größer oder gleich 120 überschrieben

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

Ein weiterer möglicher Grund für ein Kreuzzeichen (❌) 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 sind im ASX-Code genauer aufgeführt. Zum Beispiel werden Header zur Cachesteuerung durch den Code geprüft, der bestimmt, wann zu signieren und wie lang die Signaturdauer sein muss. Andere Header werden vor dem Signieren durch diese Konfiguration oder durch diesen Code entfernt. Andere Header verhindern das Signieren, sofern sie nicht anderweitig entfernt werden.

Ein weiterer möglicher Grund ist das Vorhandensein eines Vary: Cookie-Antwortheaders. Der Googlebot ruft SXGs ohne Nutzeranmeldedaten ab und kann sie mehreren Besuchern bereitstellen. Wenn Sie verschiedenen Nutzern je nach Cookie unterschiedlichen HTML-Code bereitstellen, kann dies zu Problemen führen, etwa wenn Nutzer nicht angemeldet sind.

Hinweis:In Zukunft werden Seiten, die Vary: Cookie verwenden, auch von SXG unterstützt, da sie nur Besuchern angezeigt werden, die keine Cookies für deine Website haben. Diese Funktion ist in Chromium implementiert und wird nach vollständiger Einführung in der Google Suche aktiviert.

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 die SXG vorhanden und gültig ist, siehst du einen menschenlesbaren Ausdruck der SXG. Andernfalls wird eine Fehlermeldung angezeigt.

Indexierung

Prüfe, ob deine SXGs von der Google Suche indexiert wurden. Öffnen Sie die Chrome-Entwicklertools und führen Sie eine Google-Suche nach Ihrer Seite durch. Wenn sie als SXG indexiert wurde, enthält der Link von Google zu deiner 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 klickt, wird es auch vorab abgerufen:

Das <link>-Element weist den Browser an, den SXG in den Prefetch-Cache herunterzuladen. Wenn der Nutzer auf das <a>-Element klickt, verwendet der Browser diesen im Cache gespeicherten SXG, um die Seite zu rendern.

Hinweise für den Prefetch können Sie auch abrufen, indem Sie in den Entwicklertools den Tab „Network“ aufrufen und nach URLs suchen, die webpkgcache enthalten.

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

Andernfalls hat Google Ihre Seite möglicherweise noch nicht neu gecrawlt, seit Sie SXG aktiviert haben. Probieren Sie das URL-Prüftool der Google Search Console aus:

Ein digest: mi-sha256-03=...-Header weist darauf hin, dass Google die SXG-Version erfolgreich gecrawlt hat.

Wenn kein digest-Header vorhanden ist, könnte das ein Hinweis darauf sein, dass dem Googlebot kein SXG ausgeliefert wurde oder dass der Index seit der Aktivierung von SXGs nicht aktualisiert wurde.

Wenn eine SXG erfolgreich gecrawlt wurde, aber immer noch nicht mit ihr verknüpft ist, werden die Anforderungen an den SXG-Cache möglicherweise nicht erfüllt. Diese werden im nächsten Abschnitt behandelt.

Aufnahme

Wenn die Google Suche einen SXG indexiert, wird eine Kopie an den SXG-Cache von Google gesendet, der ihn anhand der Cache-Anforderungen validiert. Die Chrome-Erweiterung zeigt das Ergebnis an:

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

Wenn es die Anforderungen nicht erfüllt, werden ein Häkchen (❌) und eine Warnmeldung mit einem Grund angezeigt:

In diesem Fall funktioniert die Seite genauso wie vor der Aktivierung von SXG. Google verlinkt ohne SXG-Prefetch auf die Seite auf dem ursprünglichen Host.

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

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

Optimieren

Wenn in der Chrome-Erweiterung „SXG Validator“ alle Häkchen angezeigt werden (✅), gibt es eine SXG, die Nutzern angezeigt werden kann. Im Folgenden erfährst du, wie du deine Webseite so optimieren kannst, dass du eine maximale LCP-Verbesserung durch SXG erhältst.

max-age

Wenn SXGs ablaufen, ruft der SXG-Cache von Google im Hintergrund eine neue Kopie ab. Während sie auf diesen Abruf warten, werden Nutzer zur Seite auf ihrem ursprünglichen Host weitergeleitet, der nicht vorab abgerufen wurde. Je länger Sie Cache-Control: max-age festlegen, desto seltener erfolgt dieser Hintergrundabruf. Daher kann der LCP-Wert durch Prefetch verringert werden.

Dies ist ein Kompromiss zwischen Leistung und Aktualität und der Cache ermöglicht es Websiteinhabern, für SXGs ein Höchstalter von 2 Minuten bis 7 Tagen festzulegen, um die speziellen Anforderungen der einzelnen Seiten zu erfüllen. Anekdotenweise stellen wir Folgendes fest:

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

Wir hoffen, im Laufe der weiteren Untersuchung der Daten mehr über die Werte dazwischen zu erfahren.

Hinweis:Wir planen, diesen Kompromiss in Zukunft einfacher zu verwalten, indem wir eine Cache purge API hinzufügen. Sie wird auf webpackaging-announce angekündigt.

User-Agent

Einmal habe ich einen Anstieg des LCP mit einem vorabgerufenen SXG festgestellt. Ich habe WebPageTest ausgeführt und die Medianergebnisse 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. Der LCP-Wert, also diese grüne gestrichelte Linie, stieg von 2 s auf 2,1 s an.

Zur Diagnose des Problems habe ich mir die Filmstreifen angesehen. Ich habe festgestellt, dass die Seite in SXG anders gerendert wird. In einfachem HTML hat Chrome festgestellt, dass das „größte Element“ für LCP war die Überschrift. In der SXG-Version wurde jedoch ein Lazy-Loading-Banner hinzugefügt, wodurch der Anzeigentitel „below the fold“ (mit Scrollen sichtbar) verschoben wurde und das neue größte Element der Lazy-Loading-Dialog für Cookies zur Einwilligung war. Alles wurde schneller als zuvor gerendert, aber aufgrund einer Layoutänderung wurde der Messwert langsamer erfasst.

Ich habe mir das angesehen und festgestellt, dass der Grund für den Unterschied im Layout darin liegt, dass die Seite je nach User-Agent variiert und die Logik einen Fehler enthält. Es wurde eine Desktop-Seite angezeigt, obwohl im SXG-Crawling-Header „mobile“ angegeben war. Nachdem das Problem behoben wurde, hat der Browser die Überschrift der Seite wieder korrekt als größtes Element identifiziert.

Als ich jetzt auf „Nach“ klicke, sehe ich, dass der Prefetch-LCP auf 1,3 Sek.sinkt:

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

• Ihre Seite wird nicht um User-Agent Vary, d.h. sie verwendet responsives Design oder separate mobile URLs/Desktop-URLs.
• Wenn Sie für Ihre Seite die dynamische Bereitstellung nutzen, wird sie mit <meta name=supported-media content=...> als reine Mobilgeräte- oder Desktop-Seite gekennzeichnet.

Unterressourcen

Mit SXGs können Unterressourcen (einschließlich Bildern) zusammen mit dem HTML-Code vorab abgerufen werden. Cloudflare ASX scannt den HTML-Code nach Same-Origin-Elementen (eigene) <link rel=preload> und konvertiert sie in SXG-kompatible Link-Header. Details im Quellcode finden Sie hier und hier.

Wenn es funktioniert, werden weitere Prefetches aus der Google Suche angezeigt:

Sehen Sie sich die Vermittlungsabfolge genau an und finden Sie heraus, welche Ressourcen sich auf dem kritischen Pfad zum Rendern des größten Elements befinden, um den LCP-Wert zu optimieren. Wenn sie nicht vorab abgerufen werden können, überlegen Sie, ob sie aus dem kritischen Pfad entfernt werden können. Suchen Sie nach Skripts, die die Seite ausblenden, bis der Ladevorgang abgeschlossen ist.

Der SXG-Cache von Google ermöglicht bis zu 20 Vorabladevorgänge für Unterressourcen. ASX stellt sicher, dass dieses Limit nicht überschritten wird. Weitere Informationen Es besteht jedoch ein Risiko, wenn zu viele Vorabladevorgänge für Unterressourcen hinzugefügt werden. Der Browser verwendet vorab geladene Unterressourcen nur dann, wenn alle Ressourcen den Abruf abgeschlossen haben, um websiteübergreifendes Tracking zu verhindern. Je mehr Unterressourcen vorhanden sind, desto unwahrscheinlicher ist es, dass alle den Vorabruf abgeschlossen haben, bevor der Nutzer auf Ihre Seite gelangt.

Hinweis: ASX unterstützt derzeit nur Prefetch für Same-Origin-Unterressourcen (eigene) Unterressourcen. Wenn du Unterressourcen-Drittanbieter kennst, die SXG unterstützen, teile uns diesen Fehler mit, damit wir die ursprungsübergreifende Unterstützung priorisieren können.

Der SXG-Validator prüft derzeit keine untergeordneten Ressourcen. Verwenden Sie in der Zwischenzeit curl oder dump-signedexchange.

Messen

Nachdem Sie die LCP-Verbesserung mit WebPageTest optimiert haben, ist es hilfreich, die Auswirkungen des SXG-Vorabrufs auf die Gesamtleistung Ihrer Website zu messen.

Serverseitige Messwerte

Beim Messen serverseitiger Messwerte wie Time to First Byte (TTFB) ist es wichtig zu beachten, dass Ihre Website SXGs nur für Crawler bereitstellt, die das Format akzeptieren. Beschränken Sie die Messung der TTFB auf Anfragen von echten Nutzern und nicht von Bots. Wenn Sie SXGs generieren, erhöht sich die TTFB für Crawler-Anfragen. Dies hat jedoch keine Auswirkungen auf die Nutzererfahrung.

Clientseitige Messwerte

SXGs erzielen den größten Geschwindigkeitsvorteil für clientseitige Messwerte, insbesondere LCP. Wenn Sie die Auswirkungen messen möchten, können Sie einfach Cloudflare ASX aktivieren, warten, bis sie vom Googlebot noch einmal gecrawlt werden, weitere 28 Tage auf die Core Web Vitals-Aggregation (CWV) warten und sich dann die neuen CWV-Zahlen ansehen. Unter Umständen ist die Änderung jedoch schwer zu erkennen, wenn sie mit den anderen Änderungen in diesem Zeitraum kombiniert wird.

Ich finde es hilfreich, die Schaltfläche „Heranzoomen“ auf den möglicherweise betroffenen Seitenladevorgängen mit folgendem Text: „SXGs beeinflussen X% der Seitenaufrufe und verbessern ihren LCP im 75. Perzentil um Y Millisekunden.“

Derzeit erfolgt der SXG-Vorabruf nur unter bestimmten Bedingungen:

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

Hinweis:Wir planen, die Kontexte, in denen der SXG-Prefetch stattfinden kann, in die Google Suche zu erweitern, einschließlich Desktop-Betriebssystemen. Dadurch kann sich der Wert um X% im Laufe der Zeit erhöhen. Außerdem kann es bedeuten, dass Sie Ihre Messwerte aktualisieren sollten, um der Änderung Rechnung zu tragen. Sollte dies der Fall sein, sollte dies auf webpackaging-announce angekündigt werden.

Lesen Sie den Abschnitt zu Studien zu modernen Trends, um zu erfahren, wie Sie X% der Seitenaufrufe messen. und „Verbesserung des LCP um Y Millisekunden“.

Zeitgenössische Studie

Wenn Sie sich die RUM-Daten (Real User Monitoring) ansehen, sollten Sie Seitenladevorgänge in SXG- und Nicht-SXG-Daten aufteilen. Dabei ist es wichtig, die Anzahl der Seitenaufrufe zu begrenzen, die du dir ansiehst, damit die Nicht-SXG-Seite die Voraussetzungen für SXG erfüllt, um eine Verzerrung der Auswahl zu vermeiden. Andernfalls würden alle folgenden Werte nur in den Nicht-SXG-Seitenladevorgängen vorhanden sein, die von Natur aus einen anderen LCP haben können:

• iOS-Geräte:aufgrund von Unterschieden in der Hardware oder Netzwerkgeschwindigkeit unter den Nutzern dieser Geräte.
• Ältere Chromium-Browser: Aus denselben Gründen.
• Desktop-Geräte: aus den gleichen Gründen oder weil das Seitenlayout ein anderes „größtes Element“ verursacht ausgewählt werden.
• Navigation auf derselben Website (Besucher, die Links auf der Website folgen), da sie im Cache gespeicherte Unterressourcen des vorherigen Seitenaufbaus wiederverwenden können.

Erstellen Sie in Google Analytics (UA) zwei benutzerdefinierte Dimensionen mit dem Umfang „Hit“, eine mit dem Namen „isSXG“. und eines mit dem Namen „referrer“. Für die integrierte Dimension „Quelle“ gilt Sitzungsumfang, d. h. Navigationen auf derselben Website können nicht ausgeschlossen werden.

Erstellen Sie ein benutzerdefiniertes Segment mit dem Namen „SXG-Kontrafakten“ , wobei folgende Filter durch AND verbunden werden:

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

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

Fügen Sie in Ihrer Websitevorlage das folgende Snippet über dem Google Analytics-Snippet ein. Dies ist eine besondere Syntax, die ASX beim Generieren eines SXG false in true ändert:

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

Passen Sie das Google Analytics-Berichtsskript wie empfohlen an, um den LCP zu erfassen. Wenn Sie gtag.js verwenden, ändern Sie den Befehl 'config', um die benutzerdefinierte Dimension festzulegen. Ersetzen Sie dabei 'dimension1' und 'dimension2' durch die Namen, die in Google Analytics verwendet werden sollen:

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

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

Nachdem Sie einige Tage gewartet haben, um Daten zu erfassen, rufen Sie den Google Analytics-Bericht „Ereignisse“ auf und fügen Sie eine Aufschlüsselung für das SXG-Segment hinzu. Damit sollte das X für „SXGs beeinflussen X% der Seitenaufrufe“ ausgefüllt werden:

Rufen Sie abschließend den Web Vitals-Bericht auf, wählen Sie „Segmente auswählen“ und dann „SXG-Kontrafakten“ aus. und „SXG“.

Klicken Sie auf „Senden“. Jetzt sollten die LCP-Verteilungen für die beiden Segmente angezeigt werden. Hier sollte „Y“ für „Verbesserung des LCP um Y Millisekunden am 75. Perzentil“ eingetragen werden:

Vorsichtsmaßnahmen

Nachdem Sie alle oben genannten Filter angewendet haben, sollten kontrafaktische SXG-Seitenladevorgänge so aussehen:

• Cache-Fehler:Wenn im Google-SXG-Cache für eine bestimmte URL keine aktuelle Kopie des SXG-Cache vorhanden ist, werden Nutzer zur ursprünglichen URL Ihrer Website weitergeleitet.
• Andere Ergebnistypen:Derzeit unterstützt die Google Suche nur SXG für standardmäßige Webergebnisse und einige andere Typen. Andere, wie hervorgehobene Snippets und das Schlagzeilenkarussell, verweisen auf die ursprüngliche URL Ihrer Website.
• Unzulässige URLs:Wenn einige Seiten Ihrer Website nicht für SXG geeignet sind (z.B. weil sie nicht im Cache gespeichert werden können), könnten sie in dieser Liste angezeigt werden.

Zwischen den Ladevorgängen von SXG-Seiten und den oben genannten Nicht-SXG-Seiten kann noch eine Verzerrung bestehen, diese sollte jedoch kleiner sein als die oben im Abschnitt zur zeitgenössischen Studie genannten Verzerrungen. Dies kann beispielsweise der Fall sein, wenn nicht im Cache speicherbare Seiten langsamer oder schneller sind als im Cache speicherbare Seiten. Wenn du vermutest, dass es sich hierbei um ein Problem handelt, solltest du dir die Daten ansehen, die auf eine bestimmte für SXG geeignete URL beschränkt sind. So kannst du feststellen, ob die Ergebnisse mit der Gesamtstudie übereinstimmen.

Wenn deine Website einige AMP-Seiten hat, werden durch die Aktivierung von SXG wahrscheinlich keine Leistungsverbesserungen erzielt werden, da sie bereits aus der Google Suche abgerufen werden können. Sie können einen Filter hinzufügen, um solche Seiten auszuschließen, um weiter heranzuzoomen. zu den relevanten Änderungen.

Und schließlich besteht selbst bei der Berücksichtigung aller Selektionsverzerrungen das Risiko, dass die Verbesserung der LCP-Werte wie Verschlechterungen in den RUM-Statistiken aussieht. In diesem Artikel wird dieses Risiko gut erläutert. Wir empfehlen, anhand eines Messwerts für Ausstiegsraten zu prüfen, ob dies der Fall ist.

Vor/nach der Studie

Zur Bestätigung der Ergebnisse der Studie kann es hilfreich sein, den LCP vor und nach der Aktivierung von SXG zu vergleichen. Beschränken Sie sich nicht auf Seitenaufrufe in SXG, um die oben genannten potenziellen Verzerrungen zu vermeiden. Sehen Sie sich stattdessen die für SXG geeigneten Ergebnisse an – die oben genannten Segmentdefinitionen, aber ohne die Einschränkung „isSXG“.

Beachte, dass es mehrere Wochen dauern kann, bis die Google Suche alle Seiten deiner Website noch einmal crawlt, um festzustellen, ob SXG für sie aktiviert wurde. In diesen Wochen können weitere potenzielle Voreingenommenheiten auftreten:

• Neue Browserversionen oder Verbesserungen in der kann das Laden von Seiten beschleunigen.
• Ein wichtiges Ereignis wie ein Feiertag kann den Traffic von normalem Traffic verzerren.

Außerdem ist es hilfreich, sich vorher und nachher den gesamten LCP für das 75. Perzentil anzusehen, um die oben genannten Studien zu bestätigen. Informationen über eine Untergruppe der Population geben uns nicht unbedingt Aufschluss über die Gesamtbevölkerung. Nehmen wir an, SXG verbessert 10% der Seitenladevorgänge um 800 ms.

• Wenn diese bereits die 10% am schnellsten geladenen Seiten waren, hat dies keine Auswirkungen auf das 75. Perzentil.
• Wenn sie die 10% langsamsten Seitenladevorgänge sind, sie aber um mehr als 800 ms langsamer als der 75. Perzentil-LCP sind, hat dies keine Auswirkungen auf das 75. Perzentil.

Dies sind extreme Beispiele, die wahrscheinlich nicht die Realität widerspiegeln, aber das Problem hoffentlich veranschaulichen. In der Praxis ist es wahrscheinlich, dass SXG das 75. Perzentil für die meisten Websites beeinträchtigt. Websiteübergreifende Navigationen gehören in der Regel zu den langsamsten und die Verbesserungen durch den Prefetch sind in der Regel signifikant.

Bestimmte URLs deaktivieren

Eine Möglichkeit zum Vergleichen der SXG-Leistung könnte die Deaktivierung von SXG für einen Teil der URLs auf deiner Website sein. Sie können beispielsweise einen CDN-Cache-Control: no-store-Header festlegen, um zu verhindern, dass Cloudflare ASX einen SXG generiert. Ich würde davon abraten.

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

Holdback-Studie

Der ideale Weg, die Auswirkungen zu messen, wäre eine Holdback-Studie. Leider ist diese Art von Test derzeit nicht möglich. Wir planen, einen solchen Test in Zukunft zu unterstützen.

Eine Holdback-Studie hat die folgenden Eigenschaften:

• In der Testgruppe wird ein zufälliger Anteil der Seitenaufrufe, die als SXG-Seiten eingestuft wurden, zurückgehalten und als Nicht-SXG-Seiten ausgeliefert. So lässt sich das Ergebnis zwischen Äpfeln und Äpfeln Vergleich von gleichwertigen Nutzern, Geräten, Szenarien und Seiten.
• Diese (kontrafaktischen) Seitenaufrufe werden in Analytics entsprechend gekennzeichnet. Dies ermöglicht das Heranzoomen der Daten, um die Anzahl der SXG-Seitenaufrufe in der Kontrollgruppe mit den SXG-Kontrafakten im Test zu vergleichen. Dadurch wird wiederum das Rauschen durch andere Seitenaufbauvorgänge reduziert, die vom SXG-Prefetch nicht betroffen wären.

Dadurch würden die oben erwähnten möglichen Quellen der Auswahlverzerrung beseitigt, das Risiko der LCP-Selektivitätsverzerrung jedoch nicht eliminiert. Beide Eigenschaften erfordern zur Aktivierung entweder den Browser oder die Referrer-URL.

Fazit

Geschafft! Das war eine Menge. Hoffentlich lassen sich damit ein umfassenderes Bild davon gewinnen, wie die SXG-Leistung in einem Labortest getestet werden kann, wie die Leistung in einer engen Feedback-Schleife mit dem Labortest optimiert werden kann und wie schließlich die Leistung in der Praxis gemessen werden kann. Wenn Sie all dies kombinieren, können Sie SXGs optimal nutzen und dafür sorgen, dass Ihre Website und Ihre Nutzer davon profitieren.

Wenn du weitere Ratschläge zur Erfassung der SXG-Leistung hast, kannst du dich gern an uns wenden. Melden Sie den Fehler unter developer.chrome.com und fügen Sie Verbesserungsvorschläge hinzu.

Weitere Informationen zu Signed Exchanges findest du in der web.dev-Dokumentation und in der Dokumentation zur Google Suche.