Core Web Vitals: Cosa Sono, Come Misurarli e Come Migliorarli

I Core Web Vitals sono tre metriche che Google usa per giudicare quanto è veloce, reattivo e stabile il tuo sito web — e incidono direttamente sul tuo posizionamento. Se il tuo sito è lento, Google lo sa, i tuoi visitatori lo sentono e il tuo fatturato ne risente. In questo articolo ti spiego cosa sono queste metriche, come misurarle e, soprattutto, come migliorarle concretamente.

Io sono Andrea Baglioni, freelancer digitale a Perugia. Costruisco siti web per PMI e professionisti in Umbria e in tutta Italia, e mi occupo quotidianamente di performance e SEO. Ti parlo di Core Web Vitals non come teoria, ma come pratica che applico ogni giorno sui progetti dei miei clienti.

Punti Chiave

Aspetto	Dettaglio
Cosa sono	3 metriche Google: LCP (velocità), INP (interattività), CLS (stabilità visiva)
Perché contano	Fattore di ranking confermato da Google dal 2021
Soglia critica	LCP < 2,5s, INP < 200ms, CLS < 0,1
Strumento principale	PageSpeed Insights (pagespeed.web.dev)
Impatto reale	1 secondo di ritardo = -7% conversioni, +11% bounce rate
Soluzione più efficace	Siti statici con framework moderni (Astro) battono WordPress su tutti i fronti

Cosa Sono i Core Web Vitals

Google ha introdotto i Core Web Vitals nel 2020 e li ha resi fattore di ranking ufficiale nel giugno 2021. Sono tre indicatori che misurano l’esperienza utente reale — non metriche astratte, ma esattamente ciò che il visitatore percepisce quando apre una pagina del tuo sito.

Ogni metrica ha soglie precise: buono, da migliorare, scarso. Google le valuta usando dati reali raccolti dal browser Chrome (il cosiddetto Chrome User Experience Report, o CrUX), non solo test di laboratorio. Questo significa che conta la performance effettiva percepita dai tuoi utenti, non quella simulata.

Le soglie ufficiali di Google

Metrica	Buono	Da Migliorare	Scarso
LCP (Largest Contentful Paint)	≤ 2,5 secondi	2,5s - 4,0s	> 4,0 secondi
INP (Interaction to Next Paint)	≤ 200 ms	200ms - 500ms	> 500 ms
CLS (Cumulative Layout Shift)	≤ 0,1	0,1 - 0,25	> 0,25

Ora vediamo ciascuna metrica nel dettaglio, con spiegazioni pratiche e soluzioni concrete.

LCP: Largest Contentful Paint (Velocità di Caricamento)

L’LCP misura il tempo necessario per caricare l’elemento visivo più grande nella viewport — di solito l’immagine hero, un video in primo piano o il blocco di testo principale. In parole semplici: quanto tempo deve aspettare il visitatore prima di vedere il contenuto principale della pagina.

Soglia ideale: sotto i 2,5 secondi.

Un LCP di 4 secondi sembra poco, ma pensa a quando stai cercando un ristorante a Perugia sul telefono, in pausa pranzo. Aspetti 4 secondi? No. Chiudi e vai al risultato successivo. Google lo sa, e per questo penalizza i siti lenti.

Cosa rallenta l’LCP

Immagini non ottimizzate: foto caricate a risoluzione piena (3000x2000 pixel) quando lo schermo ne mostra 800x500
Server lento: hosting condiviso economico che risponde in 800ms invece di 50ms
CSS e JavaScript che bloccano il rendering: il browser non può mostrare nulla finché non ha scaricato e processato tutti i file CSS e JS nel <head>
Mancanza di caching: ogni visita richiede di scaricare tutto da zero
Font web pesanti: il testo resta invisibile finché il font non viene scaricato completamente

Come ottimizzare l’LCP — azioni concrete

1. Ottimizza le immagini (impatto: altissimo)

Le immagini sono la causa numero uno di un LCP lento. Ecco cosa fare:

Converti le immagini in formato WebP o AVIF — riducono il peso del 25-50% rispetto al JPEG senza perdita di qualità visibile
Usa dimensioni appropriate: se il contenitore è largo 800px, non caricare un’immagine da 2400px
Implementa il responsive images con srcset per servire la dimensione giusta a ogni dispositivo
Usa loading="lazy" per le immagini sotto la piega (below the fold), ma mai per l’immagine hero — quella deve caricarsi subito
Aggiungi fetchpriority="high" all’immagine LCP per dire al browser di darle la priorità

