Core Web Vitals: quanto ti costa far aspettare chi apre il tuo sito

Hai mai premuto un pulsante senza vedere succedere nulla, e ripetuto il gesto per sicurezza? Hai aspettato davanti a uno schermo rimasto bianco, o perso la riga che stavi leggendo perché un banner l’ha spinta giù? Sono fastidi, frustrazioni, esperienze negative che ti fanno chiudere la scheda e tornare ai risultati di ricerca.

Capita anche a chi entra nel tuo sito, e Google ne tiene il conto con i Core Web Vitals, il voto che dà all’esperienza che offri. Si sono sgonfiati quasi da subito e sembrano contare anche meno ora che c’è l’AI, che prende ciò che trova nelle pagine senza cliccare nulla né aspettare.

Chi ti sceglie, però, arriva ancora da te: per comprare, per chiedere un preventivo, per leggere fino in fondo. E davanti a un’attesa o a un pulsante muto se ne va, come ha sempre fatto.

Che cosa sono i Core Web Vitals

I Core Web Vitals, in italiano Segnali web essenziali, sono gli indicatori con cui Google valuta l’esperienza d’uso di una pagina web: la rapidità con cui ne compare il contenuto principale, la prontezza con cui risponde ai comandi, la stabilità degli elementi durante la consultazione. A ciascun aspetto corrisponde una metrica: Largest Contentful Paint (LCP) per il caricamento, Interaction to Next Paint (INP) per la reattività, Cumulative Layout Shift (CLS) per la stabilità visiva.

Apri dal telefono la pagina del tuo sito che conta di più, una scheda prodotto o un modulo di contatto, e prova a usarla. Il Largest Contentful Paint è il tempo che aspetti prima di vedere l’elemento più grande nella porzione di schermo visibile senza scorrere, di solito la foto del prodotto o il titolo. L’Interaction to Next Paint è l’intervallo fra il tocco su una taglia o su un campo e la risposta della schermata. Il Cumulative Layout Shift esprime quanto si spostano prezzo e pulsanti se, mentre li guardi, sopra di loro compare un banner.

Se controlli soltanto quanto impiega la pagina ad aprirsi, ti sfugge ciò che succede dopo: il pulsante del carrello che reagisce con mezzo secondo di ritardo, l’annuncio che spinge in basso il testo mentre il cliente legge. Una pagina che si apre in un secondo può fallire la valutazione anche per uno solo di questi motivi.

Nel giudizio finiscono le visite di chi usa il sito ogni giorno. Il browser Chrome registra quei tempi mentre le persone navigano, e Google li raccoglie dagli utenti che hanno acconsentito a condividere le statistiche d’uso. Se dal computer dell’ufficio il sito ti sembra immediato, tieni presente che nel conto entra anche chi lo apre da un telefono economico su una rete mobile debole.

I Core Web Vitals registrano soltanto visite di persone. Googlebot e i crawler con cui OpenAI, Anthropic e Perplexity alimentano ChatGPT, Claude e Perplexity scaricano le pagine senza che un browser le mostri a qualcuno, e nessun tempo viene registrato. Chi invece clicca una fonte citata in una di quelle risposte entra nel sito come qualunque altro visitatore, e la sua attesa si somma a quella degli altri clienti.

Perché Google ha scelto di misurare l’esperienza di chi visita

PageSpeed Insights, Lighthouse, il pannello Audits degli strumenti per sviluppatori di Chrome, il rapporto sulla velocità di Search Console, i rapporti Velocità del sito di Google Analytics, Test My Site. Fino al 2020, per capire se il tuo sito era veloce e dove non lo era, dovevi consultarli uno per uno. Ciascuno rispondeva con metriche proprie: un punteggio da 0 a 100, un indice di velocità, un tempo medio di caricamento, una classificazione degli indirizzi in lenti, medi e veloci.

La stessa scheda prodotto poteva prendere 40 punti in PageSpeed Insights ed essere classificata «veloce» in Search Console. A quel punto dovevi decidere quale numero credere, prima ancora di capire che cosa chiedere allo sviluppatore.

Un’abbondanza di metriche e strumenti che creava problemi di priorità, chiarezza e coerenza, e che Google stessa riconobbe. La risposta fu una guida unica, con poche metriche valide per ogni sito, ciascuna con una soglia che dice senza ambiguità se una pagina è buona o scarsa. Così la spiegò Ilya Grigorik, all’epoca ingegnere di Google dedicato alle prestazioni web, presentandola nel maggio 2020 sul blog di Chromium, la base open source da cui nasce Chrome.

Con i Core Web Vitals cambia anche ciò che osservi. Gli indicatori tradizionali seguivano eventi tecnici, come l’evento load, che il browser segnala quando ha scaricato ogni risorsa, script pubblicitari compresi. Una pagina poteva essere leggibile da due secondi e completare il load dopo otto, per colpa di un widget in fondo al codice. Oppure poteva completarlo presto e restare bloccata al primo tocco del cliente, mentre uno script lavorava in background.

Le nuove metriche seguono ciò che il visitatore vede sullo schermo e ciò che accade dopo il suo tocco. Con un riferimento così puoi parlare del problema con sviluppatori, redazione e reparto vendite usando lo stesso dato e la stessa soglia, e chiedere a ciascuno qualcosa di preciso: quale metrica cede, su quali pagine, da quale data.

Quali sono i Core Web Vitals: LCP, INP e CLS

