Core Web Vitals sui siti grandi

Le tre metriche e le loro soglie

Le soglie sono fisse e pubblicate da Google: valgono allo stesso modo per ogni sito, e non si negoziano.

Una pagina supera la verifica solo se sta dentro la soglia su tutte e tre.

Come si misurano davvero

Qui si gioca quasi tutto, ed è la parte che le guide italiane saltano quasi sempre. Tre cose cambiano il modo di leggere i numeri.

1. Sono dati di campo, non di laboratorio. I valori che contano arrivano dal Chrome UX Report, cioè dalle sessioni di utenti reali con i loro dispositivi e le loro connessioni. Lighthouse e il punteggio di PageSpeed Insights sono un test simulato: servono a diagnosticare, non a stabilire se una pagina è dentro o fuori soglia.
2. Contano al 75esimo percentile. Non si guarda l’utente medio: si guarda il valore sotto il quale ricade il 75% dei caricamenti. Detta in un altro modo, una pagina è a posto su una metrica quando almeno tre caricamenti su quattro rientrano nella soglia. La valutazione è per gruppo di pagine e per singola metrica, non per sito. È la ragione per cui una media rassicurante può convivere con un quarto degli utenti in difficoltà.
3. La finestra è di 28 giorni, e scorre. Il report Core Web Vitals di Search Console mostra, per ciascuna metrica, il valore al 75esimo percentile delle visite degli ultimi 28 giorni. Una correzione pubblicata oggi entra nei dati un poco per volta, man mano che le vecchie sessioni escono dalla finestra. Chi ricarica il report il giorno dopo non vede niente e pensa che l’intervento non abbia funzionato.

Con quali strumenti si misurano

Gli strumenti non sono intercambiabili: alcuni producono dati di laboratorio, altri dati di campo, e uno li mette affiancati.

• Search Console, report Core Web Vitals. È la fonte che conta: dati di campo, raggruppati per template, separati tra mobile e desktop. Da qui si decide su cosa lavorare.
• PageSpeed Insights. Mostra entrambe le cose sulla stessa schermata: in alto i dati di campo dell’URL, se ce ne sono abbastanza, e sotto il test di laboratorio. Il punteggio su cento è di laboratorio e non è un Core Web Vital.
• Lighthouse e il pannello Prestazioni di Chrome. Servono a capire perché una pagina è lenta: qual è l’elemento LCP e quale risorsa lo determina, quale script tiene occupato il thread principale, quale blocco provoca lo spostamento.
• Chrome UX Report. È il database dietro ai dati di campo. Utile quando servono confronti su più mesi o su domini che non si controllano, per esempio i concorrenti.

La regola pratica: si diagnostica in laboratorio e si verifica sul campo. Chi inverte i due passaggi ottimizza un punteggio simulato senza sapere se gli utenti se ne sono accorti.

Perché la media inganna sui siti grandi

Su un sito con pochi template la media dice quasi tutto. Su un sito con decine di template la media è la somma di comportamenti diversi, e un template che carica male ma riceve poco traffico sparisce dentro l’aggregato.

Search Console lo rende esplicito: gli URL del report non sono elencati uno per uno, ma raccolti in gruppi di pagine con un’esperienza utente simile, e lo stato di LCP, INP e CLS si applica all’intero gruppo. In pratica il report ragiona già per template. Quando i dati di un gruppo non bastano, Google li accorpa in un gruppo a livello di origine, cioè tutti gli URL che condividono protocollo, host e porta: a quel punto il numero che si legge è una media di tutto, e diagnostica poco. Attenzione che sottodomini e versione http contano come origini separate.

La domanda utile quindi non è quanto vale la media del sito. È quali template stanno sotto la soglia e quanto traffico organico ricevono. Sono due liste diverse, e la seconda decide l’ordine del lavoro.

Come si smonta il numero

1. Raggruppa gli URL per template, non per sezione del sito.
2. Leggi il 75esimo percentile, non la media.
3. Separa mobile e desktop prima di trarre conclusioni.
4. Controlla se Search Console ti sta mostrando un gruppo di origine invece di gruppi di pagine: in quel caso i dati sono troppo pochi per quel template.

Cosa muove davvero i numeri

Le tre metriche si rompono per ragioni diverse e si riparano con interventi diversi. Vale la pena prenderle una alla volta.

LCP: quasi sempre una risorsa sola

L’elemento LCP è il blocco di contenuto più grande visibile nell’area visibile, non il più pesante in byte. Di solito è l’immagine principale, il poster di un video, un’immagine di sfondo dichiarata in CSS o il blocco di testo di apertura.

Il motivo per cui il lavoro sull’LCP spesso gira a vuoto è che si ottimizza la parte sbagliata. Google scompone l’LCP in quattro sottoparti, con una distribuzione ideale:

Le due sottoparti che dovrebbero stare sotto il 10% sono quelle che nella pratica esplodono. Il ritardo del caricamento è il tempo tra l’arrivo del primo byte dell’HTML e il momento in cui il browser comincia davvero a scaricare quella risorsa: di solito perché la scopre tardi, quando l’immagine principale è dichiarata dentro un CSS, caricata da uno script o nascosta in un carosello, a volte perché le assegna una priorità bassa. Il ritardo di rendering è il tempo in cui la risorsa è già arrivata ma non viene disegnata, tipicamente perché un font o uno script la stanno bloccando.

Tre correzioni coprono la maggior parte dei casi:

