Abbiamo auditato 47 siti web di PMI italiane: ecco cosa abbiamo trovato

Ogni anno Google aggiorna i suoi algoritmi e la SEO community pubblica guide su come ottimizzare i Core Web Vitals. Ma pochi si fermano a misurare com’è la situazione reale — non i siti dei grandi brand, non quelli delle aziende tech, ma quelli delle PMI italiane che non hanno team dedicati alla performance web.

Noi lo abbiamo fatto.

Nel periodo tra settembre 2025 e aprile 2026 abbiamo condotto un audit completo dei Core Web Vitals su 47 siti web di clienti e prospect italiani. I dati che seguono sono reali, non stimati. Le aziende sono anonimizzate per settore, non per nome.

Quello che abbiamo trovato è al tempo stesso preoccupante e pieno di opportunità.

Chi sono i 47 siti analizzati

Distribuzione per settore:

• E-commerce: 16 siti
• Siti aziendali/istituzionali (B2B): 14 siti
• Servizi locali (ristoranti, saloni, studi professionali): 9 siti
• Siti informativi/blog: 5 siti
• Portali di settore: 3 siti

Distribuzione per CMS/tecnologia:

• WordPress (con vari builder e temi): 29 siti (61%)
• Shopify: 7 siti (15%)
• Siti custom (React, Next.js, altri): 6 siti (13%)
• Wix/Squarespace/altri page builder: 5 siti (11%)

Metodologia di misurazione: Abbiamo usato Google PageSpeed Insights, Chrome UX Report (dati reali di utenti Chrome), e Lighthouse in modalità mobile e desktop. I dati mobile sono il nostro punto di riferimento primario, perché è da mobile che arriva la maggior parte del traffico e dove Google valuta il sito per il ranking.

Il risultato principale: solo 11 siti su 47 passano tutti e tre i test su mobile

Questo è il dato che più ci ha colpito.

Percentuale di siti con performance BUONA (verde) su mobile:

Metrica	Siti con punteggio “buono”	Percentuale
LCP (Largest Contentful Paint < 2.5s)	18/47	38%
INP (Interaction to Next Paint < 200ms)	24/47	51%
CLS (Cumulative Layout Shift < 0.1)	31/47	66%
Tutti e tre insieme	11/47	23%

Solo il 23% dei siti analizzati supera tutti e tre i Core Web Vitals su mobile. Tre siti su quattro hanno almeno un problema che impatta il ranking SEO e l’esperienza utente. Se non hai chiaro cosa misurano queste tre metriche, parti da Core Web Vitals 2026: la metrica che Google usa per decidere chi appare primo.

Questo allineato con i dati globali (solo il 48% delle pagine mobile passa tutti i CWV secondo il Web Almanac 2025), ma la nostra analisi mostra che le PMI italiane sono sotto la media globale — probabilmente perché i grandi siti internazionali investono di più in performance engineering.

LCP: il problema più grave (e più ignorato)

Il Largest Contentful Paint misura quanto ci vuole prima che l’elemento principale della pagina sia visibile. Google lo considera “buono” se avviene entro 2.5 secondi. Dal marzo 2026, con l’ultimo core update, il peso di LCP nel ranking è aumentato ulteriormente.

LCP medio per tecnologia:

Tecnologia	LCP medio su mobile	% siti con LCP “buono”
Next.js / React custom	1.8s	83%
Shopify (tema ottimizzato)	2.3s	57%
WordPress (ottimizzato)	3.1s	28%
WordPress (standard)	5.4s	4%
Wix/Squarespace	4.2s	20%

Il dato più brutale: i siti WordPress “standard” — con temi premium popolari, molti plugin, nessuna ottimizzazione tecnica — hanno un LCP medio di 5.4 secondi. Il triplo del threshold di Google.

Attenzione: “WordPress” non è intrinsecamente lento. WordPress ottimizzato può superare i Core Web Vitals. Il problema è che il 90% dei siti WordPress che vediamo non è ottimizzato — usa temi pesanti, troppe richieste HTTP, immagini non compresse, hosting condiviso lento.

Le cause di LCP alto che abbiamo trovato più spesso:

1. Immagini hero non ottimizzate (presente nel 78% dei siti con LCP scarso) L’immagine principale della home o delle landing page era un JPEG da 3-8 MB, non convertito in WebP o AVIF, senza loading="eager" e fetchpriority="high". Correggere solo questo ha ridotto il LCP del 30-45% in diversi casi.

2. Hosting condiviso lento (presente nel 54% dei siti con LCP scarso) Il Time to First Byte (TTFB) — la velocità con cui il server risponde — era sopra i 600ms su molti siti. Un TTFB alto brucia il tempo disponibile prima ancora di iniziare a caricare la pagina. La soluzione: hosting con server in Italia o Europa, PHP aggiornato, CDN attiva.

