Core Web Vitals per e-commerce: LCP, INP e CLS spiegati

Cosa misurano LCP, INP e CLS, le soglie buone e scadenti al 75° percentile, dati di laboratorio e sul campo, e le correzioni tipiche su Shopify e WooCommerce.

Redazione FixReports14 min di lettura

I Core Web Vitals sono tre metriche di Google che descrivono l’esperienza dei visitatori reali su una pagina: Largest Contentful Paint (LCP) per il caricamento, Interaction to Next Paint (INP) per la reattività e Cumulative Layout Shift (CLS) per la stabilità visiva. Una pagina supera la valutazione quando almeno il 75% delle visite rientra nella fascia «buona»: LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS pari o inferiore a 0,1, misurati separatamente per mobile e desktop. Nei negozi online, i punteggi insufficienti dipendono di solito da immagini hero e di prodotto pesanti o caricate in modalità lazy, da script di app e di tracciamento, dai web font e da banner o widget di recensioni che spingono in basso i contenuti dopo che la pagina è apparsa.

Punti chiave

Quali sono le soglie dei Core Web Vitals?

Una pagina soddisfa i Core Web Vitals quando il 75° percentile dei suoi caricamenti rientra nella fascia buona per tutte e tre le metriche.

MetricaChe cosa misuraBuonoDa migliorareScadente
LCPTempo fino al rendering dell’immagine, del video o del blocco di testo più grande nell’area visibile2,5 s o menoOltre 2,5 s e fino a 4,0 sOltre 4,0 s
INPTempo da un clic, un tocco o la pressione di un tasto fino alla visualizzazione del frame successivo200 ms o menoOltre 200 ms e fino a 500 msOltre 500 ms
CLSQuanto si spostano in modo imprevisto i contenuti visibili0,1 o menoOltre 0,1 e fino a 0,25Oltre 0,25

Le soglie provengono dalle guide di web.dev su LCP (si apre in una nuova scheda), INP (si apre in una nuova scheda) e CLS (si apre in una nuova scheda), aggiornate a ottobre 2026.

Il 75° percentile fa sì che il risultato rispecchi la maggior parte dei visitatori, non solo i più veloci, e Google distingue tra mobile e desktop (si apre in una nuova scheda). PageSpeed Insights promuove una pagina quando tutte e tre le metriche sono buone; se mancano dati sufficienti su INP, valuta solo LCP e CLS (documentazione di PageSpeed Insights (si apre in una nuova scheda)). Google afferma che i Core Web Vitals stabili non cambiano più di una volta all’anno.

In un negozio online, l’elemento LCP è spesso il banner hero o l’immagine principale del prodotto, ed è per questo che la gestione delle immagini conta così tanto.

Perché INP ha sostituito FID a marzo 2024?

INP ha sostituito FID perché FID misurava solo la prima interazione e solo una parte del suo ritardo, mentre INP considera le interazioni di tutta la visita.

A maggio 2023 Google ha annunciato che INP sarebbe diventato un Core Web Vital, e il cambio è entrato in vigore il 12 marzo 2024 (si apre in una nuova scheda). FID riportava solo la prima interazione, e solo il suo ritardo di input, non il tempo impiegato per eseguire i gestori di eventi o per visualizzare il risultato. INP osserva clic, tocchi e pressioni di tasti per tutta la visita e riporta l’interazione più lenta, ignorando i valori anomali; lo scorrimento e il passaggio del mouse non contano. Chi usava le API di CrUX e di PageSpeed Insights ha avuto tempo fino al 9 settembre 2024 per adeguarsi (web.dev (si apre in una nuova scheda)).

Ogni interazione ha tre parti: ritardo di input (l’attesa dovuta a script occupati), durata dell’elaborazione (l’esecuzione dei gestori) e ritardo di presentazione (la visualizzazione del frame successivo) (web.dev (si apre in una nuova scheda)).

In un negozio online, queste interazioni sono il selettore delle varianti, i pulsanti della quantità, l’aggiunta al carrello, il carrello a scomparsa, i filtri e i menu. Una pagina poteva superare FID grazie a un primo tocco veloce e risultare comunque lenta quando qualcuno apriva i filtri più tardi.

Che differenza c’è tra dati di laboratorio e dati sul campo?

