Core/Dash Dimension: Navigation Origin

Bekijk of je bezoekers afkomstig zijn van hetzelfde domein of van externe bronnen, en hoe die verdeling je Core Web Vitals beïnvloedt.

Gratis proefperiode

Trusted by market leaders · Client results

adevintaloopearplugsdpg mediacomparemarktplaatsnestleharvardmonarchfotocasavpnsnvkpnperionebayerasmusmcaleteiawhowhatwearmy work featured on web.devnina caresaturnhappyhorizonworkiva

Wat Navigation Origin meet

De Navigation Origin-dimensie splitst je field data in twee groepen:

  • Same Origin (1) — de vorige pagina bevond zich op hetzelfde domein.
  • Cross Origin (2) — de gebruiker is afkomstig van een ander domein, een zoekmachine, een sociaal platform, of heeft de URL direct ingetypt.

Dit onderscheid is belangrijk omdat de startvoorwaarden van de browser in beide gevallen compleet anders zijn. Een same-origin navigatie kan een bestaande verbinding hergebruiken, putten uit de HTTP-cache voor subresources, en profiteren van eventuele prefetching die je site heeft ingesteld. Een cross-origin navigatie begint vanaf nul.

Waarom cross-origin navigaties langzamer zijn

Wanneer een gebruiker op een link van een externe site klikt, moet de browser werk verzetten voordat deze zelfs maar je HTML kan opvragen:

  1. DNS lookup — je domein herleiden naar een IP-adres.
  2. TCP handshake — een verbinding openen met je server.
  3. TLS negotiation — de HTTPS-handshake voltooien.

Samen voegen deze stappen doorgaans 200 tot 500 ms toe op een mobiele verbinding voordat de eerste byte van je pagina is opgevraagd. Die kosten zijn direct zichtbaar in Time to First Byte (TTFB), en als je LCP-element afhankelijk is van een resource die wordt geladen nadat de HTML arriveert, leidt dit ook tot een slechtere Largest Contentful Paint (LCP).

Gecachete subresources zijn ook niet beschikbaar. Een bezoeker die doorklikt vanuit Google heeft geen gecachete kopie van je lettertypen, hero-afbeelding of kritieke CSS. Een bezoeker die net van je homepage afkomt, heeft die waarschijnlijk allemaal wel.

Same-origin navigaties en de back-forward cache

Same-origin navigaties openen de deur naar twee prestatievoordelen die cross-origin navigaties niet zo betrouwbaar kunnen gebruiken.

Ten eerste laat de Speculation Rules API je interne pagina's prefetch of prerenderen voordat de gebruiker klikt. De browser kan de volgende pagina al volledig in een achtergrondtabblad gerenderd hebben, waardoor de navigatie direct verloopt. Dit geldt alleen voor same-origin bestemmingen.

Ten tweede herstelt de back-forward cache (bfcache) een pagina uit het geheugen wanneer de gebruiker op de terugknop drukt. Bfcache-hits zijn extreem snel en scoren goed over alle Core Web Vitals. Ze verschijnen in je data als same-origin navigaties. Als je same-origin LCP aanzienlijk beter is dan je cross-origin LCP, dragen bfcache en prefetch waarschijnlijk bij aan dat verschil.

Hoe lees je deze dimensie in CoreDash

coredash metric table urls

Gebruik Navigation Origin in CoreDash als filter of als breakdown-dimensie naast een willekeurige metric. De nuttigste vergelijking is LCP op basis van navigation origin. Een groot verschil tussen same-origin en cross-origin LCP vertelt je een van de volgende drie dingen:

  • Je cross-origin landingspagina's hebben een trage TTFB die de LCP opdrijft.
  • Same-origin navigaties profiteren van prefetch of bfcache en je cross-origin pagina's niet.
  • Je gecachete subresources helpen terugkerende bezoekers, maar niet de bezoekers die voor het eerst via externe bronnen arriveren.

Cross-origin data is voor SEO meestal het belangrijkste getal. Google's Chrome UX Report (CrUX) omvat alle navigatietypen, maar organisch zoekverkeer is vrijwel uitsluitend cross-origin. Als je cross-origin LCP slaagt terwijl je same-origin LCP faalt, is dat ongebruikelijk en de moeite waard om te onderzoeken. Het omgekeerde komt veel vaker voor.

De cross-origin penalty verminderen

Je kunt de cold-start penalty niet volledig elimineren, maar je kunt hem wel verminderen:

  • Gebruik een CDN met een snelle TTFB. De verbindings-overhead krimpt wanneer je server geografisch dicht bij de gebruiker staat en snel reageert. Streef naar een TTFB onder de 200 ms voor het HTML-document.
  • Preload de LCP-afbeelding. Een <link rel="preload"> in de <head> start het ophalen van de afbeelding zo vroeg mogelijk, wat de tijd tussen het afleveren van de HTML en het painten van het LCP-element verkort.
  • Kritieke CSS inlinen. Zonder een render-blocking stylesheet verzoek kan de browser sneller beginnen met painten, zelfs op een koude verbinding.
  • Voeg preconnect hints toe voor third-party origins. Als je LCP-afbeelding of een render-blocking resource op een ander domein wordt gehost, start een rel="preconnect" hint het TCP- en TLS-werk al vroeg.

Voor same-origin navigaties is de Speculation Rules API de verbetering met de grootste impact die momenteel beschikbaar is. Het prerenderen van de meest waarschijnlijke volgende pagina brengt LCP voor die overgangen terug tot bijna nul.

Navigation Origin in context

Navigation Origin werkt goed samen met de Navigation Type-dimensie (die navigate, reload, back-forward en prerender scheidt) en de Effective Connection Type-dimensie. Een cross-origin navigatie op een trage verbinding is het zwaarste scenario waarmee je site te maken krijgt. Door op deze twee voorwaarden tegelijk te filteren, zie je je ware worst-case performance en waar de grootste verbeteringen te behalen zijn.