Core/Dash Dimension: Navigation Origin

Sehen Sie, ob Ihre Besucher von derselben Domain oder von externen Quellen kommen, und wie diese Aufteilung Ihre Core Web Vitals prägt.

Kostenlose Testversion

Trusted by market leaders · Client results

snvworkivahappyhorizonharvardcompareloopearplugsfotocasaebayaleteiaperionerasmusmcdpg mediakpnnestlemarktplaatsadevintamonarchsaturnwhowhatwearnina carevpnmy work featured on web.dev

Was Navigation Origin misst

Die Dimension Navigation Origin teilt Ihre Felddaten in zwei Gruppen auf:

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

Dieser Unterschied ist wichtig, da die Startbedingungen des Browsers in jedem Fall völlig unterschiedlich sind. Eine Same-Origin-Navigation kann eine bestehende Verbindung wiederverwenden, für Unterressourcen auf den HTTP-Cache zurückgreifen und von jedem Prefetching profitieren, das Ihre Website eingerichtet hat. Eine Cross-Origin-Navigation fängt bei null an.

Warum Cross-Origin-Navigationen langsamer sind

Wenn ein Benutzer auf einen Link von einer externen Website klickt, muss der Browser arbeiten, 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 typischerweise 200 bis 500 ms bei einer mobilen Verbindung hinzu, bevor das erste Byte Ihrer Seite angefordert wurde. Diese Kosten zeigen sich direkt beim Time to First Byte (TTFB), und wenn Ihr LCP-Element von einer Ressource abhängt, die nach dem Eintreffen des HTML geladen wird, führt dies auch zu einem schlechteren Largest Contentful Paint (LCP).

Gecachte Unterressourcen sind ebenfalls nicht verfügbar. Ein Besucher, der von Google durchgeklickt hat, hat keine im Cache gespeicherte 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 vorzuladen (prefetch) oder vorzurendern (prerender), bevor der Benutzer klickt. Der Browser kann die nächste Seite in einem Hintergrund-Tab vollständig gerendert haben, wodurch die Navigation sofort erfolgt. Dies gilt nur für Same-Origin-Ziele.

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

Wie man diese Dimension in CoreDash liest

coredash metric table urls

Verwenden Sie in CoreDash Navigation Origin als Filter oder als Breakdown-Dimension neben jeder 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 einen langsamen TTFB, der das LCP aufbläht.
  • Same-Origin-Navigationen profitieren von Prefetch oder bfcache und Ihre Cross-Origin-Seiten nicht.
  • Ihre gecachten Unterressourcen helfen wiederkehrenden Besuchern, aber nicht Erstbesuchern von externen Quellen.

Cross-Origin-Daten sind normalerweise 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.

Die Cross-Origin-Strafe reduzieren

Sie können die Kaltstart-Strafe nicht vollständig eliminieren, aber Sie können sie reduzieren:

  • Verwenden Sie ein CDN mit einem schnellen TTFB. Der Verbindungs-Overhead schrumpft, wenn Ihr Server geografisch nah beim Benutzer ist und schnell antwortet. Streben Sie einen TTFB von unter 200 ms für das HTML-Dokument an.
  • Laden Sie das LCP-Bild vor. Ein <link rel="preload"> im <head> startet den Bildabruf so früh wie möglich und verkürzt die Zeit zwischen der HTML-Auslieferung und dem Paint des LCP-Elements.
  • Inlinen Sie Critical CSS. Keine renderblockierende Stylesheet-Anforderung bedeutet, dass der Browser selbst bei einer kalten Verbindung früher rendern kann.
  • Fügen Sie preconnect-Hinweise für Third-Party-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 höchsten Auswirkung, die heute verfügbar ist. Das Prerendering der wahrscheinlichsten nächsten Seite reduziert das LCP für diese Übergänge auf fast null.

Navigation Origin im Kontext

Navigation Origin funktioniert gut zusammen mit der Dimension Navigation Type (die zwischen navigate, reload, back-forward und prerender unterscheidet) und der Dimension Effective Connection Type. Eine Cross-Origin-Navigation über eine langsame Verbindung ist das schwierigste Szenario, mit dem Ihre Website konfrontiert ist. Wenn Sie nach diesen beiden Bedingungen zusammen filtern, sehen Sie Ihre wahre Worst-Case-Performance und wo die größten Verbesserungen möglich sind.