Quanto costano i Core Web Vitals in termini di fatturato

I Core Web Vitals vengono solitamente discussi come argomento prettamente SEO. Questa prospettiva ne sminuisce la vera portata: come segnale di ranking sono oggettivamente secondari — Google stesso lo ha confermato più volte, e una pagina lenta con la risposta migliore supererà sempre una pagina veloce con contenuti peggiori.

Il vero motivo per cui occuparsene è il tasso di conversione. Un utente che abbandona il sito prima ancora che la pagina sia renderizzata converte esattamente a zero, e nessun posizionamento nei risultati di ricerca può rimediare a questo.

Ecco cosa misurano realmente i tre parametri, quali sono le cause effettive dei punteggi scadenti e cosa ottimizzare per primo.

Le tre metriche fondamentali

Largest Contentful Paint (LCP)

Il momento in cui l'elemento visibile più esteso della pagina completa il rendering. Solitamente è l'immagine principale (hero image), il titolo H1 o un blocco di testo rilevante.

Buono: sotto i 2,5 secondi
Da migliorare: 2,5–4,0 secondi
Scarso: oltre i 4,0 secondi

L'LCP è l'indicatore più fedele di "quando la pagina è diventata realmente utile per l'utente". È la prima metrica da ottimizzare.

Cumulative Layout Shift (CLS)

L'entità dello spostamento visivo degli elementi durante il caricamento. È un'esperienza comune: state per cliccare un link, si carica un banner pubblicitario sopra di esso, il layout si sposta all'improvviso e finite per cliccare un elemento diverso.

Buono: inferiore a 0,1
Scarso: superiore a 0,25

Il CLS è di norma il più economico e rapido da correggere dei tre, poiché le cause scatenanti sono poche e ben documentate.

Interaction to Next Paint (INP)

Il tempo impiegato dalla pagina per rispondere visivamente a un'interazione dell'utente. Ha sostituito la metrica First Input Delay (FID) nel marzo 2024 ed è molto più severa: misura ciascuna interazione avvenuta durante l'intera visita, non solo la prima.

Buono: sotto i 200ms
Scarso: oltre i 500ms

L'INP è quasi sempre riconducibile a problemi di JavaScript: il main thread del browser è sovraccarico e non riesce a ridisegnare l'interfaccia.

Dati di laboratorio contro dati di campo

Questa distinzione genera spesso grande confusione, per cui è opportuno fare chiarezza con precisione tecnica.

I dati di laboratorio (Lab Data) derivano da un caricamento simulato in un ambiente controllato — esattamente ciò che restituisce lo strumento Lighthouse negli strumenti per sviluppatori di Chrome. Sono riproducibili e utilissimi per il debug, ma non sono ciò che Google impiega per determinare il posizionamento.

I dati di campo (Field Data) provengono dal Chrome User Experience Report (CrUX): misurazioni effettive registrate da utenti reali di Chrome su una finestra mobile di 28 giorni. Questo è ciò che Google valuta concretamente ed è il dato riportato all'interno di Google Search Console.

I due valori divergono frequentemente, e quando accade, i dati di campo rappresentano l'unica verità. Un sito web può totalizzare un punteggio di 95 su Lighthouse sulla potente workstation di uno sviluppatore e fallire miseramente nei dati di campo perché la maggior parte degli utenti reali naviga da smartphone Android di fascia media su reti mobili congestionate.

Regola pratica: ottimizzate sui dati di campo reali, fate debug con i dati di laboratorio. E tenete a mente che i dati di campo hanno una latenza fisiologica: una correzione tecnica può impiegare fino a 28 giorni prima di riflettersi pienamente nei grafici.

Il nostro strumento gratuito di audit SEO analizza entrambi i dati, interrogando direttamente le API di Google PageSpeed Insights, permettendovi di individuare subito dove divergono per il vostro dominio.

Cosa causa realmente un LCP negativo

In ordine approssimativo di frequenza con cui si manifesta il problema:

