Dimensione Core/Dash: Navigation Origin

Cosa misura Navigation Origin

La dimensione Navigation Origin divide 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, da un motore di ricerca, da una piattaforma social, o ha digitato direttamente l'URL.

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 alla cache HTTP per le sottorisorse e beneficiare di qualsiasi prefetching configurato dal tuo sito. Una navigazione cross-origin riparte da zero.

Perché le navigazioni cross-origin sono più lente

Quando un utente fa clic su un link da un sito esterno, il browser ha del lavoro da fare prima ancora di poter richiedere il tuo HTML:

1. Risoluzione DNS — risolve il tuo dominio in un indirizzo IP.
2. Handshake TCP — apre una connessione con il tuo server.
3. Negoziazione TLS — completa l'handshake HTTPS.

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

Inoltre, le sottorisorse memorizzate nella cache non sono disponibili. Un visitatore che ha fatto clic su un link da Google non ha una copia nella cache dei tuoi font, dell'immagine hero o del CSS critico. Un visitatore che è appena arrivato dalla tua homepage probabilmente ha già tutto questo.

Navigazioni same-origin e back-forward cache

Le navigazioni same-origin aprono le porte a due vantaggi in termini di prestazioni che le navigazioni cross-origin non possono sfruttare in modo altrettanto affidabile.

In primo luogo, la Speculation Rules API ti consente di effettuare il prefetch o il prerender delle pagine interne prima che l'utente faccia clic. 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.

In secondo luogo, la back-forward cache (bfcache) ripristina una pagina dalla memoria quando l'utente preme il pulsante Indietro. Gli hit della bfcache sono estremamente veloci e ottengono ottimi punteggi in tutti i Core Web Vitals. Appaiono nei tuoi dati come navigazioni same-origin. Se il tuo LCP same-origin è significativamente migliore rispetto a quello cross-origin, è probabile che bfcache e prefetch stiano contribuendo a questo divario.

Come leggere questa dimensione in CoreDash

In CoreDash, usa Navigation Origin come filtro o come dimensione di raggruppamento (breakdown) insieme a qualsiasi metrica. Il confronto più utile è l'LCP per origine della navigazione. Un ampio divario tra l'LCP same-origin e cross-origin ti indica una di queste tre cose:

• Le tue pagine di ingresso cross-origin hanno un TTFB lento che fa gonfiare l'LCP.
• Le navigazioni same-origin beneficiano di prefetch o bfcache, mentre le tue pagine cross-origin no.
• Le tue sottorisorse memorizzate nella cache aiutano i visitatori di ritorno, ma non i nuovi arrivati da fonti esterne.

I dati cross-origin rappresentano in genere il numero più importante per la SEO. Il Chrome UX Report (CrUX) di Google include tutti i tipi di navigazione, ma il traffico di ricerca organica è quasi interamente cross-origin. Se il tuo LCP cross-origin passa mentre il tuo LCP same-origin fallisce, è insolito e vale la pena indagare. Il contrario è molto più comune.

Ridurre la penalità cross-origin

Non è possibile eliminare del tutto la penalità del cold-start, ma è possibile ridurla:

• Usa una CDN con un TTFB veloce. L'overhead di 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.
• Fai il preload dell'immagine LCP. Un <link rel="preload"> all'interno dell'<head> avvia il recupero dell'immagine il prima possibile, riducendo il tempo tra la consegna dell'HTML e il paint dell'elemento LCP.
• Rendi inline il CSS critico. L'assenza di una richiesta per fogli di stile render-blocking significa che il browser può eseguire il paint prima, persino su una connessione a freddo.
• Aggiungi suggerimenti preconnect per origini di terze parti. Se la tua immagine LCP o una risorsa render-blocking è ospitata su un dominio diverso, un suggerimento rel="preconnect" avvia in anticipo il lavoro TCP e TLS.

Per le navigazioni same-origin, la Speculation Rules API è il miglioramento con il maggiore impatto oggi disponibile. Il prerendering della pagina successiva più probabile azzera quasi completamente l'LCP 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 queste due condizioni insieme ti mostrerà le tue vere prestazioni nel caso peggiore e dove sono disponibili i maggiori miglioramenti.