Le 7 metriche di Core Web Vitals che ogni PMI italiana deve monitorare nel 2026
Pubblicato il 21 apr 2026 · Aggiornato il 21 apr 2026 · 11 min lettura
Di Redazione Atlante Digitale, Redazione Atlante Digitale
Le 7 metriche di Core Web Vitals che ogni PMI italiana deve monitorare nel 2026
Nel 2021 Google ha trasformato la velocità e la qualità percepita di un sito web da buona pratica tecnica a fattore di ranking ufficiale. Cinque anni dopo, il quadro si è consolidato, ma anche evoluto: una metrica è stata sostituita, i dati di campo hanno assunto peso crescente rispetto ai test di laboratorio, e le soglie sono diventate benchmark de facto per qualsiasi sito che voglia competere nei risultati di ricerca.
Per le PMI italiane — che gestiscono siti spesso costruiti anni fa, con risorse tecniche limitate — capire esattamente cosa misurare, con quale strumento e con quale priorità è più utile di qualsiasi panoramica generica. Questo articolo analizza le 7 metriche che compongono oggi l'ecosistema Core Web Vitals, le soglie ufficiali, l'impatto pratico sul business e gli strumenti accessibili per il monitoraggio autonomo.
Il contesto: le PMI italiane e la performance web nel 2026
Prima di entrare nelle metriche, vale la pena quantificare il problema. Il ritardo digitale delle imprese italiane di piccola e media dimensione non riguarda solo la presenza online, ma la qualità tecnica di quella presenza.
Il 67% delle PMI italiane con 10-49 dipendenti possiede un sito web attivo, ma solo il 29% dichiara di aver effettuato interventi tecnici sul sito negli ultimi 12 mesi.
Fonte: ISTAT — Cittadini e ICT 2024
A livello globale, solo il 43% delle pagine web supera la soglia "Good" su tutti e tre i Core Web Vitals principali. Per i siti con CMS (WordPress, Joomla, PrestaShop) il dato scende al 38%.
Fonte: HTTP Archive — Web Almanac 2024
La competizione non è quindi impossibile: la maggior parte dei siti concorrenti ha gli stessi problemi. Monitorare e migliorare sistematicamente le metriche CWV è un vantaggio differenziale concreto, non un esercizio accademico.
Come funziona il sistema di misurazione: laboratorio vs campo
Prima di analizzare le singole metriche, è essenziale distinguere due modalità di misurazione che Google utilizza in parallelo.
Dati di laboratorio (Lab Data)
Simulazioni effettuate da strumenti come Lighthouse (integrato in PageSpeed Insights e Chrome DevTools) in condizioni controllate: rete 4G simulata, dispositivo mobile di fascia media simulato. Sono riproducibili e utili per il debugging, ma non riflettono l'esperienza reale degli utenti.
Dati di campo (Field Data / CrUX)
Il Chrome User Experience Report (CrUX) raccoglie metriche reali dagli utenti Chrome che hanno attivato la condivisione dei dati. Questi dati alimentano:
Google Search Console → report "Esperienza pagina"
PageSpeed Insights → sezione "Dati sul campo"
Google BigQuery → dataset pubblico aggiornato mensilmente
Per il ranking Google, contano i dati di campo, non quelli di laboratorio. Una PMI con un sito che ottiene 95/100 su Lighthouse ma che viene visitato da utenti con connessioni lente o dispositivi vecchi potrebbe comunque avere score CrUX "Needs Improvement".
Le 7 metriche Core Web Vitals nel 2026
1. LCP — Largest Contentful Paint
Cosa misura: il tempo necessario affinché l'elemento visivo più grande della pagina (spesso un'immagine hero, un video thumbnail o un blocco di testo H1) diventi visibile nel viewport.
Soglie ufficiali:
Rating
Soglia
Good
≤ 2.5 secondi
Needs Improvement
2.5s – 4.0s
Poor
> 4.0 secondi
LCP è la metrica con il maggiore impatto percepito sull'esperienza utente: studi Google mostrano che passare da LCP "Poor" a "Good" riduce il tasso di abbandono della pagina del 24% in media.
Fonte: Google Web Dev — Core Web Vitals thresholds 2025
Cause più comuni di LCP lento nelle PMI italiane:
Immagini hero non compresse o in formato JPEG/PNG anziché WebP/AVIF
Hosting condiviso con TTFB (Time to First Byte) superiore a 600ms
Font web caricati senza font-display: swap
JavaScript che blocca il rendering prima del caricamento del contenuto principale
Cosa fare: L'elemento LCP va identificato (PageSpeed Insights lo evidenzia) e ottimizzato con priorità assoluta. Per un e-commerce, spesso è l'immagine del prodotto in primo piano; per un sito aziendale, il logo o il titolo principale.
2. INP — Interaction to Next Paint
Cosa misura: la latenza dell'interazione più lenta tra l'utente e la pagina durante l'intera sessione di navigazione — clic su bottoni, pressioni di tasti, tap su mobile. INP ha sostituito FID a marzo 2024.
Soglie ufficiali:
Rating
Soglia
Good
≤ 200 millisecondi
Needs Improvement
200ms – 500ms
Poor
> 500 millisecondi
Con l'introduzione di INP come metrica Core Web Vitals, il 12% dei siti precedentemente classificati "Good" su tutti i CWV è retrocesso a "Needs Improvement", principalmente per JavaScript pesante da plugin di terze parti.
Fonte: HTTP Archive — Web Almanac 2024
La differenza rispetto a FID è sostanziale: FID misurava solo il ritardo del primo input, ignorando tutto ciò che accadeva dopo. INP cattura la reattività dell'intera esperienza — inclusi i rallentamenti su form multi-step, filtri di prodotto, modal e widget di chat.
Per le PMI: plugin di live chat (Tawk.to, Zendesk), widget di prenotazione, script di analytics multipli e pixel pubblicitari sono i principali responsabili di INP elevato. Auditare gli script di terze parti è spesso più efficace che riscrivere il codice proprietario.
3. CLS — Cumulative Layout Shift
Cosa misura: la somma di tutti i movimenti inaspettati degli elementi della pagina durante il caricamento — il fenomeno del "testo che salta" quando arriva un'immagine o un banner pubblicitario.
Soglie ufficiali:
Rating
Soglia
Good
≤ 0.1
Needs Improvement
0.1 – 0.25
Poor
> 0.25
Un CLS superiore a 0.25 corrisponde a uno scenario in cui l'utente clicca sul pulsante sbagliato perché il layout si è spostato nell'istante del clic — uno dei principali cause di frustrazioni e acquisti accidentali mancati.
Fonte: Google Web Dev — Core Web Vitals thresholds 2025
Cause frequenti:
Immagini senza attributi width e height espliciti nell'HTML
Banner pubblicitari (Google AdSense, banner diretti) senza spazio riservato
Font web che sostituiscono il font di sistema con dimensioni diverse
Contenuto iniettato dinamicamente (cookie banner, popup) che sposta il layout
Nota pratica: il CLS è migliorabile quasi interamente a livello CSS/HTML, senza toccare il backend. Su WordPress, il plugin Perfmatters o la configurazione avanzata di WP Rocket includono opzioni specifiche per riservare spazio alle immagini lazy-loaded.
4. FCP — First Contentful Paint
Cosa misura: il tempo dal primo byte di risposta del server al momento in cui il browser renderizza il primo elemento di contenuto (testo, immagine, SVG) nel DOM.
Soglie ufficiali:
Rating
Soglia
Good
≤ 1.8 secondi
Needs Improvement
1.8s – 3.0s
Poor
> 3.0 secondi
FCP non è un Core Web Vital "core" (non influenza direttamente il ranking quanto LCP, INP e CLS), ma è un indicatore diagnostico fondamentale: un FCP lento segnala problemi di server, rete o CSS render-blocking che si ripercuotono su tutto il resto.
I siti e-commerce italiani con FCP superiore a 3 secondi registrano un tasso di conversione inferiore del 32% rispetto a quelli con FCP inferiore a 1.8 secondi, a parità di prezzo e offerta.
Fonte: Osservatorio eCommerce B2c — Politecnico di Milano 2024
5. TTFB — Time to First Byte
Cosa misura: il tempo che intercorre tra la richiesta HTTP dell'utente e il primo byte di risposta dal server. È una metrica "di diagnostica" nelle linee guida Google, ma influenza direttamente FCP e LCP.
Soglie di riferimento:
Rating
Soglia
Good
≤ 800 millisecondi
Needs Improvement
800ms – 1800ms
Poor
> 1800 millisecondi
Per le PMI su hosting condiviso o VPS economici con server fisici fuori dall'Italia, TTFB è spesso il collo di bottiglia principale. Un hosting con datacenter in Italia o nell'Europa centrale (Germania, Paesi Bassi) riduce il TTFB di 200-400ms per gli utenti italiani rispetto a server nordamericani.
Soluzioni pratiche:
Migrazione a hosting con SSD NVMe e PHP 8.x (vs PHP 7.x ancora comune)
Attivazione CDN (Cloudflare gratuito riduce TTFB medio del 40-60% per asset statici)
Cache full-page per siti WordPress (LiteSpeed Cache, WP Rocket)
6. TBT — Total Blocking Time
Cosa misura: la somma del tempo in cui il thread principale del browser è bloccato da JavaScript tra FCP e TTI (Time to Interactive). Non è raccolta dal CrUX (quindi non è un dato di campo diretto), ma è il principale proxy di laboratorio per predire INP.
Soglia di riferimento Lighthouse:
Rating
Soglia
Good
≤ 200 millisecondi
Needs Improvement
200ms – 600ms
Poor
> 600 millisecondi
TBT è l'indicatore di laboratorio più correlato a INP nei test su larga scala. Una riduzione di TBT da 600ms a 200ms corrisponde, nel 78% dei casi analizzati, a un miglioramento di INP da "Poor" a "Good" nei dati di campo CrUX.
Fonte: Google Web Dev — Core Web Vitals documentation 2025
Per le PMI, TBT elevato è quasi sempre causato da script JavaScript di terze parti caricati in modo sincrono: pixel Facebook/Meta, tag Google Ads, script di chat, widget di recensioni. La soluzione più efficace è il caricamento differito (lazy loading o defer) di questi script e la loro migrazione attraverso Google Tag Manager con regole di attivazione ritardata.
7. TTI — Time to Interactive
Cosa misura: il momento in cui la pagina è completamente interattiva — il thread principale è libero, i gestori degli eventi sono registrati, la pagina risponde ai clic in meno di 50ms.
Soglia di riferimento Lighthouse:
Rating
Soglia
Good
≤ 3.8 secondi
Needs Improvement
3.8s – 7.3s
Poor
> 7.3 secondi
TTI è diventato meno centrale come metrica standalone con l'introduzione di INP, poiché quest'ultima è più rappresentativa dell'interattività percepita dall'utente reale. Tuttavia rimane utile come metrica aggregata di "salute complessiva" del JavaScript sulla pagina.
La matrice di priorità per una PMI italiana
Non tutte le metriche hanno lo stesso peso. Ecco una matrice operativa per chi ha risorse limitate:
Metrica
Impatto ranking Google
Impatto UX percepita
Difficoltà fix medio
Priorità PMI
LCP
Alto
Alta
Media
Critica
INP
Alto
Alta
Media-Alta
Critica
CLS
Alto
Alta
Bassa
Critica
FCP
Indiretto
Media
Bassa-Media
Alta
TTFB
Indiretto
Media
Media (dipende hosting)
Alta
TBT
Lab only
Media
Media
Media
TTI
Lab only
Bassa-Media
Media
Bassa
La regola pratica: risolvere LCP, INP e CLS porta al 90% dei benefici con il 60% dello sforzo totale.
Strumenti di monitoraggio accessibili senza competenze tecniche avanzate
Google Search Console — Report "Esperienza pagina"
Disponibile gratuitamente per qualsiasi sito verificato, mostra la distribuzione delle URL in "Good", "Needs Improvement" e "Poor" per LCP, INP e CLS, usando dati CrUX reali. È il punto di partenza obbligatorio.
Solo il 34% delle PMI europee con meno di 50 dipendenti utilizza strumenti di analisi della performance web oltre a Google Analytics. In Italia il dato è al 28%, tra i più bassi dell'UE-27.
Fonte: Eurostat — Digital Economy and Society Index 2024
PageSpeed Insights
Fornisce sia dati di laboratorio (Lighthouse) sia dati di campo (CrUX) per singola URL. Particolarmente utile per analisi pagina per pagina prima di un intervento specifico (es. ottimizzazione scheda prodotto).
Google offre un template gratuito per Looker Studio (ex Data Studio) che connette il dataset CrUX pubblico e visualizza le tendenze nel tempo per il proprio dominio. Richiede un account Google e circa 30 minuti di configurazione.
Per i siti che usano Cloudflare (anche il piano gratuito), Web Analytics fornisce metriche di performance aggregate senza script aggiuntivi sulla pagina, con impatto zero su TBT e INP.
Un piano d'azione in tre fasi per PMI con risorse limitate
Eseguire PageSpeed Insights sulle 5 pagine più trafficate (homepage, 2 pagine di servizio/prodotto, contatti, una categoria se e-commerce)
Annotare le metriche critiche e le 3 raccomandazioni principali di Lighthouse per ciascuna pagina
Fase 2 — Quick wins (2-4 settimane, bassa complessità tecnica)
Convertire tutte le immagini in WebP/AVIF e aggiungere width/height nell'HTML (risolve LCP e CLS)
Attivare Cloudflare CDN gratuito (migliora TTFB e FCP)
Differire script di terze parti non critici via GTM (migliora INP e TBT)
Attivare plugin di cache full-page se si usa CMS (migliora TTFB, FCP, LCP)
Fase 3 — Interventi strutturali (1-3 mesi, richiede sviluppatore)
Revisione del tema o template: eliminare CSS/JS non utilizzati
Migrazione a hosting gestito con datacenter europeo se TTFB > 1.5s
Audit e riduzione dei plugin attivi (ogni plugin WordPress aggiunge in media 20-80ms di TBT)
Implementazione di font-display: swap e preload dei font critici
Il legame tra Core Web Vitals e conversioni: i dati che contano per le PMI
Le metriche di performance non sono rilevanti solo per il ranking: l'impatto sulle conversioni è documentato e misurabile.
Per gli e-commerce italiani di fascia media (100K-1M€ di fatturato online annuo), ogni secondo di miglioramento del LCP corrisponde a un aumento del tasso di conversione stimato tra il 7% e il 12%.
Fonte: Osservatorio eCommerce B2c — Politecnico di Milano 2024
I siti che passano da rating "Poor" a "Good" su INP registrano una riduzione del 18% nel tasso di abbandono dei form — dato rilevante per PMI con preventivatori, moduli di contatto o checkout complessi.
Fonte: HTTP Archive — Web Almanac 2024
Il nesso causale è diretto: un'interazione lenta o un layout che salta durante la compilazione di un modulo genera frustrazione e abbandono. Google misura questo effetto e lo incorpora nel ranking come proxy della soddisfazione dell'utente.
Cosa cambia nel 2026 rispetto al 2024
Tre evoluzioni significative meritano attenzione:
1. Peso crescente dei dati di campo su mobile. Google ha aumentato la ponderazione dei dati CrUX mobile rispetto a desktop nell'algoritmo. Per le PMI con un pubblico prevalentemente da smartphone (settori retail, ristorazione, servizi locali), ottimizzare su rete 4G reale è più rilevante che raggiungere punteggi perfetti su desktop.
2. INP stabilizzato come metrica matura. Dopo la transizione da FID (completata a settembre 2024), INP è ora pienamente integrato in tutti gli strumenti Google. I dati storici FID non sono comparabili con INP, quindi benchmark precedenti al 2024 vanno ignorati.
3. Attenzione crescente a Soft Navigation. Google sta sperimentando il supporto per le SPA (Single Page Application) nella misurazione dei CWV tramite l'API Soft Navigation. Non è ancora un fattore di ranking, ma sarà rilevante per PMI con siti React/Vue/Next.js nei prossimi 12-18 mesi.
Sì. Dal maggio 2021 Google include i Core Web Vitals come segnale di ranking nell'algoritmo Page Experience. Non sono l'unico fattore, ma pagine con performance 'Poor' su LCP o INP subiscono penalizzazioni misurabili, specialmente nelle serp mobile.
FID (First Input Delay) misurava solo il ritardo del primo clic. INP (Interaction to Next Paint), che lo ha sostituito ufficialmente a marzo 2024, misura la latenza dell'interazione peggiore durante l'intera sessione. Per le PMI con siti ricchi di form, carrelli o widget, INP è molto più rappresentativo dell'esperienza reale dell'utente.
PageSpeed Insights (pagespeed.web.dev) è il punto di partenza: fornisce sia dati di laboratorio (Lighthouse) sia dati reali di campo (CrUX). Google Search Console mostra i dati aggregati per tutte le URL indicizzate. Per monitoraggio continuativo, Cloudflare Web Analytics o la versione free di SpeedCurve Lux sono accessibili anche senza sviluppatori.
Google raccoglie dati CrUX su finestre mobili di 28 giorni. Per PMI con aggiornamenti frequenti al sito (campagne, nuovi prodotti, plugin), si consiglia una verifica mensile tramite Search Console e una scansione trimestrale approfondita con PageSpeed Insights su tutte le pagine chiave (homepage, categorie, schede prodotto, contatti).
Sì, ma richiede intervento tecnico mirato. I colli di bottiglia più comuni su WordPress sono temi pesanti, plugin JavaScript bloccanti, immagini non ottimizzate e hosting condiviso lento. Con un tema leggero (Kadence, GeneratePress), un plugin di cache adeguato (LiteSpeed Cache o WP Rocket) e immagini WebP/AVIF, raggiungere LCP < 2.5s e INP < 200ms è praticabile anche senza sviluppatori dedicati.