I dati di laboratorio provengono da un singolo test in condizioni fisse, mentre i dati sul campo vengono raccolti dai visitatori reali nel tempo, e Google consiglia di usare i dati sul campo per decidere che cosa correggere per primo (web.dev (si apre in una nuova scheda)).

Dati di laboratorioDati sul campo
OrigineUn singolo caricamento di pagina simulato (Lighthouse, Chrome DevTools, la sezione di laboratorio di PageSpeed Insights)Visitatori reali di Chrome (Chrome UX Report), oppure il tuo sistema di monitoraggio degli utenti reali
CondizioniDispositivo e rete fissi. Il test mobile predefinito di Lighthouse (si apre in una nuova scheda) usa «Slow 4G» (150 ms di round trip, 1,6 Mbps in download) e un rallentamento della CPU di 4xQualunque dispositivo, rete e luogo dei tuoi visitatori
INPNon misurato su un semplice caricamento di pagina. Total Blocking Time (TBT) ne è un’approssimazione grossolanaMisurato da interazioni reali
Ideale perFare debugging e verificare una modifica prima del rilascioSapere che cosa ottengono davvero i visitatori

TBT somma la parte di ogni attività del thread principale che supera i 50 ms; web.dev suggerisce di restare sotto i 200 ms su hardware mobile di fascia media, ma precisa che non sostituisce INP (web.dev (si apre in una nuova scheda)).

Tre dettagli del Chrome UX Report (CrUX) contano per i negozi online:

  • È una media mobile di 28 giorni (si apre in una nuova scheda), aggiornata ogni giorno.
  • Copre Chrome su desktop e Android per gli utenti che soddisfano le condizioni di raccolta dati di Chrome. Chrome su iOS è escluso, quindi un negozio con acquirenti in gran parte su iPhone vede dati sul campo relativi solo a una parte del suo pubblico (metodologia (si apre in una nuova scheda)).
  • Pagine e origini compaiono solo se sono individuabili pubblicamente e abbastanza popolari, quindi un negozio con poco traffico può avere solo dati a livello di origine, o nessun dato.

Anche la dashboard delle prestazioni web (si apre in una nuova scheda) di Shopify riporta LCP, INP e CLS degli utenti reali al 75° percentile, ma su 30 giorni anziché 28, quindi aspettati qualche differenza rispetto a CrUX.

Che cosa rallenta l’LCP nelle pagine di un negozio online?

Nei negozi online l’LCP è di solito lento perché l’immagine principale è troppo pesante, viene scoperta tardi o viene ritardata di proposito dal lazy loading o da un’animazione.

  • Lazy loading dell’immagine LCP. web.dev dice di non farlo mai (web.dev (si apre in una nuova scheda)). La sua analisi delle pagine WordPress ha rilevato un LCP al 75° percentile più lento sui siti che usavano il lazy loading nativo, e non applicarlo alle immagini above the fold ha eliminato il peggioramento (web.dev (si apre in una nuova scheda)).
  • Un’immagine trovata tardi. Un’immagine hero impostata come background-image CSS, o inserita da uno script di slider, non è nell’HTML che il browser analizza per primo. Shopify sconsiglia gli sfondi CSS per i contenuti hero e gli effetti di dissolvenza sull’immagine LCP (Shopify (si apre in una nuova scheda)).
  • Priorità bassa. Le immagini si caricano con priorità bassa finché il layout non è completo, quindi Shopify consiglia fetchpriority="high" sull’immagine LCP (Shopify (si apre in una nuova scheda)). web.dev osserva che impostarlo su più di una o due immagini ne riduce l’utilità (web.dev (si apre in una nuova scheda)).
  • CSS e script che bloccano il rendering. Fogli di stile pesanti e script sincroni nell’<head> ritardano il rendering anche dopo l’arrivo dell’immagine (web.dev (si apre in una nuova scheda)).
  • Dimensione dei file e font. Usa formati moderni, srcset e sizes, e una CDN. Per i web font, usa un valore di font-display diverso da auto o block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

Che cosa rende lento l’INP nelle pagine di un negozio online?

Un INP lento nei negozi online significa di solito troppo JavaScript sul thread principale, in gran parte proveniente da app, tag di tracciamento e funzioni del tema, per cui i tocchi devono aspettare.

