Cosa sono i Core Web Vitals
I Core Web Vitals sono tre metriche specifiche che Google utilizza per misurare l’esperienza utente reale su un sito web: velocità di caricamento del contenuto principale, reattività alle interazioni e stabilità visiva della pagina.
Non si tratta di KPI isolati o di semplici numeri da inseguire per compiacere un algoritmo ma rappresentano il tentativo di Google di tradurre in dati oggettivi quello che gli utenti percepiscono come “esperienza di navigazione fluida”. Un sito può superare test sintetici, avere tempi di risposta server eccellenti e caricare in 2 secondi, ma se l’utente clicca su un pulsante e non succede nulla per mezzo secondo, o se il layout salta mentre sta leggendo, l’esperienza è compromessa.
Google ha scelto queste metriche perché correlano direttamente con comportamenti misurabili: frequenza di rimbalzo, tempo sulla pagina, conversioni.
I Core web vitals non sono l’unico fattore di ranking (e tra poco vedremo quando incidono davvero), ma sono diventati il linguaggio comune con cui misurare la performance percepita.
La differenza fondamentale rispetto alle metriche tecniche tradizionali è questa: i Core Web Vitals misurano quello che l’utente vive, non quello che il server eroga. E questo cambia completamente l’approccio all’ottimizzazione.
Le metriche dei Core Web Vitals spiegate con esempi reali: LCP, INP e CLS
LCP: perché resta centrale
Il Largest Contentful Paint misura il tempo impiegato dal contenuto visivo più grande della viewport a diventare visibile. Nella maggior parte dei casi si tratta di un’immagine hero, un video, un blocco di testo esteso.
Google considera ottimale un LCP inferiore a 2.5 secondi. Oltre i 4 secondi, il sito è classificato come “poor”.
I problemi più ricorrenti che vediamo negli audit:
- Immagini hero non ottimizzate: file da 3-4 MB caricati senza compressione, senza formati moderni (WebP, AVIF), senza responsive image tramite srcset, assenza di precaricamento, configurazione errata del Lazyload.
- Risorse bloccanti: CSS e JavaScript critici non inline che ritardano il rendering del contenuto principale
- Font personalizzati caricati senza strategia di preload o fallback, causando FOIT (Flash of Invisible Text)
Un caso tipico
Homepage con slider full-screen. L’immagine pesa 2.8 MB e viene caricata come quinta risorsa dopo CSS globale, font e JavaScript di tracciamento. Il risultato? LCP a 5.2 secondi su connessione 3G.
La soluzione non è “comprimere l’immagine”, ma ripensare l’intera strategia di caricamento: priorità assoluta alla hero image, lazy loading per tutto il resto, preload selettivo.
INP: cosa misura davvero l’interazione
L’Interaction to Next Paint è la metrica che ha generato più problemi dopo la sua introduzione a marzo 2024, quando ha sostituito il First Input Delay (FID).
INP misura la latenza tra un’interazione dell’utente (click, tap, pressione tasto) e il successivo aggiornamento visivo dello schermo.
Non si limita alla prima interazione come il FID, ma considera tutte le interazioni durante l’intera sessione e riporta il valore al 98° percentile. La soglia ottimale è sotto i 200ms. Oltre i 500ms, il sito è classificato come problematico.
Perché FID non bastava
Il First Input Delay misurava solo il tempo tra il click dell’utente e l’inizio dell’elaborazione dell’evento da parte del browser. Non considerava:
- Il tempo effettivo di esecuzione del codice
- Il rendering del risultato dell’interazione
- Le interazioni successive alla prima
Un sito poteva avere FID perfetto (sotto i 100ms) ma risultare completamente bloccato per secondi dopo il primo click. FID misurava la disponibilità del main thread, INP misura l’esperienza complessiva di reattività.
Cosa cambia a livello tecnico
Con FID bastava evitare di bloccare il main thread durante il caricamento iniziale. Con INP devi garantire reattività continua durante tutta la sessione. Ogni interazione viene analizzata: apertura menu, cambio filtro, submit form, scroll infinito.
L’impatto maggiore si vede su:
- Siti dinamici con filtri (ecommerce, comparatori): ogni cambio filtro ricalcola risultati, aggiorna DOM, riapplica stili
- Single Page Application: router client-side, gestione stato, virtual DOM diffing
- Siti con animazioni complesse: transizioni CSS pesanti, JavaScript animation library
INP: interazioni reali
Questa è la metrica più problematica nei siti complessi perché è direttamente correlata alla quantità e qualità del JavaScript eseguito. Non basta ridurre il peso totale dei file JavaScript (bundle size), è indispensabile intervenire su quando viene eseguito, se blocca il main thread, se causa reflow e repaint.
La relazione con JavaScript è diretta: ogni libreria di terze parti (chat, analytics, A/B testing, personalizzazione), ogni framework frontend, ogni animazione aggiunge latenza potenziale. Nei siti ecommerce con filtri dinamici, INP diventa il vero collo di bottiglia: l’utente cambia categoria, il sistema deve eseguire query dei dati, aggiornare centinaia di elementi DOM, ricalcolare layout.
Nei progetti che seguiamo, INP alto è quasi sempre sintomo di architettura non ottimizzata per l’interattività, non di “codice lento” isolato.
CLS: il problema dell’instabilità
Il Cumulative Layout Shift misura quanto il layout si sposta durante il caricamento e l’interazione. Ogni volta che un elemento visibile cambia posizione senza input dell’utente, contribuisce al punteggio CLS.
La soglia ottimale è sotto 0.1. Oltre 0.25 il sito è considerato problematico.
Impatto del CLS su UX e conversioni
CLS non è solo un problema estetico. Un utente sta per cliccare su “Acquista”, un banner pubblicitario si carica sopra e l’utente clicca sul banner invece che sul pulsante. Oppure sta leggendo un articolo, un’immagine si carica tardivamente e il testo salta 300 pixel più in basso.
Negli ecommerce, il CLS alto durante il checkout è strettamente correlato con l’abbandono del carrello. L’utente non si fida di un sito che “si muove” mentre sta inserendo dati di pagamento.
Errori comuni
- Immagini senza dimensioni esplicite: il browser non riserva spazio, l’immagine carica e spinge il contenuto verso il basso
- Font web senza fallback: il testo viene renderizzato con font di sistema, poi il font custom carica e cambia dimensione
- Banner e annunci iniettati dinamicamente senza contenitore di dimensione fissa
- Contenuti dinamici (popup, cookie banner, notifiche) inseriti senza transizione o con logica di rendering non ottimizzata
Un caso frequente
Homepage WordPress con widget in sidebar. Ogni widget è un plugin diverso, ognuno carica i propri asset in modo asincrono e si inserisce quando pronto. Risultato: il layout salta 5-6 volte nei primi 3 secondi.
Core Web Vitals e SEO nel 2026
I CWV sono un fattore di ranking?
Google ha confermato che i Core Web Vitals fanno parte dei segnali di Page Experience usati per il ranking. Tuttavia, il loro peso è relativo e contestuale infatti questi non sostituiscono la rilevanza del contenuto.
Un articolo perfettamente ottimizzato ma poco pertinente non supererà mai un contenuto di valore con CWV mediocri. Google continua a premiare innanzitutto la risposta migliore alla query dell’utente.
Quando incidono davvero
I Core Web Vitals diventano discriminanti in situazioni specifiche:
- Settori altamente competitivi: quando più siti offrono contenuti equivalenti, CWV possono fare la differenza nel far scalare le posizioni tra i risultati di ricerca
- Siti già ottimizzati per gli altri fattori: se hai già un contenuto eccellente, backlink di qualità, architettura informativa solida, i CWV sono un ulteriore elemento in grado di farti migliorare il ranking su Google
- Campagne paid con Quality Score: Google Ads considera Page Experience nel calcolo del Quality Score. CWV migliori possono ridurre il CPC e migliorare la posizione degli annunci
In mercati saturi (fashion, travel), dove la competizione è spietata e i contenuti tendono a standardizzarsi, ottimizzare i CWV può tradursi in un miglior posizionamento, una visibilità maggiore e un costo di acquisizione ridotto.
Negli ultimi progetti seguiti, abbiamo osservato miglioramenti di posizionamento non tanto come effetto diretto dei CWV, ma come conseguenza indiretta: riduzione bounce rate, aumento tempo sulla pagina, maggiori interazioni. Tutti segnali che Google interpreta come “contenuto di valore”.
La domanda corretta non è “mi penalizzano?” ma “sto perdendo opportunità rispetto a competitor con CWV migliori?” e la risposta arriva dai dati: confronta le tue metriche con quelle dei siti che ti precedono in SERP per query rilevanti. Se loro hanno CWV significativamente migliori e contenuti comparabili, hai identificato un margine di miglioramento competitivo.
Come misurare i Core Web Vitals
Esistono due categorie di dati che è possibile prendere in considerazione nel misurare i CWV:
- Lab data (dati di laboratorio): test sintetici eseguiti in ambienti controllati con condizioni standardizzate. Strumenti come Lighthouse o PageSpeed Insights in modalità lab simulano il caricamento su un dispositivo specifico con connessione definita.
- Field data (dati reali): metriche raccolte da utenti reali che navigano il sito. Chrome User Experience Report (CrUX) aggrega dati anonimi da milioni di utenti Chrome. La differenza è fondamentale. I lab data sono diagnostici: ti mostrano cosa può essere migliorato in condizioni ideali. I field data sono valutativi: ti mostrano cosa sperimentano gli utenti veri, con dispositivi eterogenei, connessioni variabili, browser diversi.
| Tool | Tipo | Pro | Contro | Quando usarlo |
| PageSpeed Insights | Lab + Field | Diagnostica rapida, combina lab e field data, suggerimenti specifici | Non cattura INP reale in condizioni di utilizzo intenso | Prime analisi, verifica rapida post-intervento |
| GTMetrix | Lab | Waterfall dettagliato, video recording, test da location multiple, storico performance | Versione free limitata, dati solo lab | Analisi approfondita caricamento risorse, monitoring schedulato |
| WebPageTest | Lab | Controllo granulare test (device, connection, location), filmstrip view, test comparativi | Interfaccia complessa, learning curve elevata | Test avanzati con configurazioni custom, troubleshooting tecnico |
| Search Console | Field | Dati aggregati ufficiali Google, influenza ranking, breakdown per tipo dispositivo | Delay di 28 giorni, soglia minima di traffico richiesta | Monitoraggio andamento nel tempo, correlazione con ranking |
| Lighthouse CI | Lab | Automatizzabile in pipeline, test ripetibili, integrazione con CI/CD | Nessun dato utente reale, ambiente sintetico | Prevenzione regressioni in fase di sviluppo |
| CrUX Dashboard | Field | Percentili globali per dominio e origine, confronto con competitor | Dati aggregati senza granularità per singola pagina | Benchmark settore, analisi trend competitor |
Nessuno strumento è sufficiente da solo. L’approccio corretto prevede:
- PageSpeed Insights per diagnosi iniziale e identificazione degli interventi con maggio rapporto effort/beneficio (quick wins)
- Search Console per monitoraggio ufficiale e correlazione ranking
- GTmetrix o WebPageTest per analisi dettagliata del caricamento risorse e waterfall diagnostics
- Lighthouse CI integrato nel processo di sviluppo per evitare regressioni
- Strumenti RUM (Real User Monitoring) per analisi granulare del comportamento utente
Come migliorare i Core Web Vitals sul tuo sito
Il principio fondamentale è: caricare solo quello che serve, dove serve, quando serve. Non si tratta di eliminare funzionalità, ma di ripensare la strategia di delivery.
Ottimizzazione del frontend
è possibile andare a fare una ottimizzazione delle risorse:
- CSS critico inline: identificare gli stili necessari per il rendering above-the-fold e inserirli inline nell’HTML. Il resto va caricato in modo asincrono
- Responsive images: utilizzare srcset e sizes per servire immagini dimensionate correttamente in base al dispositivo. Un’immagine da 2000px visualizzata a 400px su mobile è uno spreco
- Formati moderni: WebP e AVIF riducono peso del 30-50% rispetto a JPEG mantenendo qualità visiva
- Lazy loading strategico: immagini e iframe sotto la piega vanno caricati on-demand. Attenzione a non applicare il lazy-load al contenuto LCP
Gestione JavaScript
Ottimizzazione del codice:
- Code splitting: separare JavaScript per route, componente, funzionalità
- Tree shaking: eliminare codice non utilizzato dai bundle finali
- Defer e async: caricare script non critici in modo da non bloccare il parsing HTML
- Debouncing e throttling: limitare esecuzioni di funzioni legate a eventi frequenti (scroll, resize, input)
Architettura
Decisioni strutturali:
- Static generation dove possibile: generare HTML statico in build time invece di rendering client-side
- Edge computing: spostare logica sul CDN edge per ridurre latenza server
- Partial hydration: nei framework moderni, rendere interattivi solo i componenti che necessitano JavaScript
- Resource hints: preconnect per domini esterni critici, prefetch per risorse che l’utente probabilmente richiederà
Server
Ottimizzazione infrastruttura:
- CDN globale: distribuire asset statici geograficamente vicino agli utenti
- Cache strategy: header HTTP corretti per cache browser e intermediari
- Compression: Brotli o Gzip per ridurre dimensione trasferimento
- HTTP/2 o HTTP/3: multiplexing, header compression, push server
Alcuni esempi concreti:
Una pagina Chi siamo non ha bisogno di Framework JavaScript completo, JavaScript del form, GoogleMap Può essere una semplice pagina HTML con CSS minimale. Invece vediamo costantemente pagine “chi siamo” che caricano 2MB di risorse perché “ereditano” la struttura globale del sito.
Un articolo blog non ha bisogno di funzioni JavaScript E-commerce o filtri prodotti Richiede contenuto leggibile rapidamente, con ottimizzazione immagini e tipografia. Il resto è zavorra.
Questo approccio richiede architettura modulare, non template monolitici. Significa creare logiche di caricamento contestualizzate invece di “caricare sempre tutto ovunque”.
Core Web Vitals e CMS: quando il limite è strutturale
Come ottimizzare i CWV su WordPress e Prestashop
L’ottimizzazione dei Core Web Vitals su piattaforme come WordPress e PrestaShop si scontra spesso con la natura stessa di questi sistemi. Sebbene esistano soluzioni immediate per migliorare le prestazioni, alcuni vincoli strutturali richiedono un approccio più profondo e strategico. Ecco un’analisi dettagliata di cosa è possibile gestire e dove, invece, il sistema mostra i suoi limiti.
Cosa puoi migliorare:
- Logica di caricamento delle risorse
- Plugin di caching performanti con ottimizzazione automatica (critical CSS, minification, lazy loading)
- Tema leggero o headless con generazione statica
- Ottimizzazione database e query
- Ottimizzazione e gestione delle immagini
- CDN per asset statici
- Riduzione numero plugin attivi
Cosa non puoi migliorare facilmente:
- Architettura monolitica che carica WordPress o Prestashop core anche per pagine statiche
- Plugin mal sviluppati che iniettano risorse globalmente
- Hook e filtri che eseguono query ridondanti
- Gestione asset non ottimizzata con page builder
Quando serve sviluppo avanzato:
Quando il sito ha:
- Oltre 50-60 plugin attivi
- Page builder con logica di rendering complessa
- Funzionalità custom che richiedono JavaScript pesante
- Necessità di performance
In questi casi, l’ottimizzazione marginale non basta. Serve refactoring architetturale: headless WordPress con frontend statico, microservizi per funzionalità complesse, CDN edge con logica custom.
Come ottimizzare i CWV per Shopify
Ottimizzare un ecosistema chiuso come Shopify richiede un equilibrio tra le potenzialità della piattaforma e i suoi vincoli strutturali predefiniti. Sebbene l’infrastruttura offra una base solida, il raggiungimento di prestazioni eccellenti dipende spesso dalla gestione rigorosa degli asset e delle applicazioni di terze parti.
Quando le esigenze di personalizzazione superano le capacità del sistema standard, diventa necessario valutare soluzioni architetturali più avanzate.
Cosa puoi migliorare:
- Tema performance-oriented o custom development
- App strettamente necessarie (ogni app aggiunge overhead)
- Ottimizzazione e gestione delle immagini
- Ottimizzazione asset del tema
Cosa non puoi migliorare:
- Infrastruttura server (gestita da Shopify)
- Logica checkout (closed system)
- Loading di Shopify core JavaScript
- Alcune limitazioni architetturali della piattaforma
Quando serve sviluppo avanzato:
- Temi fortemente customizzati con logica complessa
- Headless Shopify con frontend custom (React, Next.js)
- Integrazione sistemi esterni (ERP, CRM, PIM)
- Personalizzazione checkout (Shopify Plus)
Come ottimizzare i CWV su un sito Custom
Lo sviluppo di soluzioni custom rappresenta la massima libertà tecnica, permettendo di plasmare ogni parte del progetto alle specifiche esigenze di business. Tuttavia, questo controllo totale sposta la responsabilità dell’ottimizzazione interamente sul team di sviluppo, rendendo la performance un obiettivo da progettare sin dalle fondamenta. In questo scenario, il limite non è più la piattaforma, ma la capacità di bilanciare innovazione tecnologica e sostenibilità dei costi.
Cosa puoi migliorare:
Tutto, perché controlli l’intero stack. Ma richiede competenza:
- Architettura ottimizzata per performance (SSR, SSG, ISR)
- Gestione granulare del caching
- Build ottimizzata con code splitting avanzato
- Database query optimization
- Infrastructure as Code con auto-scaling
Cosa non puoi migliorare:
Vincoli di business:
- Script di terze parti obbligatori (tracking, advertising, compliance)
- Funzionalità legacy che richiedono refactoring profondo
- Integrazioni con sistemi esterni lenti
Quando serve sviluppo avanzato:
Sempre, perché custom significa governance completa ma anche responsabilità totale. Serve team con competenze full-stack, conoscenza performance optimization, capacità di progettazione architetturale.
Il vantaggio: potenziale di ottimizzazione illimitato.
Lo svantaggio: complessità e costi di manutenzione elevati.
I Core Web Vitals come parte dell’architettura del sito
I Core Web Vitals non sono un traguardo da raggiungere una volta e dimenticare, ma un processo continuo di ottimizzazione e monitoraggio. Ogni aggiornamento del sito, ogni nuovo plugin, ogni script di terze parti può impattare le metriche.
L’approccio corretto non è “sistemare i numeri”, ma costruire un’architettura che per design produce performance eccellenti. Questo richiede competenze tecniche specifiche, visione strategica e attenzione costante.