1. Dichiara la priorità dell’immagine principale con fetchpriority="high", e aggiungi un preload quando la risorsa non è individuabile subito nell’HTML.
2. Non mettere mai loading="lazy" sull’elemento LCP. È l’errore più frequente quando il lazy loading viene applicato a tutte le immagini del template.
3. Riduci il TTFB con cache lato server e una risposta rapida, perché è una delle due sottoparti più pesanti ed è l’unica che ricade su tutte le pagine insieme.

CLS: spazio non riservato

Lo spostamento del layout ha una causa ancora più concentrata: qualcosa occupa spazio dopo che la pagina è già stata disegnata, e spinge giù tutto quello che sta sotto. Le cause che Google elenca sono sempre le stesse:

• immagini e video senza dimensioni dichiarate;
• font che al caricamento vengono resi in dimensioni diverse dal ripiego iniziale;
• annunci, widget o iframe di terze parti che si ridimensionano da soli;
• elementi inseriti nel DOM al di sopra di contenuti già presenti;
• animazioni costruite su proprietà che ricalcolano il layout invece che su transform.

Il CLS non somma tutti gli spostamenti della pagina: prende la finestra di sessione peggiore, cioè il gruppo di spostamenti ravvicinati con il punteggio più alto. Una finestra si chiude dopo un secondo senza spostamenti, o comunque dopo cinque secondi. Per questo un singolo banner che entra tardi può da solo determinare il valore della pagina.

La correzione è sempre la stessa: riservare lo spazio prima. Dimensioni dichiarate su immagini e iframe, un contenitore di altezza fissa per i blocchi inseriti dopo, e una strategia di ripiego per i font che non cambi le dimensioni del testo.

INP: il thread principale occupato

Qui va corretto un equivoco diffuso, che nelle guide italiane sopravvive ancora. L’INP non misura la prima interazione. Quella era la metrica precedente, il FID, sostituita da INP nel marzo 2024. L’INP osserva tutti i clic, i tocchi e le interazioni da tastiera di una visita, e riporta l’interazione più lenta, scartando i valori anomali.

È una misura più severa e più onesta: una pagina che risponde bene al primo clic e male a tutti quelli dopo, con il FID passava e con l’INP no.

Ogni interazione si divide in tre fasi: il ritardo di input, cioè l’attesa prima che il browser cominci a elaborare; la durata dell’elaborazione del codice associato all’evento; il ritardo di presentazione, cioè il tempo per disegnare il fotogramma successivo. La causa dominante di un INP alto sono le attività lunghe nel thread principale, che tengono il browser occupato mentre l’utente sta già cliccando.

Sui siti grandi il colpevole è quasi sempre lo stesso: script di terze parti, tag manager carichi e JavaScript del template eseguito tutto insieme all’avvio.

Come si lavora per template

Il vantaggio di un sito grande è che una correzione su un template vale per tutte le pagine che lo usano. Una correzione sul template che porta gran parte del traffico organico muove l’aggregato più di dieci correzioni su singole pagine.

Per questo la sequenza è sempre la stessa:

1. Ordina i template per traffico organico, non per gravità del problema. Un template disastroso con cento visite al mese aspetta.
2. Individua la sottoparte che domina, prima di toccare il codice. Su LCP significa sapere se il tempo sta nel TTFB o nel ritardo di rendering: sono due lavori diversi.
3. Correggi il template, non le pagine che lo usano.
4. Verifica in laboratorio subito, per sapere se la correzione ha avuto effetto sulla singola pagina.
5. Aspetta i dati di campo prima di dichiarare chiuso il lavoro. In Search Console si avvia il monitoraggio e la verifica dura 28 giorni: se in quel periodo il problema non ricompare su nessun URL del gruppo, è considerato risolto.

I due passaggi finali sono distinti apposta. Il test di laboratorio dice se hai fatto bene il lavoro, i dati di campo dicono se è servito agli utenti. Solo il secondo conta per Google.

Quanto pesano davvero sul ranking

Vale la pena essere precisi, perché su questo punto quasi tutte le guide italiane esagerano in un senso o nell’altro. Google colloca i Core Web Vitals dentro l’esperienza sulla pagina, li descrive come allineati a ciò che i sistemi di ranking principali premiano e raccomanda ai proprietari dei siti di avere buoni valori. Ma chiarisce anche due cose: non esiste un singolo indicatore di esperienza sulla pagina, e la Ricerca mostra comunque i contenuti più pertinenti anche quando l’esperienza è di qualità scadente. Tradotto: non compensano una minore pertinenza. Una pagina lenta ma molto più pertinente continua a posizionarsi sopra una veloce e generica.

Dove incidono davvero è a parità di tutto il resto, e sul comportamento delle persone una volta arrivate. Su un e-commerce o un portale questo si vede prima nelle conversioni che nelle posizioni.

Core Web Vitals e motori di risposta AI

Il legame con la visibilità nei motori di risposta è indiretto ma reale, e passa per due strade.

La prima è la scansione. Le metriche di campo non vengono lette dai crawler, ma le stesse cause che le peggiorano rallentano la scansione: un server lento riduce il ritmo con cui Google scarica le pagine, e contenuti che compaiono solo dopo l’esecuzione del JavaScript possono non essere visti affatto dai crawler dei sistemi AI, che in molti casi non eseguono JavaScript.

La seconda è la struttura. Portare contenuti e link principali già nell’HTML iniziale è la stessa correzione che migliora LCP e INP e che rende la pagina leggibile a chi la recupera per citarla. Il lavoro sulle prestazioni e il lavoro sulla citabilità si sovrappongono più di quanto sembri.

Domande frequenti