Core Web Vitals su scheda prodotto: ridurre LCP

Core Web Vitals su una scheda prodotto: ridurre LCP senza sacrificare le immagini

Dal 2021, Google usa i Core Web Vitals come segnale di ranking. Nel 2026, il loro peso è continuato ad aumentare, e le schede prodotto ne sono il campo principale: immagini ad alta risoluzione, slider, pulsanti di aggiunta al carrello, recensioni dinamiche — tutto ciò che degrada le performance.

Ecco come ottimizzare le 3 metriche che contano (LCP, CLS, INP) su una scheda prodotto senza perdere qualità visiva né UX.

I 3 Core Web Vitals nel 2026

LCP (Largest Contentful Paint) — il tempo necessario perché l'elemento visibile più grande (tipicamente l'immagine prodotto principale) venga mostrato. Obiettivo: <2,5 s.

CLS (Cumulative Layout Shift) — la stabilità visiva: gli elementi non devono spostarsi durante il caricamento. Obiettivo: <0,1.

INP (Interaction to Next Paint) — da marzo 2024, INP sostituisce FID. Misura il ritardo tra un clic dell'utente (aggiunta al carrello, apertura di un menu) e la risposta visiva. Obiettivo: <200 ms.

Una scheda prodotto che supera tutte e 3 le soglie in verde ha un vantaggio di ranking rispetto a quelle che non ci riescono. Lo scarto può rappresentare 3-5 posizioni di differenza su una keyword competitiva.

LCP sull'immagine hero: il lavoro principale

Sul 90% delle schede prodotto, il LCP è l'immagine hero (la prima immagine del prodotto). Il suo peso e il suo tempo di caricamento determinano tutto.

Formato immagine

WebP: 25-35% più leggero di JPEG, supportato ovunque nel 2026. Lo standard.
AVIF: 40-50% più leggero di JPEG, qualità migliore. Supportato da Chrome/Firefox/Safari dal 2022. Da preferire quando possibile.
JPEG: fallback solo per browser molto vecchi (<1% del traffico nel 2026).

Servi il formato corretto in base al browser tramite <picture>:

<picture>
  <source srcset="/product.avif" type="image/avif" />
  <source srcset="/product.webp" type="image/webp" />
  <img src="/product.jpg" alt="..." />
</picture>

Dimensioni e densità

Un'immagine hero visualizzata a 600×600 pixel sullo schermo non deve pesare 4000×4000 pixel. Servi l'immagine alla dimensione corretta + versione 2x per schermi retina:

<img
  src="/product-600.webp"
  srcset="/product-600.webp 1x, /product-1200.webp 2x"
  width="600"
  height="600"
  alt="..."
/>

Su Shopify, la sintassi Liquid img_url: '600x600' gestisce questo automaticamente. Su WooCommerce tramite WP Fastest Image Optimizer o Smush.

Lazy-loading intelligente

Non applicare il lazy-load all'immagine hero (la prima immagine visibile): deve caricarsi subito. Aggiungi fetchpriority="high":

<img
  src="/product-hero.webp"
  fetchpriority="high"
  loading="eager"
  alt="..."
/>

Applica il lazy-load a tutto il resto (immagini secondarie, recensioni con foto, prodotti simili in fondo alla pagina):

<img
  src="/product-thumbnail.webp"
  loading="lazy"
  alt="..."
/>

CDN e cache

Tutte le immagini prodotto devono passare da un CDN (Cloudflare, Fastly, Bunny). Guadagno tipico su LCP: 30-50% in Europa, 50-70% fuori dall'Europa.

Shopify include il proprio CDN (Fastly). WooCommerce richiede una configurazione esplicita.

CLS: cause e correzioni

Il CLS su una scheda prodotto deriva principalmente da:

Immagini senza dimensioni

<!-- ❌ Causa CLS -->
<img src="/product.webp" alt="..." />

<!-- ✅ Riserva lo spazio -->
<img src="/product.webp" width="600" height="600" alt="..." />

Anche su un'immagine responsive (CSS che sovrascrive width/height), specifica gli attributi HTML — servono come hint per riservare lo spazio prima del caricamento.

Un banner "Spedizione gratuita da 50 €" che compare 500 ms dopo il load e spinge tutto il contenuto verso il basso = CLS catastrofico.

Soluzione: riserva lo spazio nell'HTML iniziale con min-height, poi riempi il contenuto in seguito.

Font web che cambiano la dimensione del testo

Se carichi un font custom, arriva con un ritardo. Nel frattempo, il testo viene mostrato con un font di fallback con metriche diverse. Quando arriva il font finale, tutto si sposta.

Soluzione: font-display: optional oppure font-display: swap con size-adjust coerente:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%; /* Match fallback metrics */
}

Carosello / slider di immagini prodotto

Gli slider sono una causa frequente di CLS se implementati male. Regole:

Fissare l'altezza del contenitore dello slider (height: 600px per esempio)
Nessuna paginazione JS che cambi l'altezza al clic
Le thumbnail hanno le loro dimensioni specificate

INP: l'aggiunta al carrello e altre interazioni critiche

INP misura il peggior ritardo di risposta alle interazioni dell'utente. Su una scheda prodotto, le interazioni chiave sono:

Clic su "Aggiungi al carrello"
Cambio variante (taglia, colore)
Apertura di un menu burger
Scroll su un carosello

