Core/Dash Dimension: Navigation Origin

Was Navigation Origin misst

Die Dimension Navigation Origin unterteilt Ihre Felddaten in zwei Gruppen:

• Same Origin (1) — die vorherige Seite befand sich auf derselben Domain.
• Cross Origin (2) — der Nutzer kam von einer anderen Domain, einer Suchmaschine, einer sozialen Plattform oder hat die URL direkt eingegeben.

Diese Unterscheidung ist wichtig, da die Startbedingungen des Browsers in beiden Fällen völlig unterschiedlich sind. Eine Same-Origin-Navigation kann eine bestehende Verbindung wiederverwenden, auf den HTTP-Cache für Subressourcen zurückgreifen und von jeglichem Prefetching profitieren, das Sie auf Ihrer Website eingerichtet haben. Eine Cross-Origin-Navigation fängt ganz von vorne an.

Warum Cross-Origin-Navigationen langsamer sind

Wenn ein Nutzer auf einen Link von einer externen Website klickt, hat der Browser einiges zu tun, bevor er überhaupt Ihr HTML anfordern kann:

1. DNS-Lookup — löst Ihre Domain in eine IP-Adresse auf.
2. TCP-Handshake — öffnet eine Verbindung zu Ihrem Server.
3. TLS-Negotiation — schließt den HTTPS-Handshake ab.

Zusammen fügen diese Schritte bei einer mobilen Verbindung typischerweise 200 bis 500 ms hinzu, bevor das erste Byte Ihrer Seite angefordert wurde. Diese Kosten spiegeln sich direkt in Time to First Byte (TTFB) wider, und wenn Ihr LCP-Element von einer Ressource abhängt, die nach dem Eintreffen des HTML geladen wird, kaskadieren sie auch in einen schlechteren Largest Contentful Paint (LCP).

Zwischengespeicherte Subressourcen sind ebenfalls nicht verfügbar. Ein Besucher, der von Google durchgeklickt hat, besitzt keine zwischengespeicherte Kopie Ihrer Schriftarten, Ihres Hero-Images oder Ihres Critical CSS. Ein Besucher, der gerade von Ihrer Startseite kam, hat wahrscheinlich all das.

Same-Origin-Navigationen und der Back-Forward Cache

Same-Origin-Navigationen öffnen die Tür zu zwei Leistungsvorteilen, die Cross-Origin-Navigationen nicht so zuverlässig nutzen können.

Erstens ermöglicht Ihnen die Speculation Rules API, interne Seiten vorab zu laden (Prefetch) oder zu rendern (Prerender), bevor der Nutzer klickt. Der Browser kann die nächste Seite in einem Hintergrund-Tab vollständig rendern lassen, wodurch die Navigation sofort erfolgt. Dies gilt nur für Same-Origin-Ziele.

Zweitens stellt der Back-Forward Cache (bfcache) eine Seite aus dem Arbeitsspeicher wieder her, wenn der Nutzer die Zurück-Taste drückt. Bfcache-Treffer sind extrem schnell und schneiden bei allen Core Web Vitals gut ab. Sie erscheinen in Ihren Daten als Same-Origin-Navigationen. Wenn Ihr Same-Origin-LCP deutlich besser ist als Ihr Cross-Origin-LCP, tragen wahrscheinlich bfcache und Prefetch zu dieser Lücke bei.

So lesen Sie diese Dimension in CoreDash

Verwenden Sie Navigation Origin in CoreDash als Filter oder als Breakdown-Dimension zusammen mit einer beliebigen Metrik. Der nützlichste Vergleich ist LCP nach Navigation Origin. Eine große Lücke zwischen Same-Origin- und Cross-Origin-LCP sagt Ihnen eines von drei Dingen:

• Ihre Cross-Origin-Einstiegsseiten haben eine langsame TTFB, die LCP aufbläht.
• Same-Origin-Navigationen profitieren von Prefetch oder bfcache und Ihre Cross-Origin-Seiten nicht.
• Ihre zwischengespeicherten Subressourcen helfen wiederkehrenden Besuchern, aber nicht Erstankömmlingen aus externen Quellen.

Cross-Origin-Daten sind typischerweise die wichtigere Zahl für SEO. Der Chrome UX Report (CrUX) von Google umfasst alle Navigationstypen, aber organischer Such-Traffic ist fast ausschließlich Cross-Origin. Wenn Ihr Cross-Origin-LCP besteht, während Ihr Same-Origin-LCP fehlschlägt, ist das ungewöhnlich und eine Untersuchung wert. Das Gegenteil ist weitaus häufiger der Fall.

Reduzierung des Cross-Origin-Nachteils

Sie können den Kaltstart-Nachteil nicht vollständig eliminieren, aber Sie können ihn reduzieren:

• Verwenden Sie ein CDN mit einer schnellen TTFB. Der Verbindungs-Overhead schrumpft, wenn Ihr Server dem Nutzer geografisch nahe ist und schnell antwortet. Zielen Sie auf eine TTFB unter 200 ms für das HTML-Dokument ab.
• Laden Sie das LCP-Bild vorab. Ein <link rel="preload"> im <head> startet den Abruf des Bildes so früh wie möglich und verkürzt die Zeit zwischen der HTML-Bereitstellung und dem Paint des LCP-Elements.
• Inlinen Sie Critical CSS. Keine renderblockierende Stylesheet-Anforderung bedeutet, dass der Browser auch bei einer kalten Verbindung früher rendern kann.
• Fügen Sie preconnect-Hinweise für Drittanbieter-Origins hinzu. Wenn Ihr LCP-Bild oder eine renderblockierende Ressource auf einer anderen Domain gehostet wird, startet ein rel="preconnect"-Hinweis die TCP- und TLS-Arbeit frühzeitig.

Für Same-Origin-Navigationen ist die Speculation Rules API die Verbesserung mit der derzeit höchsten Auswirkung. Das Prerendering der wahrscheinlichsten nächsten Seite senkt LCP für diese Übergänge auf nahezu null.

Navigation Origin im Kontext

Navigation Origin funktioniert gut zusammen mit der Dimension Navigation Type (die zwischen navigate, reload, back-forward und prerender trennt) und der Dimension Effective Connection Type. Eine Cross-Origin-Navigation bei einer langsamen Verbindung ist das härteste Szenario, dem Ihre Website ausgesetzt ist. Das Filtern nach diesen beiden Bedingungen zusammen zeigt Ihnen Ihre wahre Worst-Case-Leistung und wo die größten Verbesserungen möglich sind.