Dimensione Core/Dash: Visitatore ricorrente

Dimensione: Comportamento dell'utente: Visitatore ricorrente (fv)

La dimensione Visitatore ricorrente divide i tuoi dati sulle prestazioni in due popolazioni: utenti che hanno già visitato il tuo sito e utenti che non lo hanno fatto. Dal punto di vista ingegneristico, la differenza tra questi gruppi è la cache del browser. Un visitatore ricorrente carica font, script e immagini dal disco. Un nuovo visitatore scarica ogni singolo byte dalla rete.

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

Perché il divario prestazionale è più grande di quanto ti aspetti

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

Nei dati di CoreDash dei siti monitorati, i visitatori ricorrenti mostrano in genere punteggi di LCP inferiori del 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 lontano dall'utente. Sulle pagine con server-side rendering e un elemento LCP testuale, il divario si riduce perché il ritardo di caricamento del testo è quasi nullo per entrambi i gruppi.

Le differenze dell'INP tra i due gruppi sono minori ma comunque presenti. I nuovi visitatori spesso attivano una maggiore analisi di JavaScript al primo caricamento, poiché i bundle dei moduli vengono valutati per la prima volta. I visitatori ricorrenti beneficiano della code cache di V8, che memorizza il bytecode compilato ed evita del tutto la fase di analisi e compilazione. Sulle pagine ricche di JavaScript, questo può far risparmiare da 50 ms a 150 ms sul tempo di elaborazione.

Interpretare i tre valori

0: Visitatore ricorrente

Il browser ha segnalato che questa non è la prima sessione dell'utente sulla tua origine. Le risorse in cache sono disponibili. Sulla maggior parte dei siti editoriali e di marketing monitorati in CoreDash, i visitatori ricorrenti rappresentano dal 55% al 70% di tutte le sessioni. I loro dati sulle prestazioni sono la tua baseline a cache calda: lo scenario migliore per gli utenti reali che conoscono il tuo sito. Se il tuo LCP è scadente qui, il problema non è la cache. Esamina invece le risorse render blocking, il tempo di risposta del server o il ritardo di rendering.

1: Nuovo visitatore

Nessuna cache. Il browser recupera ogni risorsa dalla rete. Questo è lo scenario 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 di LCP sono superiori di 300-700 ms rispetto a quelli dei visitatori ricorrenti sulle pagine basate su immagini. Se il LCP dei tuoi nuovi visitatori fallisce la soglia di 2,5 secondi, mentre quello dei visitatori ricorrenti la rispetta, il tuo obiettivo di ottimizzazione è chiaro: riduci le dimensioni e il ritardo della risorsa LCP stessa, perché non puoi fare affidamento sulla cache per questo pubblico.

2: Non misurato

CoreDash non ha potuto determinare il tipo di visita per questa sessione. Questo si verifica in genere quando il browser blocca l'accesso allo storage necessario per distinguere i nuovi visitatori da quelli ricorrenti, o quando una configurazione del browser orientata alla privacy impedisce il controllo. Sulla maggior parte dei siti, questo bucket rappresenta meno del 5% delle sessioni. Consideralo come un rumore di fondo piuttosto che come un segmento da ottimizzare.

Workflow di debug

1. Stabilisci la tua suddivisione di base: Apri la dimensione Visitatore ricorrente in CoreDash e annota la percentuale di sessioni nuove rispetto a quelle ricorrenti. Se i nuovi visitatori superano il 50% del traffico, le prestazioni a cache fredda rappresentano la tua esperienza utente dominante e devono essere l'obiettivo di ottimizzazione principale.
2. Confronta il LCP per tipo di visita: Filtra solo per i nuovi visitatori e registra il p75 del LCP. Poi filtra per i visitatori ricorrenti e registra la stessa metrica. Un divario superiore a 500 ms indica che il collo di bottiglia risiede nella dimensione delle risorse o nel tempo di recupero dalla rete. Un divario inferiore a 200 ms suggerisce problemi lato rendering che interessano entrambi i gruppi allo stesso modo.
3. Concentrati direttamente sulla risorsa LCP: Per i nuovi visitatori con un LCP lento, la soluzione consiste nel ridurre il tempo di caricamento della risorsa. Comprimi l'immagine LCP, servila da un nodo edge 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. Valida con la dimensione Tipo di navigazione: Esegui un confronto con la dimensione Tipo di navigazione. Le navigazioni di tipo reload e back-forward tendono a concentrarsi sui visitatori ricorrenti. Se il LCP dei visitatori ricorrenti sembra inaspettatamente lento, la causa potrebbe essere un'alta percentuale di navigazioni reload (in cui le risorse memorizzate nella cache vengono rivalidate anziché essere servite direttamente).

Regole empiriche per gli sviluppatori

• Target del LCP per i nuovi visitatori: Meno di 2,5 secondi al p75. Questo è più difficile da raggiungere rispetto al LCP dei visitatori ricorrenti e richiede un vero lavoro sull'infrastruttura: CDN, ottimizzazione delle immagini e corretta fetch priority.
• Divario accettabile tra il LCP dei nuovi visitatori e dei visitatori ricorrenti: 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 falliscono.
• Non misurato inferiore al 5%: Se questo bucket supera il 10%, verifica se un'implementazione del consenso ai cookie o una modifica dei permessi di archiviazione stia bloccando il rilevamento del tipo di visita.

La dimensione Visitatore ricorrente è uno dei primi filtri che applico quando un sito mostra un superamento al limite del LCP. I field data aggregati nascondono la verità. 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 ricorrente fedele, mentre fallisce con ogni nuovo utente che arriva dalla ricerca.