Core/Dash Dimensie: 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

harvardmarktplaatsfotocasamy work featured on web.deverasmusmcwhowhatwearkpnaleteiaperionnina careworkivacomparevpnloopearplugsmonarchsnvsaturndpg mediaebaynestlehappyhorizonadevinta

Wat Navigation Origin meet

De dimensie Navigation Origin splitst je veldgegevens 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 elk geval totaal verschillend zijn. Een same-origin navigatie kan een bestaande verbinding hergebruiken, subbronnen uit de HTTP-cache halen en profiteren van eventuele prefetching die je site heeft ingesteld. Een cross-origin navigatie begint helemaal vanaf nul.

Waarom cross-origin navigaties trager zijn

Wanneer een gebruiker op een link van een externe site klikt, heeft de browser werk te doen voordat deze je HTML überhaupt kan opvragen:

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

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

Gecachte subbronnen zijn ook niet beschikbaar. Een bezoeker die via Google is doorgeklikt, heeft geen gecachte kopie van je lettertypen, hero-afbeelding of kritieke CSS. Een bezoeker die zojuist van je homepage kwam, heeft deze 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 met dezelfde betrouwbaarheid kunnen benutten.

Ten eerste stelt de Speculation Rules API je in staat om interne pagina's te pre-fetchen of te pre-renderen voordat de gebruiker klikt. De browser kan de volgende pagina al volledig gerenderd hebben in een achtergrondtabblad, waardoor de navigatie direct verloopt. Dit geldt uitsluitend voor same-origin bestemmingen.

Ten tweede herstelt de back-forward cache (bfcache) een pagina vanuit het geheugen wanneer de gebruiker op de terugknop drukt. Bfcache hits zijn extreem snel en scoren goed over de gehele linie van je 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 je deze dimensie in CoreDash leest

coredash metric table urls

Gebruik Navigation Origin in CoreDash als een filter of als een uitsplitsingsdimensie naast elke willekeurige metriek. De meest nuttige vergelijking is LCP op basis van navigatieoorsprong. Een groot verschil tussen same-origin en cross-origin LCP vertelt je één van drie dingen:

  • Je cross-origin instappagina's hebben een trage TTFB die je LCP verhoogt.
  • Same-origin navigaties profiteren van prefetch of bfcache, maar je cross-origin pagina's doen dat niet.
  • Je gecachte subbronnen helpen terugkerende bezoekers wel, maar niet de nieuwe bezoekers via externe bronnen.

Cross-origin data is doorgaans het belangrijkste cijfer voor SEO. Google's Chrome UX Report (CrUX) bevat alle navigatietypes, 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 deze wel verminderen:

  • Gebruik een CDN met een snelle TTFB. Verbindingsoverhead krimpt wanneer je server zich geografisch dicht bij de gebruiker bevindt en snel reageert. Streef naar een TTFB van minder dan 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, waardoor de tijd tussen de HTML-levering en het renderen van het LCP-element wordt verkort.
  • Inline kritieke CSS. Het ontbreken van render-blocking stylesheetverzoeken betekent dat de browser sneller kan renderen, zelfs bij een koude verbinding.
  • Voeg preconnect hints toe voor third-party origins. Als je LCP-afbeelding of een render-blocking bron op een ander domein wordt gehost, start een rel="preconnect" hint het TCP- en TLS-werk in een vroeg stadium.

Voor same-origin navigaties is de Speculation Rules API momenteel de verbetering met de hoogste impact. Het pre-renderen van de meest waarschijnlijke volgende pagina reduceert de LCP tot bijna nul voor deze overgangen.

Navigation Origin in context

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