Se un acquirente tocca «Aggiungi al carrello» mentre gli script di recensioni, chat e analytics sono ancora in esecuzione, il tocco resta in attesa. Un selettore delle varianti che rielabora l’intero modulo del prodotto aggiunge tempo di elaborazione. Mega menu enormi e griglie di collezione con molti campioni colore aggiungono ritardo di presentazione.

web.dev consiglia di spezzare le attività lunghe e cedere il controllo al thread principale, aggiornare prima lo schermo e rimandare il resto, e mantenere il DOM più piccolo (web.dev (si apre in una nuova scheda)). Shopify aggiunge passaggi specifici per i negozi: verificare ogni app, pixel e script del tema, rimandare ciò che non è essenziale, caricare le funzioni al momento dell’interazione e disattivare gli snippet anti-flicker dei test A/B quando non c’è nessun test in corso (Shopify (si apre in una nuova scheda)).

Che cosa causa gli spostamenti del layout nelle pagine prodotto e di collezione?

Nei negozi online gli spostamenti del layout derivano soprattutto da contenuti che compaiono o cambiano dimensione dopo il primo rendering: immagini senza dimensioni, barre di annunci e dei cookie, widget di recensioni, blocchi delle app e sostituzioni dei font.

web.dev indica come cause comuni i contenuti multimediali con dimensioni sconosciute, i contenuti aggiunti sopra quelli esistenti, i widget di terze parti che si ridimensionano da soli e i web font di dimensioni diverse dal font di riserva (web.dev (si apre in una nuova scheda)). Nei negozi online questo significa una barra della spedizione gratuita inserita in alto, valutazioni a stelle che si caricano dopo il titolo, messaggi sul pagamento a rate sotto il prezzo e caroselli di prodotti consigliati. Shopify fa notare che anche i contenuti dei pop-up possono causare spostamenti (Shopify (si apre in una nuova scheda)).

Gli spostamenti che avvengono entro 500 ms da un input dell’utente non contano, ma quelli durante lo scorrimento sì, e gli strumenti di laboratorio spesso non li rilevano (web.dev (si apre in una nuova scheda)). Assegna alle immagini width e height o un aspect-ratio CSS, riserva lo spazio per i widget, mostra i banner in sovrimpressione, riduci gli spostamenti dovuti alla sostituzione dei font con size-adjust e anima con transform anziché con top o left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Come si migliorano i Core Web Vitals su Shopify?

Su Shopify, la maggior parte dei miglioramenti si ottiene caricando subito la prima immagine con priorità alta, riducendo gli script delle app e verificando il risultato nei report sulle prestazioni web del pannello di amministrazione.

Controlla i dati nel pannello di amministrazione

Un riepilogo compare nella pagina Negozio online > Temi (Online Store > Themes), mentre i report completi su LCP, INP e CLS si trovano in Analisi > Report (Analytics > Reports). I dati possono arrivare con un ritardo fino a 36 ore e la modalità privata deve essere disattivata (Shopify Help Center (si apre in una nuova scheda)).

Controlla il caricamento delle immagini in Liquid

Il filtro image_tag applica il lazy loading alle immagini nelle sezioni più in basso nella pagina, a meno che tu non imposti preload (riferimento di image_tag (si apre in una nuova scheda)): caricamento immediato per le sezioni da 1 a 3, lazy dalla sezione 4. Poiché section.index vale nil nell’editor del tema, usa la condizione > 3 anziché <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

Nelle griglie di prodotti, Shopify suggerisce di caricare subito solo le prime schede (per esempio forloop.index <= 4) (Shopify (si apre in una nuova scheda)). Usa preload: true con parsimonia; Shopify consiglia di precaricare solo una o due risorse scoperte tardi.

Elimina ciò che le app lasciano dietro di sé

Disattiva gli incorporamenti di app inutilizzati in Negozio online > Modifica tema > Incorporamenti app (Online Store > Edit theme > App embeds) (Shopify Help Center (si apre in una nuova scheda)). Disinstallare un’app ne rimuove i blocchi, ma le app che hanno modificato direttamente i file del tema possono lasciare «codice fantasma» che, secondo Shopify, può causare problemi di qualità e di prestazioni (Shopify (si apre in una nuova scheda)). Shopify afferma inoltre che i tag script smetteranno di funzionare il 1° marzo 2027. Per i font, Shopify consiglia la propria CDN o i font di sistema anziché servizi di font esterni (Shopify (si apre in una nuova scheda)).