Le definizioni di LCP, INP e CLS sono pubbliche e documentate su web.dev, il sito con cui il team di Chrome spiega le tecnologie del web, e ogni strumento che le calcola, da Search Console a PageSpeed Insights fino alle librerie installabili sul sito, applica le stesse regole. Nella documentazione trovi anche le esclusioni: quale elemento non può diventare LCP, quali gesti l’INP non conta, quali spostamenti il CLS ignora.

• LCP. Il Largest Contentful Paint è il tempo che passa dall’inizio della navigazione al momento in cui il browser disegna l’elemento di contenuto più grande visibile nel viewport, la porzione di schermo che compare senza scorrere. L’elemento può essere un’immagine, il primo fotogramma di un video, uno sfondo caricato dal foglio di stile o un blocco di testo. Su una scheda prodotto logo e menu compaiono quasi subito, ma per l’LCP la schermata è pronta solo quando arriva la foto, che occupa più spazio di tutto il resto. Su un articolo senza immagine d’apertura l’elemento conteggiato è spesso il titolo, e il suo tempo dipende soprattutto da font e fogli di stile. Il browser aggiorna il candidato ogni volta che disegna un elemento più grande, e smette alla prima interazione: un tocco, un tasto, uno scroll. Dal calcolo restano esclusi gli elementi trasparenti, gli sfondi che coprono l’intero schermo e le immagini sgranate usate come segnaposto. Se il tuo tema carica prima un’anteprima sfocata della foto, l’LCP scatta solo quando arriva la versione definitiva.
• INP. L’Interaction to Next Paint è la latenza fra un’interazione e il primo aggiornamento dello schermo che ne mostra l’effetto. Conta clic, tocchi e pressioni di tasti, fisici o virtuali, lungo tutta la visita. Scroll, passaggio del mouse e zoom restano fuori. Fra il tocco su «aggiungi al carrello» e il contatore che si aggiorna, il browser deve finire il lavoro che aveva in corso, eseguire il codice collegato al pulsante e ridisegnare la schermata. Se una di queste fasi si allunga, il cliente tocca di nuovo, e a volte aggiunge due volte lo stesso prodotto. Il valore di una visita coincide di solito con l’interazione più lenta. Su un articolo basta un menu lento per rendere scarso il dato. Su un catalogo pesa il filtro che si blocca a ogni uso, anche se tutto il resto risponde subito.
• CLS. Il Cumulative Layout Shift quantifica gli spostamenti inattesi degli elementi visibili, cioè i cambi di posizione che avvengono senza un’azione di chi guarda. Ogni spostamento riceve un punteggio che moltiplica la porzione di schermo coinvolta per la distanza percorsa, entrambe in proporzione al viewport, e per questo il CLS è un numero senza unità di misura. Un blocco che, fra posizione di partenza e d’arrivo, interessa tre quarti dello schermo e scende di un quarto dell’altezza produce un punteggio di 0,1875, quasi il doppio della soglia buona. Gli spostamenti provocati da chi usa la pagina non contano: quelli che arrivano entro mezzo secondo da un clic o da un tasto, e le animazioni costruite con la proprietà CSS transform, che muovono un elemento senza spingere gli altri. Se il tuo menu a tendina sposta giù il contenuto quando lo apri, il CLS lo ignora. Se lo fa un banner dei cookie comparso da solo, lo registra.

Ogni metrica ha una soglia sotto cui l’esperienza è buona e una oltre cui è scarsa, con la fascia «da migliorare» nel mezzo. Le soglie si applicano al 75° percentile delle visite, cioè al valore che tre visite su quattro rispettano.

Metrica	Che cosa vive chi apre la pagina	Buono	Scarso
LCP	aspetta il contenuto principale	fino a 2,5 s	oltre 4 s
INP	tocca, clicca o digita e aspetta la risposta	fino a 200 ms	oltre 500 ms
CLS	vede testo e pulsanti spostarsi	fino a 0,1	oltre 0,25

Da dove vengono le soglie di 2,5 secondi, 200 millisecondi e 0,1

Le soglie dei Core Web Vitals rispondono a un doppio criterio: ogni valore doveva descrivere un’esperienza che le persone giudicano buona e, insieme, essere già alla portata di una buona parte dei siti. Google lo ha illustrato in un’analisi su web.dev.

Per il caricamento, la base sono gli studi sull’attenzione di Card, Miller e Newell, secondo cui una risposta sembra rapida fino a circa 3 secondi. Per la reattività, un esperimento dello psicologo Albert Michotte del 1962: sotto i 100 millisecondi circa, un gesto e la sua conseguenza sembrano un’unica azione. Per la stabilità mancavano studi, e i test interni hanno mostrato che gli spostamenti oltre 0,15 risultano sempre fastidiosi.

La soglia dell’INP vale il doppio del limite osservato da Michotte. Con un INP di 180 millisecondi la tua pagina è promossa, ma chi tocca un pulsante può ancora avvertire lo stacco. Se il sito vive di filtri, configuratori e carrelli, 200 millisecondi sono il minimo da garantire.

Le soglie sono identiche su mobile e desktop, perché ciò che una persona si aspetta non dipende dal dispositivo che ha in mano. Cambiano le condizioni: sul telefono il processore è più lento e la rete meno stabile, e la stessa pagina fatica di più a restarci sotto.

Perché le metriche osservano tutta la visita, e il FID non basta più

