Sito web per PMI italiane: perché Core Web Vitals decide il tuo SEO

Se gestisci una piccola o media impresa in Italia e il tuo sito si apre lento, Google lo sa, i tuoi clienti lo sentono, e tu lo paghi in due posti: meno traffico organico e meno conversioni.

Negli ultimi dodici mesi Google ha aggiornato i propri algoritmi sposando sempre di più un segnale concreto chiamato Core Web Vitals. Non sono poesia da sviluppatore: sono tre numeri che raccontano, con brutalità, quanto è piacevole navigare il tuo sito.

Quali sono le metriche Core Web Vitals che contano davvero?

Le metriche Core Web Vitals che Google usa per giudicare un sito sono tre: LCP (tempo di apparizione dell'elemento principale, soglia buona sotto 2,5 secondi), CLS (instabilità visiva durante il caricamento, soglia sotto 0,1) e INP (reattività al click, soglia sotto 200ms). Se anche una sola sta in rosso su mobile, il ranking organico ne paga il prezzo.

LCP, Largest Contentful Paint

Misura il tempo che passa tra quando l'utente clicca sul tuo link e quando l'elemento più grande della pagina (di solito l'immagine hero o un titolone) diventa visibile.

• Buono: sotto 2,5 secondi
• Da migliorare: tra 2,5 e 4 secondi
• Scarso: sopra 4 secondi

Per una PMI italiana con traffico da mobile (la maggior parte), 4 secondi significa perdere metà degli utenti prima ancora del primo click.

CLS, Cumulative Layout Shift

Quando apri una pagina e i contenuti "saltano" perché un'immagine si carica in ritardo, quella è CLS. Misura quanto la pagina si sposta sotto gli occhi dell'utente mentre carica.

• Buono: sotto 0,1
• Scarso: sopra 0,25

Un CLS alto non è solo fastidioso: Google lo legge come "sito fatto male" e ti penalizza.

INP, Interaction to Next Paint

Ha sostituito FID nel 2024. Misura la reattività del sito: quanto tempo passa da quando clicchi un bottone a quando succede qualcosa di visibile.

• Buono: sotto 200ms
• Scarso: sopra 500ms

Le soglie Google e le soglie operative di Webica Labs

Google definisce tre fasce per ogni metrica: buono, da migliorare, scarso. Nelle soglie "buono" un sito è già a posto dal punto di vista del ranking. Ma noi in Webica Labs usiamo target interni più stringenti, perché costruire siti che stanno appena sopra la soglia minima non ci soddisfa, e perché un margine di sicurezza protegge dalle fluttuazioni normali dei test.

La colonna "Soglia Webica" è il nostro target di consegna. Se consegnamo un sito che sta dentro quelle righe, sappiamo che c'è margine rispetto ai minimi Google e che la manutenzione ordinaria non lo farà scivolare nel rosso.

Come migliorare le performance del sito senza essere uno sviluppatore?

Per migliorare le performance del sito senza scrivere codice basta sapere dove guardare e cosa pretendere dal fornitore: apri PageSpeed Insights, inserisci l'URL, guarda solo la colonna Mobile, e se vedi pallini rossi su LCP, CLS o INP stampa il report e chiedi una roadmap di rientro nel verde. Se il fornitore liquida con "è normale", stai parlando con la persona sbagliata.

Non serve essere tecnici per partire. Serve sapere dove guardare e cosa chiedere al fornitore.

1. Apri PageSpeed Insights e inserisci il tuo URL.
2. Guarda la colonna Mobile (non Desktop, i clienti arrivano dal telefono).
3. Se hai un pallino rosso su LCP, CLS o INP, hai un problema concreto.
4. Stampa il report e mandalo a chi ti ha fatto il sito. Chiedi una roadmap per portare tutto in verde.

Se il fornitore risponde "è normale" o "non si può fare meglio", stai parlando con la persona sbagliata. Un sito moderno, anche su WordPress, può stare nei verdi con un lavoro serio.

Quali interventi migliorano davvero i Core Web Vitals di un sito?

Gli interventi che spostano davvero i Core Web Vitals di un sito PMI sono quattro e portano il 90% del risultato: immagini convertite in AVIF o WebP e dimensionate correttamente, font self-hosted con font-display: swap e preload, JavaScript non critico differito al post first-paint, e hosting decente al posto di shared hosting da due euro al mese con duemila siti sulla stessa macchina.

• Immagini compresse in formato AVIF o WebP, dimensionate correttamente per il placement (niente immagini da 3000px su card da 400px).
• Font pre-caricati con font-display: swap e self-hosted dove possibile.
• JavaScript differito, tutto quello che non serve al first paint va caricato dopo.
• Hosting decente, non 2 euro al mese con 2000 siti condivisi sulla stessa macchina.

La sequenza giusta è questa: prima misuri (PageSpeed Insights + Google Search Console, sezione "Esperienza sulla pagina"), poi identifichi il collo di bottiglia principale, poi intervieni in ordine di impatto. Non si parte mai da "rifacciamo tutto" — si parte dal numero peggiore e si lavora verso il basso.

Caso reale: come RD Assicurazioni è passata dal rosso verso il verde

RD Assicurazioni è un'agenzia assicurativa monomandataria con sede a Roma. Il consulente Riccardo Angalli lavora principalmente con aziende, PMI e partite IVA, in un settore dove la concorrenza digitale è forte: comparatori come Prima.it e Segugio.it dominano il traffico informazionale, e per un agente locale guadagnare visibilità organica significa avere un sito tecnicamente inattaccabile.

Quando abbiamo analizzato rdassicurazioni.com a inizio maggio 2026, il quadro CWV era questo: un sito già ben strutturato sul piano semantico (preload dei font critici, fetchpriority="high" sull'immagine hero, srcset responsive già implementato), ma con un'immagine LCP servita in formato JPG da 158 KB sul breakpoint largo. Su rete mobile simulata (throttling 4G slow, la condizione standard di Lighthouse), l'LCP arrivava a 7,8 secondi. Gli altri segnali erano già in ordine: CLS quasi zero, Thread principale libero.

L'intervento è stato chirurgico: conversione dell'immagine hero di Riccardo Angalli da JPG a AVIF (avifenc -q 60), generazione di 9 varianti responsive (3 soggetti × 3 breakpoint), aggiornamento del tag <picture> con <source type="image/avif"> come prima scelta su 4 pagine pillar, e aggiornamento del <link rel="preload"> da WebP ad AVIF. Nessun refactoring strutturale, nessuna dipendenza nuova, nessun tocco al backend.

Il risultato in Lighthouse lab (throttling 4G slow, mobile, misurato post-deploy):

Due cose da leggere correttamente in questa tabella. Prima: CLS e TBT erano già nella fascia ottima prima dell'intervento, e lo sono rimasti, perché il sito era costruito bene. Seconda: LCP è migliorato di oltre il 35% ma è ancora nella fascia "scarso" secondo le soglie Google. Questo è onesto. Il punto di partenza aveva un problema strutturale, e un singolo sprint di ottimizzazione immagini sposta il numero in modo significativo senza risolverlo completamente.

Il passo successivo per rdassicurazioni.com è lavorare sul Critical Rendering Path: analisi CSS unused (il foglio main.css da 35 KB ha regole non utilizzate), eventuale inline del CSS above-fold, e verifica del rendering path su connessione reale piuttosto che simulata. Queste sono attività che rientrano in un ciclo di ottimizzazione continua, non in un singolo deploy.

La cosa importante, dal punto di vista dell'esperienza utente: il sito carica in modo stabile, senza salti visivi, con un thread principale libero che non blocca i click. L'esperienza su device fisico è sensibilmente migliore di quanto i numeri Lighthouse throttled suggeriscano, proprio perché la maggior parte delle ottimizzazioni strutturali era già al suo posto.

Quanto costa portare un sito ai Core Web Vitals verdi?

Dipende dal punto di partenza. Un sito nato bene, costruito con un framework moderno e su hosting adeguato, arriva spesso nei verdi senza intervento specifico. Per questi siti la performance è una proprietà emergente dell'architettura, non un obiettivo separato da inseguire.

La situazione cambia con i siti legacy: WordPress con venti plugin che si parlano addosso, temi comprati su Themeforest mai aggiornati, immagini caricate dall'amministratore a 4 MB perché "funziona comunque", hosting condiviso economico. In questi casi il lavoro di ottimizzazione è reale e richiede un audit tecnico prima di stimare quanto tempo serve.

Per i clienti Webica Labs, l'ottimizzazione delle performance non è un servizio a sé: fa parte dei pacchetti completi (Starter e Pro), dove costruire un sito che stia nei verdi dal primo giorno è parte del lavoro, non un extra. La manutenzione mensile inclusa serve precisamente a monitorare che i numeri non si degradino nel tempo, perché un plugin aggiornato male o un'immagine caricata senza compressione possono far scivolare un sito dal verde all'arancio in silenzio.

Se invece hai un sito esistente e vuoi capire dove sta il problema, il punto di partenza è un audit. Nel caso di RD Assicurazioni, cinque minuti su PageSpeed Insights e un'ora di lavoro tecnico hanno spostato LCP di 2,8 secondi. Non sempre è così lineare, ma spesso il collo di bottiglia principale è uno e uno solo, e identificarlo correttamente è il 70% del lavoro.

Per un confronto gratuito sui tuoi numeri attuali, prenota una chiamata su /contatti?fonte=blog-cwv: in 30 minuti guardiamo insieme PageSpeed Insights, identifichiamo il problema principale, e capisci se ha senso un intervento e di che portata.

Perché ne parliamo su Webica Labs

Perché lavoriamo ogni giorno con PMI italiane e vediamo due scenari:

• Siti nati benissimo che sono stati "ottimizzati" in modo sbagliato negli anni e ora zoppicano.
• Siti nati male che nessuno ha mai misurato, finché il giro annuale di SEO agency di turno non arriva a dire "bisogna rifarlo tutto". Quasi sempre la velocità rotta è solo uno dei sette errori tipici che vedo sui siti delle PMI.

Il punto è che non si rifà mai tutto. Si misura, si aggiusta quello che pesa di più, si iterano i numeri mese per mese. Quando invece un sito web per una PMI nasce bene, i Core Web Vitals sono verdi dal primo giorno, e restarci dentro è il core della nostra manutenzione mensile nei pacchetti Webica Labs.

Se vuoi capire se il tuo sito ha un problema reale o è "abbastanza ok", prenota una chiamata gratuita di 30 minuti. Guardiamo insieme i tuoi numeri e decidi tu cosa fare.