2. Migliora il server (impatto: alto)

Il Time to First Byte (TTFB) — il tempo che il server impiega a rispondere — incide direttamente sull’LCP. Se il server è lento, tutto il resto è inutile.

Usa un VPS dedicato invece di hosting condiviso (su un hosting condiviso il tuo sito compete con centinaia di altri per le risorse)
Scegli un web server moderno come Caddy, che gestisce automaticamente HTTP/2, compressione e certificati SSL
Implementa un CDN (Content Delivery Network) per servire i file statici da server vicini ai tuoi utenti
Attiva il caching aggressivo: i file statici (CSS, JS, immagini) possono avere cache di 1 anno con Cache-Control: public, max-age=31536000, immutable

3. Elimina le risorse che bloccano il rendering (impatto: alto)

Sposta i JavaScript non critici in fondo alla pagina o usa l’attributo defer
Inline il CSS critico (above the fold) direttamente nell’HTML e carica il resto in modo asincrono
Precarica le risorse critiche con <link rel="preload"> — specialmente i font e l’immagine hero
Rimuovi il CSS e JavaScript inutilizzato: molti siti caricano librerie intere per usare una singola funzione

INP: Interaction to Next Paint (Interattività)

L’INP ha sostituito il vecchio FID (First Input Delay) a marzo 2024. Misura il tempo tra un’interazione dell’utente — clic su un pulsante, tap su un link, pressione di un tasto — e il momento in cui il browser mostra la risposta visiva. A differenza del FID, che misurava solo la prima interazione, l’INP monitora tutte le interazioni durante la visita e riporta il caso peggiore (al 75esimo percentile).

Soglia ideale: sotto i 200 millisecondi.

Un INP alto significa che l’utente clicca su “Aggiungi al carrello” e non succede nulla per mezzo secondo. O che tocca il menu di navigazione e lo vede aprirsi con ritardo. Ogni ritardo erode la fiducia.

Cosa peggiora l’INP

JavaScript pesante sul main thread: script che bloccano il browser per centinaia di millisecondi alla volta
Task lunghi (Long Tasks): operazioni JavaScript che superano i 50ms e impediscono al browser di rispondere agli input
Troppi event listener: centinaia di listener su scroll, mousemove, resize che rallentano ogni interazione
Layout recalc e reflow pesanti: modifiche al DOM che forzano il browser a ricalcolare il layout dell’intera pagina
Plugin e widget di terze parti: chatbot, analytics multipli, pixel di tracciamento che aggiungono JavaScript non controllabile

Come ottimizzare l’INP

Spezza i task lunghi usando requestIdleCallback, setTimeout(fn, 0) o la nuova API scheduler.yield() per cedere il controllo al browser tra un’operazione e l’altra
Usa il debouncing e il throttling per eventi ad alta frequenza (scroll, resize, input) — non serve eseguire codice a ogni singolo evento
Riduci il lavoro del DOM: meno elementi nella pagina, meno listener, meno ricalcoli. Un DOM con 1.500+ elementi diventa problematico
Sposta il lavoro pesante nei Web Worker: calcoli complessi, parsing di dati, manipolazione di stringhe — tutto questo può girare in un thread separato senza bloccare l’interfaccia
Rimuovi il JavaScript inutile: ogni script di terze parti che carichi (analytics, pixel, chatbot, social widget) aggiunge latenza. Chiediti: mi serve davvero?
Carica JavaScript in modo differito: usa type="module", defer o il dynamic import per caricare il codice solo quando serve

CLS: Cumulative Layout Shift (Stabilità Visiva)

Il CLS misura quanto gli elementi della pagina si spostano inaspettatamente durante il caricamento. Hai presente quando stai per cliccare un pulsante e la pagina “salta” perché si è caricata un’immagine sopra, un banner pubblicitario o un font diverso? Quello spostamento è un layout shift, e il CLS ne calcola l’impatto cumulativo.

Soglia ideale: sotto 0,1.