Immagini pesanti e non ottimizzate

Nella maggioranza delle pagine l'elemento LCP è un'immagine, e quasi sempre è immensamente più pesante del necessario.

L'errore tipico è costante: un file JPEG da 700 KB largo 3000px, visualizzato a 640px, caricato senza priorità e privo di formati moderni di compressione.

La soluzione strutturale:

<picture>
  <source srcset="/hero-640.avif 640w, /hero-1280.avif 1280w" type="image/avif" />
  <source srcset="/hero-640.webp 640w, /hero-1280.webp 1280w" type="image/webp" />
  <img src="/hero-640.jpg" alt="…"
       width="640" height="480"
       fetchpriority="high" decoding="async" />
</picture>

In questo frammento di codice intervengono quattro ottimizzazioni cruciali. I formati AVIF e WebP abbattono le dimensioni del file dal 50% all'80% rispetto al JPEG a parità di resa visiva. L'attributo srcset invia ai dispositivi mobili un file dimensionato per schermi piccoli. Gli attributi width e height riservano lo spazio nel layout, correggendo contemporaneamente il CLS. Infine, fetchpriority="high" istruisce il browser affinché dia la precedenza assoluta a questa immagine rispetto a qualsiasi altra risorsa di rete in coda.

Quest'ultimo attributo rappresenta frequentemente la modifica a più alto ritorno economico su una pagina web, e l'implementazione è a costo zero.

Non applicate mai loading="lazy" sull'immagine associata all'LCP. Il caricamento pigro differisce il recupero della risorsa, che è l'esatto opposto di ciò che serve per l'elemento cardine su cui venite valutati. Applicate il lazy-load a tutto ciò che si trova al di sotto della piega di pagina (below the fold); caricate in modo immediato (eager) l'immagine hero.

Risorse che bloccano il rendering (Render-blocking)

Ogni foglio di stile CSS inserito nell'head del documento blocca il rendering visivo fino al completamento di download e parsing. Lo stesso vale per qualsiasi script JavaScript sincrono.

L'errore classico è la catena sequenziale di richieste:

/* all'interno di styles.css — genera una catena di blocco */
@import url('https://fonts.googleapis.com/css2?family=…');

Il browser deve prima scaricare styles.css, analizzarlo, scoprire la direttiva import, scaricare il CSS dei font, elaborarlo e solo a quel punto scaricare i file dei caratteri tipografici. Quattro passaggi di rete sequenziali prima che sia possibile visualizzare una singola riga di testo.

Inserite il foglio di stile dei font direttamente nell'head HTML, anticipato dalle direttive preconnect:

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=…&display=swap" />

Il parametro display=swap è essenziale: renderizza immediatamente il testo con un font di riserva di sistema anziché lasciare uno spazio vuoto invisibile durante il download del webfont.

Tempo di risposta del server (TTFB)

Se il Time To First Byte supera i 600ms, nessun accorgimento a valle potrà rendere veloce la pagina. Le cause sono note e rimediabili: assenza di caching, hosting sottodimensionato, query di database lente a ogni caricamento o una CDN non posizionata correttamente davanti all'origine.

Per un sito promozionale la risposta risiede quasi sempre nella generazione statica (SSG). Se la pagina non varia per ciascun singolo visitatore, deve essere un file statico salvato su disco, non una vista assemblata dinamicamente a ogni richiesta.

Eccesso di codice JavaScript

Un framework moderno che invia 400 KB di bundle JavaScript per renderizzare una semplice pagina di testo comporta costi altissimi senza apportare alcun beneficio reale. Su uno smartphone di fascia media, il parsing e l'esecuzione di una simile mole di codice possono richiedere oltre un secondo prima che appaia qualsiasi elemento.

Questa non è una critica ai framework in sé: è una critica all'impiego di framework interamente renderizzati lato client per contenuti che potrebbero essere erogati come puro codice HTML statico.