3. Render-blocking JavaScript (presente nel 67% dei siti con LCP scarso) Script di tracking, chatbot, widget di terze parti caricati prima del contenuto principale. Il browser aspettava di scaricare ed eseguire questi script prima di renderizzare la pagina. La soluzione: defer/async su tutti gli script non critici, lazy loading per widget non visibili sopra la piega.

4. Google Fonts non ottimizzati (presente nel 71% dei siti WordPress) Font scaricati da Google Fonts in modo non ottimizzato bloccano il rendering. La soluzione: self-hosting dei font con font-display: swap, preload del font principale.

INP: la metrica nuova che molti non conoscono ancora

L’INP (Interaction to Next Paint) ha sostituito il FID (First Input Delay) a marzo 2024. Misura la reattività complessiva della pagina — quanto velocemente risponde quando l’utente fa clic, tocca lo schermo, o interagisce.

Il threshold è 200ms. Sopra i 500ms, Google considera la pagina “scarsa”.

INP medio per settore:

Settore	INP medio mobile	% siti con INP “buono”
E-commerce	310ms	37%
B2B istituzionale	190ms	64%
Servizi locali	220ms	56%
Blog/informativo	170ms	80%

I siti e-commerce hanno l’INP peggiore — e non è una coincidenza. I siti di vendita tendono ad avere più JavaScript interattivo: filtri prodotto, carrello dinamico, countdown, popup, chat widget. Tutta questa interattività ha un costo in termini di reattività.

I problemi che causano INP alto:

Il colpevole principale che abbiamo trovato è il long task JavaScript — pezzi di codice che occupano il thread principale del browser per più di 50ms, bloccando la risposta agli input dell’utente. Le cause più comuni:

• Plugin di analytics e tracking che fanno troppo sul main thread
• Librerie JavaScript pesanti caricate integralmente invece di parzialmente
• Animazioni CSS implementate con JavaScript invece di CSS nativo
• Lazy loading mal implementato che causa ricalcoli di layout all’interazione

CLS: il problema “invisibile” che frustra gli utenti

Il Cumulative Layout Shift misura quanto il contenuto della pagina si sposta visivamente durante il caricamento. Se hai mai cliccato su un link e nel momento in cui cliccavi il bottone si è spostato — facendoti cliccare su qualcos’altro — hai vissuto CLS alto.

Il threshold “buono” è 0.1. La buona notizia: il CLS è il Core Web Vital che più siti superano. La cattiva: quelli che non lo superano hanno spesso CLS molto alti.

Distribuzione CLS nei 47 siti:

• CLS < 0.1 (buono): 31 siti (66%)
• CLS 0.1–0.25 (da migliorare): 10 siti (21%)
• CLS > 0.25 (scarso): 6 siti (13%)

Le cause di CLS alto che abbiamo trovato:

1. Immagini senza dimensioni dichiarate (più frequente) Se un’immagine non ha width e height dichiarati in HTML, il browser non riserva lo spazio prima che l’immagine si carichi. Quando arriva, sposta tutto il contenuto sotto di lei. Fix: aggiungere sempre width e height agli elementi <img>.

2. Banner/cookie bar che si caricano dopo il contenuto Il GDPR ha reso obbligatori i cookie banner in Italia, ma molti sono implementati in modo che appaiano dopo che la pagina è già caricata, spostando il contenuto visibile. Fix: riservare spazio statico per il banner o usare position: fixed.

3. Font con fallback diverso dal definitivo Il browser usa prima un font system (Arial, Georgia, etc.) e poi sostituisce con il font definitivo quando si carica. Se le dimensioni sono diverse, il testo si sposta. Fix: font-display: swap con font-size aggiustato, o self-hosting del font con preload.

L’impatto SEO: quanto perdono i siti con CWV scarsi?

Questa è la domanda che interessa di più ai clienti. Abbiamo dati diretti su 9 siti per cui abbiamo migliorato i Core Web Vitals nell’ultimo anno.

Risultati medi post-ottimizzazione (a 3 mesi):

Metrica	Prima	Dopo	Variazione
Posizione media su Google	18.4	13.1	+28%
Traffico organico mensile	1.240	1.870	+51%
Bounce rate (mobile)	67%	48%	-19pp
Conversioni da traffico organico	23/mese	41/mese	+78%

Attenzione: questi sono dati medi su 9 siti, e la correlazione non implica causalità. Spesso l’ottimizzazione dei CWV viene fatta insieme ad altri interventi SEO (contenuti, link building). Ma il miglioramento della velocità da solo ha prodotto effetti misurabili su tutti i siti monitorati.

Il caso più evidente: un e-commerce di moda con LCP di 8.2 secondi su mobile. Dopo l’ottimizzazione (migrazione a Next.js, ottimizzazione immagini, CDN), LCP sceso a 1.9 secondi. Traffico organico +82% in 4 mesi. Tasso di conversione da mobile +34%. Perché il passaggio a Next.js cambi così tanto le carte lo spieghiamo in perché il tuo sito React non appare su Google.