Un CLS alto non è solo fastidioso — può causare clic accidentali (immagina cliccare su “Acquista” invece di “Leggi le recensioni” perché la pagina si è spostata). Per un e-commerce o per qualsiasi sito che genera lead, questo è un problema serio.

Cause principali di CLS alto

Immagini e video senza dimensioni specificate: il browser non sa quanto spazio riservare finché non li scarica, e quando arrivano spinge tutto il contenuto in basso
Annunci e embed dinamici: banner pubblicitari, iframe di YouTube, widget social che si caricano in ritardo
Font web che cambiano dimensione: quando il font di sistema viene sostituito dal web font, le righe di testo possono cambiare altezza e larghezza
Contenuto inserito dinamicamente: popup di cookie consent, barre di notifica, elementi iniettati da JavaScript sopra il contenuto già visibile

Come ottimizzare il CLS

Specifica sempre width e height per immagini, video e iframe — oppure usa aspect-ratio in CSS. Questo permette al browser di riservare lo spazio corretto prima del caricamento
Riserva spazio per i contenuti dinamici: se sai che un banner sarà alto 90px, crea un contenitore con min-height: 90px prima che il banner si carichi
Usa font-display: swap con attenzione: meglio ancora, usa font-display: optional o carica i font in <link rel="preload"> per ridurre il flash of unstyled text
Non inserire mai contenuti sopra quelli già visibili: se devi mostrare un banner, aggiungi spazio in anticipo o posizionalo in modo che non sposti il contenuto esistente
Usa le transizioni CSS: se un elemento deve cambiare dimensione, animalo con transform invece di modificare height o width — le trasformazioni non causano layout shift

Come Misurare i Core Web Vitals

Non puoi migliorare ciò che non misuri. Esistono diversi strumenti, ciascuno con un ruolo specifico. Ti consiglio di usarli in combinazione.

Google PageSpeed Insights (il punto di partenza)

Vai su pagespeed.web.dev e inserisci l’URL della pagina da analizzare. Otterrai due tipi di dati:

Dati di campo (Field Data): basati sugli utenti reali che visitano il tuo sito tramite Chrome (report CrUX). Sono i dati che Google usa per il ranking. Se il tuo sito ha abbastanza traffico, li vedrai in alto nel report
Dati di laboratorio (Lab Data): simulazione in condizioni controllate. Utili per diagnosticare problemi, ma non riflettono esattamente l’esperienza degli utenti reali

PageSpeed ti dà anche una lista di opportunità e diagnostiche con suggerimenti specifici su cosa migliorare.

Google Search Console (visione d’insieme)

Nella sezione “Esperienza con le pagine” trovi il report dei Core Web Vitals per tutto il sito. Search Console raggruppa le pagine per tipo e ti mostra quante hanno valori buoni, da migliorare o scarsi. Questo è utile per capire la situazione globale e identificare le aree problematiche.

Il vantaggio di Search Console è che monitora le metriche nel tempo: puoi vedere se i tuoi interventi stanno funzionando e se le prestazioni migliorano settimana dopo settimana.

Chrome DevTools (diagnosi tecnica)

Il pannello Performance di Chrome DevTools è lo strumento per chi vuole andare in profondità. Registra un profilo di caricamento della pagina e mostra esattamente cosa sta succedendo millisecondo per millisecondo: quali script bloccano il rendering, dove avvengono i layout shift, quanto dura ogni task.

Per usarlo: apri DevTools (F12), vai al pannello Performance, premi il pulsante di registrazione, ricarica la pagina e analizza il waterfall risultante. Cerca i “Long Tasks” evidenziati in rosso — quelli sono i principali colpevoli di un INP alto.

Web Vitals Extension (monitoraggio in tempo reale)

Questa estensione per Chrome mostra i Core Web Vitals in tempo reale mentre navighi il sito. Utile per verificare rapidamente le metriche su pagine specifiche senza aprire PageSpeed Insights ogni volta. Mostra LCP, INP e CLS con codice colore verde/giallo/rosso.

Lighthouse (audit completo)

Integrato in Chrome DevTools (pannello Lighthouse), genera un report completo con punteggi da 0 a 100 per Performance, Accessibilità, Best Practices e SEO. Il punteggio Performance include i Core Web Vitals ma va oltre, analizzando anche Total Blocking Time, Speed Index e Time to Interactive.