Nel 2020 i Core Web Vitals erano LCP, CLS e First Input Delay (FID), il ritardo della prima interazione, e Google aveva previsto di rivederne l’elenco ogni anno. Le revisioni sono arrivate più di rado, ma tutte nella stessa direzione, dai primi istanti della visita alla visita intera.

Nel giugno 2021 è cambiato il calcolo del CLS. Fino ad allora si sommavano tutti gli spostamenti finché la pagina restava aperta, e un articolo lungo o una pagina a scorrimento infinito accumulavano punti solo perché chi leggeva ci restava a lungo. Con il nuovo calcolo conta il gruppo di spostamenti ravvicinati peggiore, in finestre di cinque secondi al massimo.

Il 12 marzo 2024 è toccato al FID. Registrava soltanto l’attesa prima che il browser cominciasse a gestire il primo tocco, e ignorava tutto il resto: l’esecuzione del codice, l’aggiornamento dello schermo, ogni tocco successivo. Una pagina pronta al primo gesto e bloccata al terzo superava il controllo.

L’INP, che ha preso il suo posto, segue ogni interazione dall’inizio alla fine. La ragione sta in un dato di Chrome riportato nella documentazione sull’INP: il 90% del tempo che una persona passa su una pagina viene dopo il caricamento.

Il FID sopravvive nelle guide scritte prima del 2024, nei report di strumenti mai aggiornati e spesso nelle risposte dei sistemi di AI, che su questo tema ripropongono ancora l’elenco LCP, FID e CLS. Se trovi un consiglio per migliorare il FID, stai leggendo un’indicazione superata. Se un vecchio report ti mostra un FID buono, non sai ancora nulla di come rispondono le tue pagine.

Le applicazioni a pagina singola, i siti che cambiano contenuto e indirizzo senza ricaricare, sono state a lungo osservate quasi solo al primo ingresso. Da Chrome 151 il browser riconosce questi cambi di vista, le soft navigations, e calcola LCP, INP e CLS per ciascuno. Come entreranno nel giudizio non è stato ancora annunciato.

Come Google giudica i Core Web Vitals del tuo sito

In Search Console, il servizio gratuito con cui Google mostra ai proprietari di un sito come ne vede le pagine, lo stato dei Core Web Vitals si trova nel rapporto Segnali web essenziali, che divide gli indirizzi del sito in gruppi e classifica ciascun gruppo come buono, da migliorare o scadente, con un grafico separato per dispositivi mobili e desktop.

Quella classificazione nasce dai dati di campo, le rilevazioni di Chrome sulle visite reali, che Google riunisce nel Chrome User Experience Report (CrUX), un archivio pubblico che copre milioni di siti.

Nel campione entrano gli utenti di Chrome che hanno attivato l’invio delle statistiche d’uso e la sincronizzazione della cronologia, secondo la metodologia di CrUX. Restano fuori Safari, Firefox, Edge, le app che aprono i link al proprio interno e perfino Chrome su iPhone, che usa il motore di Safari.

Se il tuo pubblico mobile usa soprattutto iPhone, il voto sulla versione mobile lo decidono le visite da Android. Se molti clienti arrivano dall’app di un social, la loro esperienza non entra nel conto.

I dati coprono una finestra mobile di 28 giorni, aggiornata ogni giorno: entrano le visite più recenti, escono le più vecchie. Il rapporto che leggi racconta le ultime quattro settimane, e la modifica pubblicata ieri vi pesa appena.

Per ogni metrica le visite si mettono in fila dalla migliore alla peggiore, e il voto si dà sul 75° percentile, il valore che tre visite su quattro rispettano. Un LCP di 2,4 secondi al 75° percentile vuol dire che tre clienti su quattro hanno visto il contenuto principale entro quel tempo, e il quarto ha aspettato di più.

Con una media, le attese di chi arriva da un telefono economico sparirebbero dietro quelle rapide. Con il percentile pesano, e su molti siti riguardano una quota consistente del pubblico.

Mobile e desktop hanno le stesse soglie ma voti separati, e un sito può passare da computer e fallire da telefono con lo stesso codice. La valutazione si supera solo con LCP, INP e CLS buoni insieme: un caricamento rapido non compensa un pulsante che risponde tardi.

Perché PageSpeed Insights e Search Console danno giudizi diversi

Per la stessa pagina, nello stesso giorno, PageSpeed Insights può assegnare un punteggio di 95 mentre Search Console colloca il suo gruppo fra gli URL scadenti. I giudizi sono entrambi corretti, perché nascono da osservazioni diverse.

In alto, PageSpeed Insights mostra i dati di campo di CrUX, della pagina o del sito intero. Più sotto compare un punteggio da 0 a 100 calcolato da Lighthouse, un test che carica la pagina simulando un telefono di fascia media su rete mobile, sempre alle stesse condizioni.

Quel punteggio appartiene ai dati di laboratorio, prodotti da una visita simulata, ed è il «90» che circola negli screenshot e nei preventivi. Nella valutazione dei Core Web Vitals non entra. Prima di intervenire, conviene capire da dove nasce la distanza fra il punteggio e il giudizio.

Che cosa cambia	Dati di campo (CrUX, Search Console)	Dati di laboratorio (Lighthouse)
Da dove vengono	visite reali di utenti Chrome	una visita simulata
Dispositivo e rete	quelli dei visitatori	telefono di fascia media emulato, rete mobile fissa
Periodo	ultimi 28 giorni	il momento del test
Reattività	INP, su tutta la visita	TBT, solo durante il caricamento
Redirect e connessione	inclusi nell’LCP	saltati, se il test parte dall’indirizzo finale
Perimetro	gruppi di URL, pagina o sito intero	solo l’URL inserito
Dopo una correzione	settimane per aggiornarsi	subito
Entra nella valutazione	sì	no