Cause tipiche di INP elevato:

JavaScript bloccante

Le librerie di terze parti (Facebook Pixel, Google Tag Manager, Hotjar, widget recensioni) sono i primi responsabili. Ogni script che gira sul main thread blocca le interazioni.

Soluzioni:

Caricare gli script di terze parti in defer o async quando possibile
Spostare su un Web Worker se critico
Consolidare i pixel analytics tramite un solo tag (GTM)
Ritardi volontari: non caricare Hotjar prima di 3 secondi dopo il First Contentful Paint

Handler JavaScript pesanti al clic

Un clic su "Aggiungi al carrello" che attiva 5 chiamate API, anima 3 elementi e apre una modal può impiegare 500 ms per rispondere.

Ottimizzazioni:

Optimistic UI: mostra subito il feedback (il pulsante cambia stato), anche se l'API impiega 300 ms a rispondere
Debounce degli handler: evita di rilanciare calcoli a ogni hover
Sposta le animazioni in CSS invece che in JS quando possibile

Hydration su SPA / framework

Se usi React/Next/Vue, l'"hydration" iniziale può bloccare il main thread per 1-2 secondi. Durante questo tempo, i clic non funzionano.

Soluzioni:

Server-side rendering con contenuto interattivo limitato all'inizio
Progressive hydration: idrata prima le parti critiche
Su Next.js 16+, usa "use client" con parsimonia — più il componente resta server, migliore è l'INP

Strumenti di misurazione

Lab tools (dati simulati, utili in sviluppo):

PageSpeed Insights — rapido, pubblico
Lighthouse (integrato in Chrome DevTools) — dettagliato
WebPageTest — più configurazione, test multi-device

Field data (dati reali degli utenti, critici per Google):

Chrome User Experience Report (CrUX) — dati aggregati pubblici
Google Search Console → Core Web Vitals — il tuo sito nello specifico
PostHog, Vercel Analytics, Cloudflare Web Analytics — monitoraggio continuo

Regola importante: solo i field data contano per il ranking. Un punteggio perfetto in lab con punteggi scarsi in field = nessun effetto SEO positivo.

Per piattaforma

Shopify

Shopify fornisce Core Web Vitals discreti di default. I temi ufficiali (Dawn, Studio, Crave) sono ottimizzati. I Core Web Vitals scarsi su Shopify derivano quasi sempre da:

App di terze parti che iniettano JS pesante
Temi premium di terze parti ottimizzati male
Immagini non compresse

Audit su Shopify: rimuovi le app inutili (Online Store → Apps), usa un tema ufficiale recente, comprimi le immagini.

WooCommerce

Più variabilità in base all'hosting e ai plugin. Stack consigliato:

Hosting performante: Kinsta, WP Engine, Hostinger Cloud (non un condiviso low-cost)
Tema leggero: Storefront ufficiale o un tema personalizzato ottimizzato (non Divi o Avada)
Solo plugin essenziali
Plugin di cache: WP Rocket, Cache Enabler
Plugin per ottimizzazione immagini: ShortPixel, Imagify

Headless

Su Next.js con next/image, ottimizzazione automatica. Su frontend custom: implementa manualmente (formati, lazy, fetchpriority).

FAQ

Quanto tempo serve perché Google tenga conto dei miglioramenti ai Core Web Vitals?

28 giorni di "field data" vengono aggregati per i CrUX. Dopo un rilascio di ottimizzazioni, considera 4-6 settimane prima che il punteggio Google rifletta la realtà. Sii paziente, non fare rollback dopo 1 settimana.

I Core Web Vitals sono più importanti del contenuto per il ranking?

No. Il contenuto (pertinenza, qualità, backlink) resta il fattore dominante. I Core Web Vitals sono un tie-breaker: su due pagine equivalenti per contenuto, quella con i CWV migliori si posiziona meglio. Peggiorare il contenuto per guadagnare in CWV è controproducente.

Posso essere in verde senza CDN?

Per un sito italiano con pubblico solo italiano, sì — se il tuo server è in Italia e ben configurato. Per l'internazionale, il CDN è quasi obbligatorio. Cloudflare gratuito basta nell'80% dei casi.

Devo sacrificare la qualità dell'immagine per migliorare il LCP?

No. La configurazione corretta (WebP/AVIF + dimensioni + CDN + fetchpriority) permette di avere un'immagine 600×600 da 40 KB con qualità equivalente a un JPEG da 200 KB. Il sacrificio non è più necessario dal 2023.

I Core Web Vitals sono gli stessi su mobile e desktop?

Le soglie sì, ma i punteggi vengono misurati separatamente da Google. Una pagina può essere "Good" su desktop e "Poor" su mobile (succede spesso). Google usa principalmente le metriche mobile per il ranking (Mobile-First Indexing).

Quanto denaro investire nell'ottimizzazione CWV?

Inquadramento: se le tue pagine sono già "Good", non serve investire altro. Se sei in "Needs improvement", 1-3 settimane di sviluppo sui fix principali (immagini, script di terze parti, CDN) bastano. Se sei "Poor" su tutto il sito, potrebbe essere necessaria una revisione tecnica — inizia con un audit completo.

Ecomptimize ottimizza automaticamente i Core Web Vitals sulle schede prodotto del tuo catalogo. Vedi Ecomptimize per Shopify o Ecomptimize per WooCommerce.