Come si migliorano i Core Web Vitals su WooCommerce?

Su WooCommerce, assicurati che i plugin non sovrascrivano la priorità delle immagini impostata da WordPress, metti in cache tutto tranne carrello e checkout ed elimina gli script che si caricano ovunque senza motivo.

  • Mantieni la gestione delle immagini del core. Da WordPress 6.3 (rilasciato l’8 agosto 2023), il core aggiunge fetchpriority="high" alla probabile immagine LCP (per impostazione predefinita di almeno 50.000 pixel quadrati) e non applica il lazy loading alle prime tre immagini del contenuto (Make WordPress Core (si apre in una nuova scheda)). Se un plugin di ottimizzazione aggiunge un proprio lazy loading, verifica che escluda l’immagine hero e l’immagine principale del prodotto.
  • Metti in cache le pagine, non i carrelli. La guida di WooCommerce consiglia la cache delle pagine lato server o tramite plugin e una CDN, lasciando però fuori dalla cache le pagine del carrello e del checkout (documentazione per sviluppatori di WooCommerce (si apre in una nuova scheda)).
  • Controlla i cart fragments. Da WooCommerce 7.8, lo script dei cart fragments si carica solo dove è presente un widget Carrello, ma alcuni temi inseriscono quel widget direttamente nel codice. Il blocco Mini-Cart non usa i cart fragments (blog per sviluppatori di WooCommerce (si apre in una nuova scheda)).
  • Trova i plugin pesanti. WooCommerce suggerisce Query Monitor per individuare i plugin lenti e consiglia di rimandare il JavaScript non essenziale.

Se il tuo layout mostra più di tre immagini above the fold, puoi alzare la soglia di WordPress:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Quanto tempo serve perché le correzioni si vedano?

I test di laboratorio mostrano subito l’effetto di una correzione, mentre i dati sul campo hanno bisogno fino a circa quattro settimane per rifletterlo del tutto, perché CrUX fa la media dei 28 giorni precedenti.

Esegui il test di laboratorio più volte prima e dopo una modifica, perché i singoli test variano, poi segui i dati sul campo in PageSpeed Insights, nel report Core Web Vitals di Search Console o nei report di Shopify. Una scansione gratuita ti dà una prima lettura in circa un minuto. Il Report Prestazioni esegue un test di laboratorio su mobile con limitazione di rete e CPU (4G lenta, CPU 4x) e aggiunge i dati sul campo del Chrome UX Report, incluso INP quando Google dispone di dati sufficienti sul tuo negozio.

Domande frequenti

I Core Web Vitals influiscono sul posizionamento su Google?

Google afferma che i Core Web Vitals sono usati dai suoi sistemi di ranking, ma che buoni punteggi non garantiscono le prime posizioni e che mostra comunque i contenuti più pertinenti anche quando l’esperienza sulla pagina è scarsa (Google Search Central (si apre in una nuova scheda)).

Perché PageSpeed Insights non mostra dati sul campo per il mio negozio?

CrUX include solo pagine e origini individuabili pubblicamente e con abbastanza visitatori di Chrome idonei. Un negozio con poco traffico può avere solo dati a livello di origine, o nessun dato, quindi affidati ai test di laboratorio e ai report della tua piattaforma.

Serve un punteggio Lighthouse di 90 o più per superare la valutazione?

No. Il punteggio delle prestazioni di Lighthouse è un risultato di laboratorio, mentre la valutazione dei Core Web Vitals usa i dati sul campo al 75° percentile, quindi una pagina può superarla con un punteggio Lighthouse modesto e non superarla con uno alto.

Devo applicare il lazy loading a tutte le immagini dei prodotti?

No. Applica il lazy loading alle immagini sotto la prima schermata, ma carica subito l’immagine hero e l’immagine principale del prodotto, con fetchpriority="high" su una delle due.

Perché i risultati su mobile sono peggiori di quelli su desktop?

Google misura mobile e desktop separatamente, e gli smartphone hanno processori e reti più lenti. Il test mobile di Lighthouse lo simula con un profilo Slow 4G e un rallentamento della CPU di 4x.

Fonti

Tutte le guide