Il Total Blocking Time (TBT) è il tempo in cui, durante il caricamento, il browser resta impegnato in attività così lunghe da non poter rispondere a un gesto. In laboratorio nessuno tocca niente, quindi l’INP non si può calcolare, e il TBT ne prende il posto come indizio, senza esserne un equivalente.

Per capire quanto il pubblico reale si allontana dal telefono simulato, guarda in Google Analytics la ripartizione delle visite per dispositivo.

Il punteggio di laboratorio oscilla anche fra un’esecuzione e l’altra, per la rete e la macchina che esegue il test: qualche punto in più al secondo tentativo descrive la stessa pagina. Il laboratorio serve ad altro. Ti permette di riprodurre un problema quando vuoi, di vedere quale elemento il browser ha scelto come LCP e quale script lo ha bloccato, di confrontare la pagina prima e dopo una modifica senza aspettare un mese di visite.

Gruppi di URL e dato di origine: quando una pagina eredita il giudizio

Nel rapporto Segnali web essenziali un gruppo riunisce indirizzi con un’esperienza simile, di solito costruiti sullo stesso modello, e prende lo stato della sua metrica peggiore: con un CLS scarso e un INP buono, il gruppo finisce fra gli URL scadenti.

Aprendo un gruppo vedi alcuni URL di esempio. Servono a riconoscere il modello, perché correggere il primo della lista non cambia lo stato di un insieme che può contare centinaia di indirizzi.

Una pagina ha dati propri solo se riceve abbastanza visite di utenti Chrome nei 28 giorni, e la soglia non è dichiarata. Una scheda di nicchia o un articolo appena pubblicato possono restarne sotto. In quel caso PageSpeed Insights mostra il dato dell’origine, cioè del sito intero identificato da protocollo, dominio e porta, e lo segnala sopra i valori di campo: è la prima cosa da controllare.

Il dato dell’origine inganna in entrambe le direzioni. Una scheda lenta risulta buona perché il resto del sito è veloce, e la lasci com’è mentre i suoi visitatori aspettano. Una pagina leggera eredita l’INP scarso di un configuratore che sta altrove, e ti fa cercare un problema che non ha.

Quando il giudizio cambia senza che tu tocchi il sito

Una correzione pubblicata ieri non cambia il rapporto di Search Console domani, perché i dati coprono le ultime quattro settimane di visite. Il gruppo resta fra gli URL scadenti finché le visite alla versione vecchia non escono dal conteggio. Anche un peggioramento compare tardi, spesso settimane dopo che i clienti hanno cominciato ad aspettare.

Il voto si muove anche senza modifiche al codice, quando cambia chi arriva. Una campagna sui social porta visite da telefoni più lenti e da rete mobile, e l’LCP sale.

Anche le risposte generate dall’AI cambiano chi arriva. Quando una ricerca informativa si chiude dentro un AI Overview, il riassunto che Google mostra sopra i risultati, o in un assistente come ChatGPT, sulla pagina che ne viveva arrivano meno persone, con dispositivi e abitudini diverse. Se le visite scendono abbastanza, la pagina perde i dati propri e passa al dato dell’origine. Nessuna misura pubblica dice quanto questo sposti i valori.

Prima di attribuire un cambiamento a un tuo intervento, affianca l’andamento dei Core Web Vitals alla composizione del pubblico in Google Analytics, per dispositivo e per canale. Se le curve si muovono insieme, è cambiato chi arriva.

Il peso dei Core Web Vitals nella Ricerca e nelle risposte AI

Dal giugno 2021 i Core Web Vitals fanno parte dei segnali con cui la Ricerca Google ordina i risultati. Sono entrati con l’aggiornamento page experience, che li ha affiancati ad altri aspetti dell’esperienza di pagina, come HTTPS e la resa su mobile, prima sui dispositivi mobili e dal 2022 anche su desktop. Il ridimensionamento è cominciato quasi subito, ed è stata Google stessa a portarlo avanti, documento dopo documento.

La documentazione sull’esperienza di pagina li conferma fra i segnali usati e ne delimita subito il ruolo. Non esiste un segnale unico dell’esperienza, il contenuto più pertinente viene mostrato anche quando l’esperienza è scadente, e una buona esperienza contribuisce quando i contenuti utili sono molti e si equivalgono.

Se la tua pagina risponde peggio di quelle che le stanno sopra, portare le metriche sotto soglia non le darà la pertinenza che le manca. Se risponde meglio, resta dov’è anche con un’esperienza scadente. I Core Web Vitals lavorano sul margine fra risposte equivalenti.

Per anni la page experience è stata letta come un fattore di ranking autonomo, che sommava Core Web Vitals, HTTPS, resa su mobile e assenza di interstitial invadenti, le finestre che coprono il contenuto all’apertura. Fino all’aprile 2023 compariva anche come sistema a sé nella guida di Google ai sistemi di ranking.

Quando l’ha tolta da quella guida, Google ha chiarito che si trattava di un concetto, un modo per indicare gli aspetti da curare, senza un sistema separato né un punteggio unico. Se qualcuno ti spiega un calo con un «aggiornamento page experience», ti sta indicando un sistema che non esiste.