Una nota importante: Lighthouse testa in condizioni di laboratorio con throttling di CPU e rete. I punteggi possono essere più bassi rispetto all’esperienza reale degli utenti su dispositivi e connessioni veloci.

Perché i Core Web Vitals Contano per la SEO

Google lo ha dichiarato nero su bianco: i Core Web Vitals sono un fattore di ranking. Dal Page Experience Update del 2021, queste metriche entrano nell’algoritmo e influenzano la posizione del tuo sito nei risultati di ricerca.

Detto questo, servono chiarezza: i Core Web Vitals non sono il fattore di ranking numero uno. La pertinenza del contenuto, i backlink e l’autorità del dominio restano più importanti. Ma funzionano come fattore di spareggio: a parità di altri segnali, il sito con Core Web Vitals migliori vince. Per keyword competitive — quelle dove la differenza tra pagina 1 e pagina 2 vale migliaia di euro — questo spareggio può essere decisivo.

L’impatto sulle metriche comportamentali

Un sito lento e instabile non viene solo penalizzato da Google direttamente. Genera anche segnali comportamentali negativi che, indirettamente, peggiorano il ranking:

Bounce rate più alto: secondo i dati di Google, il 53% degli utenti mobile abbandona una pagina che impiega più di 3 secondi a caricarsi. A Perugia, dove oltre il 65% delle ricerche avviene da smartphone, questo dato è ancora più rilevante
Meno pagine viste per sessione: un sito lento scoraggia la navigazione. L’utente trova quello che cerca (se ci riesce) e se ne va, invece di esplorare altre pagine
Meno conversioni: Amazon ha calcolato che ogni 100ms di ritardo costa l’1% delle vendite. Per un e-commerce locale che fattura 100.000 euro l’anno, un secondo di ritardo equivale a 7.000 euro persi
Meno tempo sulla pagina: se la pagina salta (CLS alto) o non risponde ai clic (INP alto), l’utente perde pazienza. Questo segnale di insoddisfazione arriva a Google

Quanto costa un sito lento in termini concreti

Facciamo un esempio reale. Un professionista a Perugia — un dentista, un avvocato, un commercialista — riceve 500 visite al mese dal sito. Il tasso di conversione (richieste di contatto) è del 3%, che significa 15 potenziali clienti al mese.

Se il sito è lento (LCP sopra i 4 secondi), il bounce rate aumenta del 30%. Quelle 500 visite diventano effettive solo 350. Il 3% di 350 fa 10,5 contatti. Hai perso 4-5 potenziali clienti al mese — non per il contenuto, non per la SEO, ma per la velocità.

Se ogni cliente vale in media 500 euro, stai perdendo 2.000-2.500 euro al mese. In un anno, fa 24.000-30.000 euro. Per un investimento in ottimizzazione che può costare qualche migliaio di euro una tantum.

WordPress vs Siti Statici: La Differenza nelle Performance

Parlo per esperienza diretta: la tecnologia con cui costruisci il sito ha un impatto enorme sui Core Web Vitals. E qui devo essere onesto, anche se non farà piacere a chi ha appena pagato 3.000 euro per un sito WordPress.

Il problema di WordPress

WordPress alimenta circa il 43% dei siti web al mondo. Ma essere popolare non significa essere veloce. Il problema è strutturale:

Ogni pagina viene generata al volo: quando un utente visita il sito, il server deve eseguire PHP, interrogare il database MySQL, assemblare la pagina e inviarla. Questo processo richiede 200-800ms prima ancora di iniziare a inviare i dati
I temi sono sovraccarichi: la maggior parte dei temi WordPress carica 15-30 file CSS e JavaScript anche su pagine che ne usano una frazione. Il tema “multipurpose” da 59 dollari include codice per slider, lightbox, animazioni, parallax — che tu li usi o no
I plugin si accumulano: il sito medio WordPress ha 20-30 plugin installati. Ognuno aggiunge CSS, JavaScript, query al database. Plugin di sicurezza, SEO, caching, form, analytics, backup, social sharing — e improvvisamente la pagina pesa 3MB e carica 80 risorse
Il caching è un cerotto: plugin come WP Rocket, W3 Total Cache o LiteSpeed Cache migliorano le cose, ma stanno curando i sintomi, non la causa. Un sito WordPress ben ottimizzato con caching aggressivo arriva dove un sito statico parte di default