Cosa causa realmente un CLS negativo

Tre problemi coprono la quasi totalità delle casistiche:

Immagini senza dimensioni esplicite. In assenza degli attributi width e height, il browser non può calcolare lo spazio necessario, provocando un salto brusco di tutti i contenuti sottostanti non appena l'immagine viene scaricata. Impostate sempre entrambi gli attributi, gestendo la reattività con height: auto nel CSS.

Sostituzione repentina dei webfont (FOUT/FOIT). Il browser renderizza il font di fallback, quindi scarica il font definitivo con metriche dimensionali differenti, provocando il ricalcolo dell'intero testo. Mitigate il fenomeno con font-display: swap combinato con size-adjust nelle regole @font-face, oppure selezionate font di fallback con proporzioni sovrapponibili.

Elementi dinamici inseriti sopra i contenuti esistenti. Banner cookie, barre promozionali in testata, annunci pubblicitari, widget incorporati lenti. Qualsiasi elemento inserito a posteriori in cima al documento fa scivolare verso il basso il resto della pagina. Riservate preventivamente lo spazio occupato, oppure posizionateli come overlay assoluto fuori dal flusso principale.

Cosa causa realmente un INP negativo

L'INP deriva dalla saturazione del thread principale (main thread) del browser. Le cause più diffuse includono:

Long Tasks — qualsiasi singola operazione JavaScript superiore a 50ms blocca la reattività ai comandi dell'utente
Event listener complessi — elaborazioni pesanti eseguite direttamente nei gestori degli eventi click o input
Script di terze parti — tracker analitici, widget di chat, mappe di calore e script di A/B test competono ferocemente sul thread principale
Rirenderizzazioni superflue — framework che ricalcolano l'intero albero dei componenti a ogni singola battuta sulla tastiera

Le soluzioni, in ordine di efficacia:

Audit degli script di terze parti. La maggior parte dei siti carica tag dimenticati da anni. Eliminate ciò che non porta un valore economico misurabile, e caricate il resto con attributo defer o solo a seguito di una prima interazione dell'utente.
Spezzare le attività prolungate. Cedete il controllo al thread principale con scheduler.yield() ove disponibile, oppure tramite setTimeout(…, 0).
Debounce sui gestori di eventi gravosi. Specialmente in corrispondenza degli eventi input e scroll.
Spostare i calcoli complessi su un Web Worker.

Cosa correggere per primo

Avendo risorse e tempo limitati, procedete in questo ordine:

Comprimere e dimensionare l'immagine LCP, aggiungendo fetchpriority="high". Spesso è il singolo intervento di maggiore impatto e richiede solo un'ora di lavoro.
Aggiungere width e height a ogni immagine. Risolve la maggioranza dei problemi di CLS in modo banale.
Eliminare le catene di @import bloccanti nei CSS. Spostate i font nell'head HTML con le intestazioni preconnect.
Rimuovere gli script di terze parti inutilizzati. Migliora contemporaneamente sia l'INP che l'LCP.
Applicare il lazy-loading sulle immagini below-the-fold. Senza toccare l'immagine principale.
Ottimizzare il TTFB se supera i 600ms. Richiede un intervento strutturale sull'infrastruttura, ma senza di esso nessun'altra ottimizzazione sarà sufficiente.

Una precisazione onesta sui punteggi

Inseguire a tutti i costi un punteggio perfetto di 100 su Lighthouse è solitamente uno spreco di risorse aziendali. La differenza tra un punteggio di 85 e 100 raramente modifica il comportamento dell'utente; la differenza tra 35 e 75 lo trasforma radicalmente.

Raggiungete la soglia "Buono" sui dati di campo per tutte e tre le metriche, quindi fermatevi e concentratevi sull'ottimizzazione del funnel di conversione. La velocità è uno strumento per incrementare il fatturato, non un fine a sé stante: una pagina velocissima con un'offerta scadente continuerà a non vendere nulla.

Scegliete la vostra lingua