«Not giant factors in ranking», li ha definiti nell’ottobre 2024 John Mueller, che per Google cura il dialogo con chi gestisce siti e si occupa di SEO, aggiungendo di dubitare che un forte calo possa dipendere solo da loro. Fallire la valutazione non ti esclude dai risultati, superarla non ti garantisce una posizione.

AI Overview e AI Mode, le risposte generate dentro la Ricerca, scelgono le fonti fra le pagine già nell’indice. Il requisito, secondo la documentazione sulle funzioni AI, è che la pagina sia indicizzata e idonea a mostrare uno snippet, senza requisiti tecnici aggiuntivi.

I Core Web Vitals arrivano in quelle risposte per la stessa strada dei risultati classici e con un peso altrettanto limitato. Una pagina pertinente con un LCP scarso può diventare una fonte, una pagina con metriche perfette e una risposta debole resta fuori.

Quando qualcuno clicca la fonte e apre la pagina, l’esperienza torna a contare per intero. La guida all’ottimizzazione per l’AI generativa, aggiornata da Google nel luglio 2026, chiede espressamente una buona esperienza per chi arriva, con latenza ridotta e un contenuto principale riconoscibile. Chi apre la tua pagina da una citazione ti ha già scelto fra le fonti proposte, e un’attesa è il modo più rapido per perderlo.

Capire se sulle tue query l’esperienza può fare la differenza

Il rapporto di Search Console ti dice come vanno le tue pagine e nulla di quelle con cui competi. Per capire se l’esperienza può spostare qualcosa su una query, parti dai risultati: cerca la query e apri le pagine sopra e sotto la tua.

Confronta prima le risposte. Le pagine sopra coprono la domanda per intero? Offrono dati, esempi o passaggi che tu non hai? Sono più aggiornate? Se sì, il divario è di contenuto, e nessun intervento sulle prestazioni lo colma.

Se le risposte si equivalgono, confronta l’esperienza. PageSpeed Insights accetta qualunque indirizzo, anche quello di un concorrente, e ne mostra i dati di campo quando ci sono. In pochi minuti vedi se i risultati vicini offrono su mobile un LCP o un INP migliori.

Concorrenti buoni e pagina tua scarsa, su una query in equilibrio, sono il caso in cui migliorare può pesare anche in classifica. Se sono tutti scarsi, nessuno ne ricava un vantaggio di posizione, ma chi migliora per primo offre un’esperienza migliore a chi clicca.

Un crollo di posizioni in pochi giorni si spiega raramente con i Core Web Vitals, che per via della finestra di 28 giorni cambiano lentamente. Coincide più spesso con un aggiornamento dell’algoritmo, con l’arrivo di un concorrente o con un problema di scansione e indicizzazione.

Che cosa conta della tua pagina quando la legge un sistema AI

I crawler dei sistemi AI, come GPTBot di OpenAI, ClaudeBot di Anthropic e PerplexityBot, chiedono la pagina al server e ne leggono il contenuto senza aprirla davanti a qualcuno: nessuna foto da aspettare, nessun pulsante da toccare, nessuna riga che scivola. Il loro passaggio non produce valori di LCP, INP o CLS, e lo stesso vale per Googlebot quando raccoglie le pagine da cui attingono AI Overview e AI Mode.

Della velocità del sito, i crawler sentono la parte che dipende dal server: tempi di risposta, errori, timeout, catene di redirect. Se il server rallenta o risponde con errori, avverte la documentazione sul crawl budget, Googlebot scansiona meno.

Il Time to First Byte (TTFB), il tempo che il server impiega a inviare il primo byte della pagina, riguarda entrambi i lettori. Nessuna documentazione lo lega alla scelta delle fonti, ma incide sulla scansione, e per chi visita è la prima fase dell’LCP: se il server risponde tardi, tutto il resto parte in ritardo.

Il JavaScript divide invece i crawler fra loro. Un’analisi di Vercel e MERJ sul traffico reale, del dicembre 2024, ha mostrato che i crawler di OpenAI, Anthropic e Perplexity scaricano i file JavaScript senza eseguirli, mentre Gemini, che usa l’infrastruttura di Googlebot, e AppleBot li eseguono. Un testo che compare solo dopo l’esecuzione del codice, per i primi, non esiste.

Le scelte che rendono il contenuto leggibile a quei crawler aiutano anche chi visita. Un’immagine principale e un testo già presenti nell’HTML inviato dal server vengono trovati prima dal browser, e l’LCP si accorcia. Meno JavaScript da eseguire lascia il browser libero di rispondere ai gesti, e l’INP scende.

Se vuoi verificare che cosa arriva ai crawler e quali scelte di rendering lo decidono, il riferimento è la guida alla SEO tecnica. Se vuoi capire perché un passaggio leggibile viene citato oppure no, entri nel campo della SEO for AI.

Su quali pagine conviene lavorarci

Il lavoro sui Core Web Vitals rende dove arrivano persone e dove quello che provano cambia quello che fanno: comprare, chiedere un preventivo, iscriversi, tornare. Su una pagina che nessuno visita, migliorare le metriche sposta un numero e nient’altro.