Perché io uso Astro per i miei clienti

Per i siti web che costruisco, uso Astro — un framework moderno che genera pagine HTML statiche. La differenza è radicale:

Zero JavaScript di default: Astro invia al browser solo HTML e CSS. Nessun framework JavaScript in esecuzione, nessuna idratazione, nessun bundle da scaricare. Se una pagina non ha bisogno di interattività, non viene inviato un solo byte di JavaScript
Pagine pre-renderizzate: il HTML viene generato al momento del build, non a ogni visita. Il server deve solo inviare un file statico — tempo di risposta: 5-20ms invece di 200-800ms
Island Architecture: quando serve interattività (un form, un carousel, un componente dinamico), Astro carica JavaScript solo per quel singolo componente, non per l’intera pagina
Risultati concreti: i siti che costruisco con Astro ottengono regolarmente punteggi di 95-100 su PageSpeed Insights, con LCP sotto il secondo, INP praticamente nullo e CLS a zero

Confronto diretto

Aspetto	WordPress (tipico)	Astro (statico)
LCP	2,5 - 6,0 secondi	0,5 - 1,2 secondi
INP	150 - 500 ms	0 - 50 ms
CLS	0,05 - 0,35	0 - 0,02
PageSpeed Score	30 - 70	90 - 100
Peso pagina	1,5 - 4 MB	50 - 300 KB
Richieste HTTP	40 - 100+	5 - 15
TTFB	200 - 800 ms	10 - 50 ms

Questo non significa che WordPress sia inutilizzabile. Per progetti che richiedono un CMS con editing continuo da parte del cliente, gestione multi-autore o funzionalità e-commerce complesse, WordPress (o WooCommerce) resta una scelta valida. Ma se le performance contano — e per la SEO contano sempre — i siti statici partono con un vantaggio strutturale enorme.

Fattori Server-Side: L’Infrastruttura Conta

Puoi ottimizzare il codice quanto vuoi, ma se il server è lento tutto il resto è inutile. L’infrastruttura su cui gira il tuo sito è il primo collo di bottiglia.

Hosting condiviso vs VPS

La maggior parte dei siti delle PMI italiane gira su hosting condiviso da 3-5 euro al mese. In pratica, il tuo sito condivide il server con centinaia di altri siti. Se uno di quei siti ha un picco di traffico, il tuo rallenta. Se il server è sovraccarico alle 10 di mattina (quando tutti navigano), il tuo TTFB schizza a 1-2 secondi.

Un VPS (Virtual Private Server) ti dà risorse dedicate: CPU, RAM e disco assegnati esclusivamente al tuo sito. Il TTFB scende a 20-50ms, la stabilità è garantita e hai il controllo completo sulla configurazione.

Per i siti dei miei clienti, uso VPS con Caddy come web server. Caddy è moderno, gestisce automaticamente i certificati SSL (HTTPS), supporta HTTP/2 e HTTP/3, la compressione gzip/brotli e le regole di caching — tutto senza configurazione manuale complessa.

CDN: servire i contenuti da vicino

Un CDN (Content Delivery Network) replica i file statici del tuo sito su server distribuiti geograficamente. Quando un utente a Milano visita il tuo sito, i file vengono serviti dal nodo CDN più vicino a Milano, non dal server a Falkenstein o Norimberga. Risultato: latenza ridotta di 50-100ms su ogni risorsa.

Per un sito che si rivolge a clienti locali a Perugia e in Umbria, un CDN con nodi europei è sufficiente. Per siti con traffico internazionale, diventa indispensabile.

Compressione e protocolli moderni

Brotli > Gzip: la compressione Brotli riduce la dimensione dei file del 15-20% in più rispetto a Gzip. Caddy e la maggior parte dei CDN moderni lo supportano nativamente
HTTP/2 e HTTP/3: permettono di scaricare più file in parallelo su una singola connessione, eliminando il collo di bottiglia del “6 connessioni massime” di HTTP/1.1
Early Hints (103): il server invia suggerimenti al browser su quali risorse precaricare prima ancora di aver finito di generare la risposta. Può ridurre l’LCP di 100-500ms

Performance Mobile: La Priorità Assoluta

