Quando si parla di performance di un sito, la conversazione tende a ridursi a un numero: il punteggio di PageSpeed Insights. Quel numero può essere utile, ma non è il prodotto che un’azienda offre alle persone. Il prodotto è l’esperienza di arrivare a una pagina, capire la promessa, interagire senza attese e completare il passo successivo senza sorprese.
I Core Web Vitals aiutano a rendere osservabili tre momenti di quell’esperienza: quando compare il contenuto principale, quanto rapidamente la pagina reagisce a un’azione e se gli elementi restano stabili mentre si caricano. Per me sono quindi più interessanti come strumento di qualità del marketing che come esercizio di ottimizzazione tecnica isolata.
Il punteggio non è il prodotto
Google descrive i Core Web Vitals come metriche basate sull’esperienza reale delle persone e dedicate a caricamento, interattività e stabilità visiva. Le soglie di riferimento sono LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS pari o inferiore a 0,1, osservate al 75° percentile. Sono obiettivi utili perché trasformano una sensazione generica — “il sito sembra lento” — in un problema che posso indagare.
Non li trasformerei però in un voto assoluto. Google chiarisce che non esiste un unico segnale di page experience e che un buon risultato nei report non garantisce da solo una posizione migliore nella Ricerca. Un contenuto pertinente e affidabile resta la base: la performance serve a non renderne più difficile la fruizione.
Tre metriche, tre attriti che il marketing può riconoscere
LCP: arrivare al contenuto che sostiene la promessa
Il Largest Contentful Paint misura il momento in cui viene visualizzato l’elemento più grande rilevante nell’area visibile, spesso un’immagine, un titolo o un blocco di testo. In una pagina di servizio dovrebbe aiutare a capire subito di che cosa si parla. Se arriva tardi, la persona non sta soltanto aspettando un file: sta aspettando di capire se è nel posto giusto.
Prima di comprimere tutto indiscriminatamente, guarderei quale elemento è davvero l’LCP e da che cosa dipende. Un’immagine hero troppo pesante, un server lento, un foglio di stile bloccante o una catena di redirect richiedono correzioni diverse.
INP: rispondere all’intenzione della persona
Interaction to Next Paint osserva la reattività delle interazioni durante la visita: clic, tocchi e pressioni di tasti. Una pagina può apparire pronta e poi non rispondere quando qualcuno apre un menu, compila un modulo o sceglie un’opzione.
Questo è un punto direttamente commerciale. Se il pulsante per richiedere informazioni sembra inattivo, l’intenzione si raffredda. La guida di web.dev suggerisce di partire dai dati sul campo e di usare il laboratorio per diagnosticare JavaScript, attività lunghe e rendering: l’ottimizzazione resta collegata al gesto che la persona stava provando a compiere.
CLS: non spostare la promessa mentre viene letta
Cumulative Layout Shift misura quanto il contenuto visibile cambia posizione in modo inatteso. Un’immagine senza dimensioni, un banner che compare sopra il testo, un font che modifica l’altezza delle righe o un embed senza spazio riservato possono spostare un titolo proprio mentre qualcuno sta per leggerlo o un pulsante mentre sta per toccarlo.
La soluzione spesso è poco spettacolare, ma decisiva: dichiarare le dimensioni delle immagini e dei video, riservare lo spazio per i contenuti che arrivano dopo e non inserire elementi nuovi nel flusso senza una ragione visibile. Così diminuiscono il lavoro necessario per ritrovare il punto della pagina e il rischio di un clic involontario.
Prima i dati reali, poi il laboratorio
PageSpeed Insights combina dati di campo e dati di laboratorio. I primi, alimentati dal Chrome User Experience Report, sintetizzano esperienze reali su un periodo mobile di 28 giorni; i secondi usano Lighthouse in un ambiente simulato. È normale che i valori non coincidano. Il laboratorio è prezioso per capire che cosa correggere, mentre il campo mostra che cosa accade davvero su dispositivi, reti e percorsi diversi.
Per questo non userei una singola esecuzione come diagnosi definitiva. Se il report non mostra dati per una pagina recente o poco visitata, può passare a una granularità di origine; non significa che quella URL abbia già dimostrato di essere veloce. Se il laboratorio è verde ma arrivano segnalazioni di lentezza, cercherei le condizioni non riprodotte dal test. La domanda è: quale esperienza devo rendere migliore, per quale pubblico e in quale momento del percorso?
Leggere la performance dentro il percorso di conversione
Un blog, una landing page e un modulo di contatto non hanno lo stesso compito. Su un articolo informativo, il primo elemento da proteggere può essere il testo che permette di orientarsi. Su una pagina di servizio, conteranno anche la visibilità e la reattività del percorso verso la richiesta. In un e-commerce, attenzione e stabilità diventano essenziali quando la persona confronta varianti, aggiorna il carrello o procede al pagamento.
Prima di aprire un ticket tecnico, mapperei quindi tre cose: la pagina d’ingresso, l’azione che esprime interesse e il punto in cui si produce valore. Poi collegherei i Core Web Vitals a segnali di comportamento proporzionati: completamento del modulo, errori, abbandono, tempo per arrivare alla conferma, richieste di assistenza. Non per sostenere che una metrica causi da sola una conversione, ma per capire dove un attrito tecnico coincide con un passaggio importante.
Le prime correzioni che cercherei
In molti progetti partirei da quattro controlli concreti:
- Quale risorsa determina l’LCP e può essere resa più piccola, anticipata o servita dal formato corretto?
- Quale interazione ha l’INP peggiore e quale script o attività lunga ritarda la risposta?
- Quale elemento provoca gli spostamenti di layout e quanto spazio posso riservargli prima del caricamento?
- La correzione migliora anche il percorso principale su mobile, oppure alza soltanto un punteggio in laboratorio?
Le immagini meritano un controllo specifico. Servire a un telefono un file pensato per uno schermo desktop può richiedere da due a quattro volte più dati del necessario, secondo web.dev. Attributi srcset e sizes aiutano il browser a scegliere una risorsa adatta; dimensioni esplicite o aspect-ratio evitano salti di layout.
Una routine di misurazione sostenibile
Non trasformerei la performance in un controllo quotidiano ossessivo, ma in una routine collegata ai cambiamenti del sito. Prima di pubblicare una nuova pagina, verificherei il percorso principale su mobile. Dopo un plugin, uno script, un banner o una nuova galleria, confronterei i dati prima e dopo. Ogni mese guarderei Search Console e PageSpeed Insights per capire se il problema riguarda una pagina, un modello o l’intero sito.
Registrerei anche la decisione, non soltanto il valore: “abbiamo ridotto l’immagine principale perché rallentava la lettura della pagina di servizio” è più utile di “LCP migliorato di 0,4 secondi”. Se il risultato commerciale non cambia, non è una prova che il lavoro fosse inutile; può significare che il collo di bottiglia era altrove. La performance è una condizione di qualità, non una promessa automatica di conversione.
La regola che seguo
I Core Web Vitals funzionano quando mi aiutano a vedere la pagina dal punto di vista di chi la usa. LCP mi chiede se la promessa arriva in tempo. INP mi chiede se la pagina risponde all’intenzione. CLS mi chiede se posso leggere e agire senza inseguire elementi che si spostano. Il punteggio è soltanto il modo più rapido per aprire queste domande.
Io partirei da un percorso reale, da un pubblico e da un’azione precisa. Misurerei il campo, userei il laboratorio per capire le cause e correggerei prima ciò che ostacola la comprensione o la fiducia. Se vuoi confrontarti su una pagina che sembra lenta o fragile, puoi contattarmi: per me la performance non è una gara al verde, ma il lavoro silenzioso che permette a un contenuto di fare bene il proprio mestiere.
Fonti e riferimenti
- Google Search Central, Understanding Core Web Vitals and Google search results, definizioni e soglie di riferimento.
- Google Search Central, Understanding page experience in Google Search results, rapporto tra Core Web Vitals, esperienza complessiva e ranking.
- Google for Developers, About PageSpeed Insights, differenza tra dati di campo, laboratorio e 75° percentile.
- web.dev, Optimize Interaction to Next Paint, diagnosi della reattività e uso dei dati sul campo.
- web.dev, Optimize Cumulative Layout Shift e Serve responsive images, cause comuni dei layout shift e immagini responsive.
Nota di trasparenza: questo articolo è stato elaborato con l'aiuto dell'intelligenza artificiale e con supervisione e responsabilità editoriale umana.