Parti dalle pagine con visite, perché solo lì esiste un dato di campo da migliorare e un modo per verificare la correzione. Le trovi nel rendimento delle pagine di Search Console e fra le pagine di destinazione di Google Analytics. Nel Progetto SEOZoom, con Search Console collegata, la vista Performance Pagine elenca ogni URL tracciato con clic, impressioni, CTR, posizione media e numero di keyword, e ti mostra in una tabella sola quali indirizzi ricevono persone.

Fra quegli indirizzi ci sono anche le destinazioni di chi clicca una fonte in una risposta generata. In Google Analytics 4 compaiono come referral da chatgpt.com o perplexity.ai, e spesso non coincidono con le pagine che hai curato di più: un vecchio articolo tecnico può ricevere dall’AI più visite della home.

Il tipo di pagina ti indica quale metrica curare per prima. Su un articolo contano l’arrivo del contenuto e la stabilità durante la lettura, quindi LCP e CLS, e fra i responsabili degli spostamenti ci sono spesso annunci ed embed. Su una scheda prodotto, un listino con filtri, un modulo di preventivo o un carrello pesa soprattutto l’INP, perché un filtro che risponde tardi rallenta il cliente proprio mentre sceglie.

Tipo di pagina	Metrica da guardare per prima	Dove nasce spesso il problema
Articolo	LCP, CLS	immagine d’apertura o titolo che arrivano tardi; annunci ed embed che spostano il testo
Scheda prodotto	INP, LCP	scelta di varianti e taglie; galleria fotografica; script delle recensioni
Listino con filtri	INP	filtri che ricalcolano e ridisegnano l’intero elenco
Modulo di preventivo o contatto	INP	controlli sui campi mentre si scrive; script di tracciamento
Carrello e checkout	INP, CLS	aggiornamento dei totali; avvisi e banner che compaiono sopra i pulsanti

Nello stesso intervento in cui ridimensionava il peso dei Core Web Vitals nel ranking, Mueller indicava questo terreno. Se le persone sono così infastidite da non voler tornare, scriveva, «you’re just wasting the first-time visitors to your site, regardless of where they come from».

Alcuni cali chiedono un altro intervento, e riconoscerli ti evita settimane di lavoro inutile. Una pagina che perde posizioni perché risponde peggio delle concorrenti ha bisogno di lavoro sul contenuto. Una pagina che perde clic perché la sua ricerca trova risposta in un AI Overview non li recupera caricandosi più in fretta. Una pagina che arriva quasi vuota ai crawler che non eseguono JavaScript ha un problema di rendering.

Template e gruppi: dove una correzione raggiunge più pagine

Nel rapporto Segnali web essenziali mobile e desktop stanno in due sezioni distinte, e vanno lette entrambe, perché i voti sono separati. Sul mobile, di solito, i gruppi scarsi sono più numerosi e più estesi.

Gli URL di esempio di un gruppo ti dicono quale modello lo compone. Indirizzi con la stessa struttura, come quelli delle schede prodotto o degli articoli del blog, indicano un template, la pagina tipo da cui il sito genera tutte quelle dello stesso genere.

Se un gruppo mescola modelli diversi, apri più esempi e cerca ciò che hanno in comune. Spesso è uno script, un banner o un widget presente ovunque.

Un problema di template si corregge una volta, nel modello, e la correzione arriva a ogni pagina che lo usa. Intervenire indirizzo per indirizzo sposta poco, perché lo stato del gruppo dipende da centinaia di URL.

Fra due template con lo stesso problema viene prima quello che vende o raccoglie contatti. A parità di ruolo, scegli quello con più visite: la correzione raggiunge più persone e produce prima un dato di campo con cui verificarla.

Le landing costruite a mano per una campagna e le pagine con poche visite restano fuori da questa logica, perché non formano gruppi o non hanno dati propri. Su di loro lavori con il laboratorio e con la rilevazione diretta delle visite.

Misurare quanto ti costa un’attesa

CrUX ti dice se superi la valutazione, e nulla su quanto ti costa un LCP di quattro secondi sulla pagina del preventivo. Per saperlo devi rilevare le visite sul tuo sito e metterle accanto a quello che le persone fanno.

La libreria web-vitals, mantenuta dal team di Chrome, pesa circa 3 KB e calcola LCP, INP e CLS come li calcola Chrome, su ogni visita e su ogni pagina, comprese quelle che CrUX non copre. La versione di attribuzione aggiunge dove si è perso il tempo: la fase dell’LCP che ha pesato di più, l’interazione lenta con lo script responsabile, l’elemento che si è spostato.

I dati si inviano a Google Analytics 4 come eventi, legati alla pagina e alla visita. A quel punto puoi confrontare il tasso di conversione delle visite con un LCP o un INP buoni con quello delle visite con valori scarsi, sulla stessa pagina o sulle pagine di un template.

Una differenza netta ti dà una stima di quanto ti costa l’attesa. Una differenza trascurabile ti dice che il tuo tempo rende di più altrove.

Nel confronto va isolato l’effetto del dispositivo. Le visite lente vengono spesso da telefoni economici e reti deboli, e chi li usa può convertire meno per ragioni che con l’attesa non c’entrano. Se confronti visite dallo stesso tipo di dispositivo e le lente convertono ancora meno, stai guardando il costo dell’attesa.

I numeri non coincideranno con quelli di CrUX. Da dicembre 2025 LCP e INP si possono rilevare anche in Safari e Firefox, e la libreria li raccoglie da tutto il pubblico, mentre CrUX continua a contare solo gli utenti di Chrome, come ha confermato web.dev. Il CLS resta limitato ai browser basati su Chromium.