Oltre il 65% delle ricerche Google a Perugia avviene da smartphone. E Google usa il mobile-first indexing dal 2021: la versione mobile del tuo sito è quella che viene indicizzata e valutata per il ranking. Non la versione desktop.

Questo significa che i Core Web Vitals vengono misurati principalmente sull’esperienza mobile. E su mobile le condizioni sono più difficili:

CPU meno potente: uno smartphone medio ha 1/4 della potenza di calcolo di un laptop. JavaScript che gira in 100ms su desktop ne richiede 400ms su mobile
Connessioni instabili: il 4G medio in Italia ha latenza di 40-60ms e banda variabile. In zone meno coperte (pensa alle zone industriali fuori Perugia), le condizioni peggiorano
Schermi piccoli ma esigenti: le immagini devono essere più leggere ma comunque nitide su display ad alta densità (Retina/HiDPI)

Checklist performance mobile

Testa sempre su dispositivi reali, non solo su simulatori — Chrome DevTools con throttling è un buon punto di partenza, ma non sostituisce un test su un telefono Android di fascia media
Usa immagini responsive con srcset e sizes per servire dimensioni appropriate al dispositivo
Minimizza il JavaScript: ogni KB di JavaScript costa più su mobile che su desktop, perché deve essere scaricato, parsato, compilato ed eseguito su hardware meno potente
Assicurati che i touch target siano almeno 48x48 pixel per evitare clic accidentali (che peggiorano anche il CLS percepito)
Verifica che i font siano leggibili senza zoom: se l’utente deve pinch-to-zoom, il sito non è ottimizzato per mobile

Guida Pratica: Ottimizzazione Step-by-Step

Se hai letto fin qui e vuoi passare all’azione, ecco un piano di ottimizzazione ordinato per impatto.

Step 1: Misura lo stato attuale

Prima di toccare qualsiasi cosa, analizza la situazione:

Apri PageSpeed Insights e testa la homepage e le 3-5 pagine più importanti del tuo sito (la pagina servizi, la pagina contatti, i post del blog più visitati)
In Search Console, controlla il report Core Web Vitals per vedere quante pagine hanno problemi
Annota i punteggi — ti serviranno come baseline per misurare i miglioramenti

Step 2: Ottimizza le immagini (impatto immediato)

Questa è quasi sempre la vittoria più facile e grande. In molti siti, le immagini rappresentano il 60-80% del peso totale della pagina.

Converti tutte le immagini in WebP (o AVIF per i browser che lo supportano)
Ridimensiona le immagini alla dimensione effettiva di visualizzazione
Implementa lazy loading per tutto ciò che sta sotto la piega
Usa fetchpriority="high" e loading="eager" per l’immagine LCP

Step 3: Riduci JavaScript e CSS

Rimuovi plugin, librerie e script non utilizzati
Carica JavaScript con defer o async
Inline il CSS critico above-the-fold
Usa il code splitting per caricare solo il JavaScript necessario per ogni pagina

Step 4: Migliora il server

Se sei su hosting condiviso e il TTFB supera i 200ms, valuta un upgrade a VPS
Implementa caching del browser con header Cache-Control appropriati
Attiva la compressione Brotli o Gzip
Valuta un CDN se il tuo traffico è distribuito geograficamente

Step 5: Risolvi il CLS

Aggiungi width e height a tutte le immagini e i video
Riserva spazio per annunci e contenuti dinamici
Precarica i web font per evitare il flash of unstyled text
Non inserire mai elementi sopra il contenuto già visibile

Step 6: Monitora nel tempo

I Core Web Vitals non sono un “sistema e dimentica”. Le performance possono degradare con l’aggiunta di nuovi contenuti, nuovi script o cambiamenti nel comportamento degli utenti. Controlla Search Console almeno una volta al mese e ri-testa con PageSpeed Insights dopo ogni modifica significativa.

Come i Core Web Vitals si Integrano nella Strategia SEO

I Core Web Vitals sono un pezzo del puzzle, non il puzzle intero. Una strategia SEO completa include contenuti di qualità, autorevolezza, link building, SEO locale e ottimizzazione tecnica. I Core Web Vitals rientrano nell’ottimizzazione tecnica, ma influenzano anche tutti gli altri aspetti.

Un sito veloce e stabile:

Invita gli utenti a restare più a lungo (migliora il dwell time)
Facilita il crawling di Google (i bot possono scansionare più pagine nello stesso tempo)
Migliora i tassi di conversione (più contatti, più vendite)
Rafforza la percezione del brand (un sito veloce comunica professionalità)

Se vuoi approfondire come funziona la SEO nel suo complesso, ho scritto una guida completa alla SEO che copre tutti gli aspetti.

Domande Frequenti

Un sito WordPress può avere buoni Core Web Vitals?

Sì, ma richiede un lavoro di ottimizzazione significativo. Serve un hosting performante (VPS, non condiviso), un tema leggero e minimalista (non un tema “multipurpose” da 60 dollari), massimo 10-15 plugin essenziali, un plugin di caching ben configurato e immagini ottimizzate. In pratica, devi rimuovere tutto il superfluo — che è esattamente il contrario di come la maggior parte delle persone usa WordPress. Ci si riesce, ma il rapporto sforzo/risultato è sfavorevole rispetto a un sito statico che parte già ottimizzato.

Quanto tempo serve per migliorare i Core Web Vitals?

Dipende dalla gravità dei problemi. Ottimizzazioni base come la compressione delle immagini e l’attivazione del caching si completano in poche ore e danno risultati immediati. Problemi strutturali (tema pesante, troppo JavaScript, hosting inadeguato) possono richiedere giorni o settimane di lavoro, e in alcuni casi un rifacimento parziale del sito. Una volta apportate le modifiche, Google impiega 28 giorni per aggiornare i dati CrUX nel report di Search Console.

I Core Web Vitals influenzano davvero il posizionamento su Google?

Sì, Google lo ha confermato ufficialmente con il Page Experience Update. Non sono il fattore principale — il contenuto e i backlink restano più importanti — ma funzionano come fattore di spareggio. Per keyword competitive dove 10 siti si contendono le prime 5 posizioni, Core Web Vitals eccellenti possono fare la differenza tra stare in prima o in seconda pagina. John Mueller di Google ha detto chiaramente: “Se hai una pagina con ottimi contenuti ma Core Web Vitals scarsi, e un concorrente ha contenuti simili ma Core Web Vitals buoni, il concorrente verrà preferito.”

Quanto costa far ottimizzare i Core Web Vitals del mio sito?

Se parliamo di ottimizzazione su un sito esistente, la forbice va da 500 a 3.000 euro a seconda della complessità. Interventi leggeri (compressione immagini, configurazione caching, rimozione script inutili) costano meno. Interventi pesanti (cambio hosting, riscrittura del tema, refactoring del JavaScript) costano di più. Se il sito ha problemi strutturali gravi, a volte il rifacimento completo è più conveniente dell’ottimizzazione — soprattutto se il sito ha anche altri problemi di usabilità o design datato. Contattami per un preventivo specifico.

Come posso monitorare i Core Web Vitals gratuitamente?

Google offre tutti gli strumenti necessari a costo zero. PageSpeed Insights per l’analisi pagina per pagina, Search Console per la visione d’insieme e il monitoraggio nel tempo, Chrome DevTools per la diagnostica tecnica approfondita, e la Web Vitals Extension per il monitoraggio in tempo reale durante la navigazione. Se vuoi automatizzare il monitoraggio, puoi usare l’API di PageSpeed Insights per creare report periodici o integrare la libreria JavaScript web-vitals nel tuo sito per raccogliere dati in tempo reale dai tuoi utenti.

Passa all’Azione

I Core Web Vitals non sono un esercizio accademico. Sono la traduzione tecnica di ciò che i tuoi clienti percepiscono ogni giorno: un sito che si carica velocemente, risponde ai clic senza ritardo e non salta mentre lo navigano. Migliorarli significa migliorare il posizionamento su Google, ridurre il tasso di abbandono e aumentare le conversioni.

Se il tuo sito ha punteggi bassi su PageSpeed Insights, ogni giorno che passa stai perdendo visitatori e potenziali clienti. La buona notizia: la maggior parte dei problemi si risolve con interventi mirati e misurabili.

Richiedi un’analisi gratuita dei Core Web Vitals del tuo sito — ti mostro esattamente dove stai perdendo performance, cosa migliorare per primo e quanto impatto avrà sul tuo posizionamento e sulle tue conversioni.