Il caso WordPress: problema strutturale o gestionale?

Il 61% dei siti analizzati usa WordPress — che riflette più o meno la distribuzione reale nel mercato italiano delle PMI. E WordPress è chiaramente il CMS con le performance peggiori nei nostri dati.

Ma la domanda corretta non è “WordPress fa schifo?” — è “perché così tanti siti WordPress performano male?”.

La risposta, basata su quello che abbiamo trovato:

WordPress in sé è neutro. È lo strumento con cui viene usato che determina le performance. Quello che degrada le performance è quasi sempre:

• Temi premium pesanti (Avada, Divi, Elementor con troppi widget) che aggiungono 500KB-2MB di CSS e JavaScript non usato
• Plugin accumulati nel tempo senza mai fare pulizia — abbiamo visto siti con 40+ plugin attivi, molti inutilizzati
• Hosting condiviso economico con server lenti e senza cache server-side configurata
• Immagini mai compresse caricate direttamente dall’upload senza ottimizzazione

Un sito WordPress costruito con Gutenberg nativo (senza page builder pesanti), tema leggero, hosting VPS con LiteSpeed o Nginx, CDN attiva, e immagini ottimizzate può avere Core Web Vitals verdi. Ne abbiamo visti. Ma sono la minoranza.

Cosa conviene fare: fix progressivo o migrazione?

Questa è la decisione pratica che più clienti ci chiedono di aiutarli a prendere.

Fix progressivo (ottimizzare l’esistente) conviene quando:

• Il sito ha meno di 3 anni
• Il CMS è WordPress con tema ragionevolmente leggero
• LCP è tra 3-4 secondi (non catastrofico)
• Il cliente ha un budget limitato per il refactoring
• I contenuti e la struttura SEO esistente sono solidi

Costo tipico: €800-2.500 per un intervento completo di ottimizzazione CWV su un sito WordPress.

Migrazione a Next.js conviene quando:

• Il sito ha più di 5 anni e la base di codice è un patchwork
• LCP è sopra i 5 secondi su mobile
• Il cliente vuole integrare funzionalità avanzate (personalizzazione, A/B testing, integrazioni AI)
• Il traffico organico è importante per il business e ogni miglioramento ha valore economico diretto
• Il budget c’è

Costo tipico: €4.000-12.000 per una migrazione completa, a seconda della complessità. Come si costruisce oggi un sito veloce da zero lo abbiamo descritto in come vengono fatti i siti web nel 2026.

La regola pratica che usiamo: se l’audit mostra che il sito esistente può arrivare a LCP < 2.5s su mobile con interventi limitati (principalmente immagini e caching), vale la pena provare. Se il problema è strutturale (tema pesante, architettura client-side, hosting non adeguato), la migrazione paga nel lungo periodo.

La checklist che usiamo prima di ogni audit

Quando prendiamo in carico un nuovo sito, questi sono i 10 check che facciamo nelle prime due ore:

1. TTFB (Time to First Byte) — ideale sotto 200ms. Se sopra 600ms, problema di hosting o server.
2. LCP element — cosa è? Immagine? Titolo H1? Background CSS? Ogni tipo ha fix diversi.
3. Immagini above the fold — formato (WebP/AVIF?), dimensioni, lazy loading disattivato per le prime.
4. Font loading — self-hosted o Google Fonts? font-display settato?
5. JavaScript bundle size — quanti KB di JS vengono scaricati? Dove sono i long task?
6. Plugin WordPress — quanti sono? Quanti sono attivi? Quali aggiungono script in front-end?
7. CDN — è attiva? I file statici vengono serviti da edge?
8. Immagini responsive — srcset configurato? Vengono servite dimensioni corrette per mobile?
9. CLS score — ci sono elementi senza dimensioni dichiarate? Banner o widget dinamici?
10. Hosting — condiviso, VPS, o cloud? Dove sono i server fisicamente?

Questa checklist permette di identificare il 90% dei problemi in meno di due ore e prioritizzare gli interventi per impatto.

Conclusione: tre anni per recuperare il ritardo

Se sei una PMI con un sito WordPress standard non ottimizzato, la buona notizia è che la maggior parte dei tuoi competitor è nella stessa situazione. Chi interviene adesso ha un vantaggio crescente — ogni mese che passa i siti più veloci raccolgono più traffico organico.

La cattiva notizia: il problema non si risolve installando un plugin. Richiede un approccio tecnico metodico — che può essere fatto in progressione, ma richiede competenza.

I dati dei nostri 47 clienti mostrano che un sito con Core Web Vitals verdi genera in media il 51% di traffico organico in più rispetto a uno con CWV rossi nello stesso settore e con la stessa autorità SEO. Quella differenza si accumula mese dopo mese.