Per le visite da iPhone è l’unico dato che hai. Per confrontarlo con il giudizio di Google, calcola anche tu il 75° percentile.

Come migliorare i Core Web Vitals

Per migliorare i Core Web Vitals parti dai dati di campo, che ti dicono dove l’esperienza cede e su quale metrica, passi al laboratorio, che ti mostra che cosa rallenta la pagina, e torni al campo per sapere se le persone hanno smesso di aspettare. Se parti dal laboratorio, rischi di passare giorni a limare il punteggio di una pagina che per i visitatori è già buona.

La prima domanda da fare ai dati di campo è da quando esiste il problema. CrUX Vis, lo strumento gratuito di Chrome che trasforma i dati di CrUX in grafici, mostra l’andamento settimanale delle ultime 40 settimane, e lo stesso storico si ottiene in forma di dati con la CrUX History API. Una data d’inizio precisa, confrontata con i rilasci, restringe molto la ricerca della causa.

Su un sito costruito con un CMS, gran parte di ciò che il browser deve scaricare ed eseguire dipende dal tema, dai plugin, dai costruttori di pagine e dagli script aggiunti negli anni. Su WordPress come su Shopify, la correzione passa spesso dal sostituire o configurare uno di questi elementi più che dal riscrivere codice.

Hosting e CDN, le reti che distribuiscono i contenuti da server vicini al visitatore, decidono invece il TTFB, da cui parte ogni caricamento. Un server lento rallenta tutte le pagine del sito, qualunque sia il template.

Una parte degli interventi puoi farla da solo: dichiarare le dimensioni delle immagini, togliere il caricamento differito dall’immagine principale, eliminare plugin e script inutili, attivare cache e CDN. Altri richiedono uno sviluppatore, come spezzare le attività lunghe nel codice del tema, spostare la generazione della pagina sul server o riscrivere un componente che ricalcola la disposizione a ogni tocco. Sapere quale metrica cede, e perché, ti dice che cosa chiedere.

Risalire alla causa di una metrica scarsa

Nel rapporto di Search Console ogni problema porta il nome della metrica e della soglia superata, per esempio un LCP oltre 2,5 secondi su mobile. Leggilo per primo, perché LCP, INP e CLS peggiorano per cause diverse e ognuna si cerca in un punto diverso della pagina. La tabella riprende le cause su cui si concentrano le raccomandazioni prioritarie di web.dev.

Metrica	Cause da cercare	Dove guardi
LCP	server lento; immagine principale inserita da uno script; immagine principale in caricamento differito o senza priorità; CSS, font e script che bloccano la visualizzazione	fasi dell’LCP con web-vitals o nel pannello Performance; elemento LCP nella diagnostica di PageSpeed Insights; sorgente HTML
INP	attività lunghe che occupano il browser; JavaScript inutile, compresi tag e script di terze parti; aggiornamenti pesanti su una pagina con moltissimi elementi	interazione lenta e script responsabile con web-vitals; registrazione nel pannello Performance mentre compi il gesto; TBT, solo come indizio
CLS	immagini, iframe ed embed senza dimensioni; banner e annunci inseriti sopra il contenuto; font che cambiano ingombro; animazioni su proprietà di layout; pagine escluse dalla cache avanti/indietro	elemento spostato secondo web-vitals; diagnostica di PageSpeed Insights; registrazione nel pannello Performance, anche scorrendo

Su un LCP scarso devi capire in quale fase si perde il tempo. La guida all’ottimizzazione dell’LCP divide l’attesa fra la risposta del server, il ritardo prima che parta il download dell’immagine principale, il download stesso e l’attesa prima che il browser la disegni. In una pagina ben costruita la risposta del server e il download si prendono circa il 40% ciascuno, e ogni ritardo resta sotto il 10%.

Sui siti con LCP scarso il tempo si perde soprattutto prima del download, che secondo web.dev occupa meno del 10% dell’attesa. Nel 35% dei casi l’immagine principale non compare nemmeno nell’HTML iniziale, perché la inserisce uno script. Solo il 15% delle pagine che potrebbero usare l’attributo fetchpriority lo usa.

Comprimere l’immagine, la prima correzione che viene in mente, spesso serve poco. Rende di più metterla nel sorgente della pagina, darle la precedenza con fetchpriority="high" o con un precaricamento, e toglierle il loading="lazy", che per costruzione la mette in coda. Formato e peso vengono dopo, e li trovi nella guida su come ottimizzare le immagini.

Se invece a occupare l’attesa è la risposta del server, il lavoro va su hosting, cache e CDN: nessun intervento sull’immagine recupera il tempo perso prima che la pagina arrivi.

Su un INP scarso devi prima scoprire quale interazione fa aspettare, e la versione di attribuzione di web-vitals te lo dice insieme alla fase e allo script responsabile. Senza quel dato, parti dai gesti con cui le persone usano il template: aprire il menu, scegliere una variante, applicare un filtro, aggiungere al carrello.

Secondo la guida all’ottimizzazione dell’INP, ogni interazione si scompone in attesa iniziale, esecuzione del codice e disegno della risposta, e ogni fase si corregge in modo diverso. Un’attesa iniziale lunga rivela un browser già occupato, spesso da script di terze parti caricati nel momento sbagliato.

Un’esecuzione lunga chiede di spezzare il codice collegato al gesto e rimandare ciò che non serve a mostrare la risposta. Un disegno lento indica una pagina con troppi elementi, o una disposizione che il browser deve ricalcolare a ogni tocco.

