Dimensione Core/Dash: Visitatore di Ritorno

Separa le prestazioni dei nuovi visitatori da quelli di ritorno per scoprire dove i tempi di caricamento a cache fredda stanno penalizzando i dati dei tuoi utenti reali.

Prova gratuita

Trusted by market leaders · Client results

loopearplugsadevintaerasmusmchappyhorizonmarktplaatsmy work featured on web.devnestleebayaleteianina carevpnsnvsaturncomparedpg mediakpnfotocasawhowhatwearworkivamonarchharvardperion

Dimensione: Comportamento Utente: Visitatore di Ritorno (fv)

La dimensione Visitatore di Ritorno divide i dati sulle prestazioni in due popolazioni: gli utenti che hanno già visitato il tuo sito e quelli che non lo hanno fatto. La differenza tecnica tra questi gruppi è la cache del browser. Un visitatore di ritorno carica font, script e immagini dal disco. Un nuovo visitatore recupera ogni byte dalla rete.

Questo è importante perché il tuo punteggio LCP aggregato è una media ponderata di entrambi. Se il 40% delle tue sessioni è costituito da nuovi visitatori, i loro tempi di caricamento a cache fredda alzano il tuo p75. Senza questa dimensione, non puoi dire se una regressione del LCP è un vero problema di infrastruttura o un picco temporaneo nell'acquisizione di nuovi utenti.

coredash new vs returning visitor

Perché il Divario di Prestazioni è Più Ampio di Quanto Ti Aspetti

La cache del browser elimina intere catene di richieste per i visitatori di ritorno. Su un tipico sito di contenuti, un visitatore di ritorno salta la risoluzione DNS, l'handshake TCP, la negoziazione TLS e la risposta del server per ogni risorsa memorizzata nella cache. La risorsa LCP stessa viene spesso servita dalla cache di memoria in meno di 5 ms anziché impiegare dai 200 ms agli 800 ms sulla rete. Non si tratta di un miglioramento marginale: è una differenza strutturale nel modo in cui la pagina si carica.

Nei dati di CoreDash sui siti monitorati, i visitatori di ritorno mostrano in genere punteggi LCP inferiori dal 35% al 60% rispetto ai nuovi visitatori sulle stesse pagine. Il divario è più ampio sulle pagine ricche di immagini, dove l'immagine hero è grande e il server di origine è geograficamente distante dall'utente. Sulle pagine con rendering lato server e un elemento di testo per il LCP, il divario si riduce perché il ritardo di caricamento del testo è quasi nullo per entrambi i gruppi.

Le differenze di INP tra i due gruppi sono più piccole ma comunque presenti. I nuovi visitatori spesso innescano un maggiore parsing di JavaScript al primo caricamento, poiché i bundle di moduli vengono valutati per la prima volta. I visitatori di ritorno beneficiano della cache del codice di V8, che memorizza il bytecode compilato e salta completamente il passaggio di parsing e compilazione. Sulle pagine cariche di JavaScript, questo può ridurre il tempo di elaborazione di 50-150 ms.

Leggere i Tre Valori

0: Visitatore di Ritorno

Il browser ha segnalato che questa non è la prima sessione dell'utente sulla tua origine. Sono disponibili risorse memorizzate nella cache. Sulla maggior parte dei siti editoriali e di marketing tracciati in CoreDash, i visitatori di ritorno costituiscono dal 55% al 70% di tutte le sessioni. I loro dati sulle prestazioni sono la tua linea di base a cache calda: lo scenario migliore per gli utenti reali che conoscono il tuo sito. Se il tuo LCP è scarso qui, il problema non è la cache. Cerca invece risorse render-blocking, tempi di risposta del server o ritardi di rendering.

1: Nuovo Visitatore

