Core/Dash Dimension: Navigation Origin

Scopri se i tuoi visitatori arrivano dallo stesso dominio o da fonti esterne, e come questa suddivisione influenza i tuoi Core Web Vitals.

Prova gratuita

Trusted by market leaders · Client results

monarchworkivamarktplaatshappyhorizonerasmusmcdpg mediaaleteiaharvardnina carefotocasakpnadevintanestlesnvloopearplugsvpnsaturncompareperionwhowhatwearebaymy work featured on web.dev

Cosa misura Navigation Origin

La dimensione Navigation Origin suddivide i tuoi dati sul campo in due gruppi:

  • Same Origin (1) — la pagina precedente era sullo stesso dominio.
  • Cross Origin (2) — l'utente è arrivato da un dominio diverso, un motore di ricerca, una piattaforma social, oppure ha digitato l'URL direttamente.

Questa distinzione è importante perché le condizioni di partenza del browser sono completamente diverse in ciascun caso. Una navigazione same-origin può riutilizzare una connessione esistente, attingere dalla cache HTTP per le sotto-risorse e beneficiare di qualsiasi prefetching configurato sul tuo sito. Una navigazione cross-origin parte da zero.

Perché le navigazioni cross-origin sono più lente

Quando un utente clicca un link da un sito esterno, il browser ha del lavoro da fare prima di poter anche solo richiedere il tuo HTML:

  1. Ricerca DNS — risolvere il tuo dominio in un indirizzo IP.
  2. Handshake TCP — aprire una connessione al tuo server.
  3. Negoziazione TLS — completare l'handshake HTTPS.

Insieme questi passaggi aggiungono tipicamente da 200 a 500 ms su una connessione mobile prima che il primo byte della tua pagina sia stato richiesto. Questo costo si riflette direttamente nel Time to First Byte (TTFB), e se il tuo elemento LCP dipende da una risorsa caricata dopo l'arrivo dell'HTML, si propaga anche in un Largest Contentful Paint (LCP) peggiore.

Anche le sotto-risorse in cache non sono disponibili. Un visitatore che ha cliccato da Google non ha una copia in cache dei tuoi font, dell'immagine hero o del CSS critico. Un visitatore che è appena arrivato dalla tua homepage probabilmente ha tutto questo.

Navigazioni same-origin e la back-forward cache

Le navigazioni same-origin aprono la porta a due vantaggi prestazionali che le navigazioni cross-origin non possono sfruttare in modo altrettanto affidabile.

Primo, la Speculation Rules API ti permette di fare prefetch o prerender delle pagine interne prima che l'utente clicchi. Il browser può avere la pagina successiva completamente renderizzata in una scheda in background, rendendo la navigazione istantanea. Questo si applica solo alle destinazioni same-origin.

Secondo, la back-forward cache (bfcache) ripristina una pagina dalla memoria quando l'utente preme il pulsante indietro. I hit della bfcache sono estremamente veloci e ottengono buoni punteggi su tutti i Core Web Vitals. Appaiono nei tuoi dati come navigazioni same-origin. Se il tuo LCP same-origin è significativamente migliore del tuo LCP cross-origin, la bfcache e il prefetch stanno probabilmente contribuendo a quel divario.

Come leggere questa dimensione in CoreDash

coredash metric table urls

In CoreDash, usa Navigation Origin come filtro o come dimensione di suddivisione insieme a qualsiasi metrica. Il confronto più utile è LCP per navigation origin. Un grande divario tra LCP same-origin e cross-origin ti dice una di tre cose:

  • Le tue pagine di ingresso cross-origin hanno un TTFB lento che gonfia il LCP.
  • Le navigazioni same-origin beneficiano di prefetch o bfcache e le tue pagine cross-origin no.
  • Le tue sotto-risorse in cache aiutano i visitatori di ritorno ma non i nuovi arrivi da fonti esterne.

I dati cross-origin sono tipicamente il numero più importante per la SEO. Il Chrome UX Report (CrUX) di Google include tutti i tipi di navigazione, ma il traffico da ricerca organica è quasi interamente cross-origin. Se il tuo LCP cross-origin supera la soglia mentre il tuo LCP same-origin no, è insolito e merita un'indagine. Il contrario è molto più comune.

Ridurre la penalità cross-origin

Non puoi eliminare completamente la penalità del cold-start, ma puoi ridurla:

  • Usa un CDN con un TTFB veloce. L'overhead della connessione si riduce quando il tuo server è geograficamente vicino all'utente e risponde rapidamente. Punta a un TTFB inferiore a 200 ms per il documento HTML.
  • Precarica l'immagine LCP. Un <link rel="preload"> nel <head> avvia il fetch dell'immagine il prima possibile, riducendo il tempo tra la consegna dell'HTML e il paint dell'elemento LCP.
  • Inserisci il CSS critico inline. Nessuna richiesta di foglio di stile che blocca il rendering significa che il browser può effettuare il paint prima anche su una connessione fredda.
  • Aggiungi hint preconnect per origini di terze parti. Se la tua immagine LCP o una risorsa che blocca il rendering è ospitata su un dominio diverso, un hint rel="preconnect" avvia il lavoro TCP e TLS in anticipo.

Per le navigazioni same-origin, la Speculation Rules API è il miglioramento con il maggiore impatto disponibile oggi. Il prerendering della pagina successiva più probabile riduce il LCP quasi a zero per quelle transizioni.

Navigation Origin nel contesto

Navigation Origin funziona bene insieme alla dimensione Navigation Type (che separa navigate, reload, back-forward e prerender) e alla dimensione Effective Connection Type. Una navigazione cross-origin su una connessione lenta è lo scenario più difficile che il tuo sito deve affrontare. Filtrare per entrambe queste condizioni insieme ti mostrerà le tue vere prestazioni nel caso peggiore e dove sono disponibili i miglioramenti più significativi.