Su un CLS scarso la correzione più efficace è riservare lo spazio prima che il contenuto arrivi. Secondo web.dev il 66% delle pagine ha almeno un’immagine senza dimensioni dichiarate: dichiararle, e riservare nel foglio di stile lo spazio per annunci ed embed, elimina la causa più comune.

I font vanno caricati con un carattere di riserva dalle misure simili, così il testo non cambia ingombro quando arriva quello definitivo. Le animazioni vanno costruite con transform, che sposta un elemento senza spingere gli altri.

La cache avanti/indietro del browser conserva una pagina quando la lasci e la ripristina all’istante quando torni indietro con il pulsante. Una pagina ripristinata così riparte con CLS zero, e la diffusione di questa cache è stata il miglioramento più grande del CLS sul web nel 2022. Molti siti ne restano esclusi per scelte tecniche, come alcuni script o intestazioni di cache, e PageSpeed Insights ti segnala quali.

Riprodurre il problema nel pannello Performance

Il pannello Performance degli strumenti per sviluppatori di Chrome ti fa vedere la causa mentre accade. Scegli fra gli URL di esempio una pagina rappresentativa del template: una scheda con foto, varianti e recensioni come le altre, non quella con la descrizione più corta.

Apri la pagina in Chrome, avvia gli strumenti per sviluppatori con F12 e passa al pannello Performance. Trovi subito i valori di LCP e CLS di quel caricamento e l’INP delle interazioni che compi, e secondo la documentazione di DevTools puoi affiancarli ai dati di campo di CrUX per la stessa pagina.

Sul tuo computer il problema spesso non compare, perché il processore esegue il codice molto più in fretta di quello di un telefono. Prima di registrare, rallenta CPU e rete dalle impostazioni di acquisizione, così la simulazione si avvicina alle condizioni dei visitatori.

Registra un caricamento e osserva nella traccia quando parte la richiesta dell’elemento principale, quanto aspetta prima di comparire, che cosa tiene occupato il browser nel frattempo, quale elemento sposta gli altri.

Per l’INP il gesto lo compi tu. Con la pagina già caricata avvii una registrazione senza ricaricare, fai quello che fanno le persone su quel template e la fermi. Nella traccia trovi ogni interazione con la sua durata e, sotto, il lavoro svolto fra il tocco e l’aggiornamento dello schermo: il codice collegato al gesto, lo script di terze parti che si è messo in mezzo, il ricalcolo della disposizione. Se quel gesto risponde in fretta, passi al successivo.

Verificare le correzioni e intercettare i peggioramenti

Una correzione si prova prima di pubblicarla, in un ambiente di staging, la copia del sito su cui si lavora senza esporla ai visitatori. Lì mancano i dati di campo, ma il laboratorio funziona: stesso template, stesse condizioni, più esecuzioni prima e dopo la modifica. Guarda il valore della metrica che vuoi migliorare più del punteggio complessivo, che oscilla per conto suo.

Dopo il rilascio, apri nel rapporto Segnali web essenziali il problema su cui hai lavorato e avvia la convalida. Search Console osserva le pagine del gruppo per 28 giorni, quanto dura la finestra di CrUX, e il gruppo migliora per gradi, man mano che le visite alla versione nuova prendono il posto di quelle alla vecchia.

Una settimana dopo il rilascio il gruppo può risultare ancora scarso anche se la correzione funziona. Nel frattempo CrUX Vis ti mostra la tendenza settimana per settimana, e web-vitals giorno per giorno.

Un peggioramento arriva nel rapporto con lo stesso ritardo di una correzione. Un aggiornamento del tema, un plugin nuovo o uno script di marketing aggiunto a un template possono rovinare l’esperienza dal primo giorno, mentre il gruppo resta per settimane fra gli URL buoni. Se nel frattempo hai pubblicato altre modifiche, capire quale ha fatto il danno diventa un lavoro a ritroso.

Per accorgerti prima di un peggioramento serve un test di laboratorio ripetuto con regolarità sui template che contano, sempre alle stesse condizioni, con i risultati conservati. Nel Progetto SEOZoom lo fa la sezione Core Web Vitals: rileva con Lighthouse la home e fino a cinque template, su desktop e su mobile, e conserva lo storico dei punteggi, così vedi il giorno in cui un template ha cambiato andamento.

Accanto a ogni rilievo trovi le metriche di laboratorio, dal Largest Contentful Paint al Cumulative Layout Shift, e la reattività attraverso il TBT, perché in laboratorio l’INP non esiste. Ogni valore si legge contro il proprio storico: un salto dopo un rilascio ti dice su quale template e da quale giorno cercare. Lo confermi con qualche esecuzione in PageSpeed Insights e nel pannello Performance, e alla fine ne verifichi l’effetto sulle persone nei dati di campo.

I Core Web Vitals raccontano ciò che succede dopo la scelta: quando qualcuno ha trovato la tua pagina in un risultato di ricerca, in una risposta generata o in un link condiviso, e ha deciso di aprirla. Dicono se l’ha vista comparire in tempo, se ha risposto ai suoi gesti, se è rimasta ferma mentre leggeva.

Quella parte del percorso si svolge sul tuo sito, ed è quella su cui hai il controllo più diretto. Se da quelle visite passano vendite, contatti e iscrizioni, il rapporto dei Core Web Vitals ti indica dove le stai perdendo.