Nessuna cache. Il browser recupera ogni singola risorsa dalla rete. Questo è il caso peggiore a cache fredda e rappresenta la prima impressione per ogni utente che ti trova tramite ricerca organica, un annuncio a pagamento o una condivisione sui social. I nuovi visitatori rappresentano in genere dal 30% al 45% delle sessioni. I loro punteggi LCP sono di 300-700 ms più alti rispetto ai visitatori di ritorno su pagine basate su immagini. Se il LCP per i nuovi visitatori fallisce la soglia di 2,5 secondi ma il LCP dei visitatori di ritorno la supera, il tuo obiettivo di ottimizzazione è chiaro: riduci le dimensioni e il ritardo della risorsa LCP stessa, poiché non puoi fare affidamento sulla cache per questo pubblico.

2: Non Misurato

CoreDash non è riuscito a determinare il tipo di visita per questa sessione. Questo accade in genere quando il browser blocca l'accesso allo storage necessario per distinguere i nuovi visitatori da quelli di ritorno, o quando una configurazione del browser incentrata sulla privacy impedisce il controllo. Sulla maggior parte dei siti, questo gruppo rappresenta meno del 5% delle sessioni. Trattalo come un rumore di fondo piuttosto che un segmento per cui ottimizzare.

Flusso di Lavoro per il Debugging

  1. Stabilisci la tua ripartizione di base: Apri la dimensione Visitatore di Ritorno in CoreDash e annota la percentuale di sessioni nuove rispetto a quelle di ritorno. Se i nuovi visitatori superano il 50% del traffico, le prestazioni a cache fredda sono la tua user experience dominante e devono essere l'obiettivo primario di ottimizzazione.
  2. Confronta il LCP per tipo di visita: Filtra solo per i nuovi visitatori e registra il p75 per il LCP. Quindi filtra per i visitatori di ritorno e registra la stessa metrica. Un divario superiore a 500 ms indica che la dimensione dell'asset o il tempo di recupero dalla rete rappresentano il collo di bottiglia. Un divario inferiore a 200 ms suggerisce problemi lato rendering che influenzano entrambi i gruppi allo stesso modo.
  3. Punta direttamente alla risorsa LCP: Per i nuovi visitatori con un LCP lento, la soluzione consiste nel ridurre il tempo di caricamento della risorsa. Comprimi l'immagine del LCP, servila da un nodo edge della CDN vicino ai tuoi utenti e applica fetchpriority="high". Questi vantaggi persistono indipendentemente dallo stato della cache. Non fare affidamento sulla cache per compensare una risorsa LCP sovradimensionata o servita lentamente.
  4. Convalida con la dimensione Navigation Type: Incrocia i dati con la dimensione Navigation Type. Le navigazioni di ricaricamento (reload) e avanti-indietro (back-forward) tendono verso i visitatori di ritorno. Se il LCP dei visitatori di ritorno appare inaspettatamente lento, un'alta percentuale di navigazioni di ricaricamento (dove le risorse in cache vengono riconvalidate anziché servite direttamente) potrebbe esserne la ragione.

Regole Generali di Ingegneria

  • Obiettivo LCP per nuovi visitatori: Sotto i 2,5 secondi al p75. Questo è più difficile da raggiungere rispetto al LCP dei visitatori di ritorno e richiede un vero lavoro di infrastruttura: CDN, ottimizzazione delle immagini e corretta priorità di recupero (fetch priority).
  • Divario accettabile tra il LCP dei nuovi visitatori e quelli di ritorno: Fino a 400 ms. Un divario maggiore indica che il tuo sito dipende dalla cache del browser per superare i Core Web Vitals, il che significa che le prime impressioni stanno fallendo.
  • Non Misurato sotto il 5%: Se questo gruppo cresce oltre il 10%, indaga se l'implementazione del consenso ai cookie o una modifica alle autorizzazioni di archiviazione (storage access) stia bloccando il rilevamento del tipo di visita.

La dimensione Visitatore di Ritorno è uno dei primi filtri che applico quando un sito mostra un superamento al limite sul LCP. I dati aggregati raccolti sul campo nascondono la vera storia. La suddivisione per tipo di visita mostra immediatamente se il lavoro di ottimizzazione è solido o se il sito sta vivendo di rendita sui cache hit di un pubblico fedele di ritorno, mentre fallisce con ogni nuovo utente che arriva dalla ricerca.