Sito lento, ranking in calo: WPO e Core Web Vitals che contano nel 2026

Il 53% dei siti è ancora troppo lento per Google

A marzo 2026 solo il 47% dei siti web supera le soglie “buone” dei Core Web Vitals stabilite da Google. Il restante 53% lavora in svantaggio competitivo diretto: traffico organico compresso, conversioni ridotte, posizioni SERP sistematicamente più basse rispetto a competitor con siti tecnicamente migliori.

Il dato non è teorico. Google usa i segnali di page experience come fattore di ranking dal 2021 e continua ad aggiornare i benchmark. Chi gestisce una PMI italiana, un negozio fisico con vetrina digitale o uno shop online, ha tutto l’interesse a capire dove perde punti e come recuperarli.

Core Web Vitals nel 2026: cosa misura Google

I tre parametri di riferimento sono LCP, INP e CLS. Dal 12 marzo 2024, INP ha sostituito FID come metrica di reattività nei Core Web Vitals: chi ha ancora documenti tecnici che parlano di First Input Delay lavora su dati superati.

LCP (Largest Contentful Paint) misura quanto impiega il contenuto principale della pagina a renderizzarsi: immagine hero, titolo H1, blocco testo. La soglia buona è sotto i 2,5 secondi. È il collo di bottiglia più comune: secondo i dati di corewebvitals.io, solo il 62% dei siti supera LCP, contro l’81% che supera CLS e il 77% che supera INP. Il problema principale dei siti lenti non è la stabilità visiva né la reattività, ma il tempo al primo contenuto percepibile.

INP (Interaction to Next Paint) misura la latenza tra un’interazione utente (click, tap, pressione tasto) e la risposta visiva del browser. Soglia buona: sotto 200 millisecondi. Il problema INP nasce quasi sempre da JavaScript pesante nel thread principale: script di terze parti, analytics mal configurati, widget chat, pixel pubblicitari accumulati nel tempo senza pulizia.

CLS (Cumulative Layout Shift) misura la stabilità visiva: quante volte gli elementi si spostano durante il caricamento. Un banner che appare dopo 2 secondi e sposta tutto il testo verso il basso genera CLS alto. La soglia buona è sotto 0,1. Si risolve con dimensioni esplicite su immagini e iframe, e riservando spazio per font e annunci prima che si carichino.

Le tecniche WPO che incidono davvero

La Web Performance Optimization non è una checklist da spuntare una volta. È un processo iterativo, ma esistono interventi ad alto impatto che producono l’80% del risultato.

TTFB e qualità del server: il Time to First Byte, cioè il tempo che il server impiega a rispondere alla prima richiesta, è il fattore che precede tutto il resto. Un TTFB sopra 600 ms vanifica qualsiasi ottimizzazione front-end. La soluzione diretta è passare a un server VPS dedicato con PHP 8.x, OPcache attivo e database ottimizzato: su hosting condivisi economici il TTFB raramente scende sotto 800-1200 ms nelle ore di picco, specialmente sui datacenter condivisi con migliaia di altri siti.

Ottimizzazione immagini: il formato WebP (o AVIF per browser moderni) riduce il peso delle immagini del 25-35% rispetto a JPEG a parità di qualità percepita. L’errore più comune è caricare immagini da 2000x1500 pixel su slot da 400x300: il browser le scarica comunque per intero. L’attributo srcset risolve questo, servendo dimensioni appropriate per ogni viewport. Su WordPress i plugin come ShortPixel o Imagify automatizzano la conversione; sui siti costruiti con tecnologie come Astro o Next.js il componente <Image> gestisce tutto questo nativamente a livello di build.

Lazy loading selettivo: le immagini above-the-fold non devono mai avere loading="lazy". Un errore diffuso su temi WordPress preconfezionati è applicare il lazy loading indiscriminatamente, ritardando proprio l’immagine hero che determina il punteggio LCP. Le immagini under-the-fold invece devono averlo, per non bloccare il rendering iniziale.

Caching e CDN: un sistema di caching a più livelli (object cache con Redis o Memcached, caching delle pagine, header di cache del browser) riduce il carico del server e abbassa il TTFB sui contenuti già generati. Cloudflare nel livello gratuito copre già buona parte del traffico nazionale: porta gli asset statici fisicamente più vicini all’utente, con datacenter a Milano che servono la penisola in decine di millisecondi invece di centinaia.

Pulizia del JavaScript: ogni pixel e ogni script di analytics aggiunto nel tempo ha un costo in INP. Vanno caricati in modo asincrono (async o defer) e, quando possibile, rimandati fino a che non servono davvero. Google Tag Manager aiuta a centralizzare, ma diventa parte del problema se contiene 15 tag attivi senza revisione periodica.

Font di sistema o preload esplicito: i web font personalizzati sono una fonte silenziosa di CLS e LCP degradato. La strategia più efficace è font-display: swap combinato con <link rel="preload"> per il font principale. Per siti dove la brand identity non dipende dal font, la stack di sistema (system-ui, -apple-system, Segoe UI) azzera completamente il problema.

I numeri che giustificano l’intervento

La velocità non è una questione estetica per tecnici: incide direttamente su fatturato e visibilità organica.

Secondo i dati raccolti da Riccardo Galli, un ritardo di un secondo nel caricamento riduce le conversioni del 4,4%. Per un e-commerce che genera 10.000 euro di ordini mensili, un sito con LCP a 4 secondi invece di 2 può tradursi in diverse centinaia di euro di mancato fatturato mensile, ogni mese. La forbice si allarga al crescere del volume di traffico.

Gli utenti abbandonano un sito che supera i 3 secondi di caricamento: lo documentava già Google nel 2022, e il comportamento mobile ha reso la soglia ancora più severa. Su smartphone, con connessioni variabili, 3 secondi è il limite oltre il quale la maggior parte degli utenti torna al risultato precedente.

Il problema si moltiplica per chi investe in pubblicità: un budget su Google Ads portato su landing page lente produce Quality Score più basso, CPC più alto e conversioni ridotte. Ogni euro speso in ads su una pagina con LCP a 5 secondi vale meno della metà rispetto alla stessa pagina ottimizzata a 1,5 secondi.

Da dove iniziare: ordine di priorità pratico

Partire da PageSpeed Insights con la URL della homepage e delle principali landing page è il primo passo operativo. Il tool restituisce i dati reali degli utenti Chrome (CrUX data) separati dai dati di laboratorio: per la SEO contano i dati reali, non il punteggio di laboratorio che molti plugin mostrano in verde.

Ordine di intervento in base all’impatto atteso:

1. TTFB prima di tutto: se supera i 600 ms, nessuna ottimizzazione front-end recupera abbastanza. Cambiare hosting o passare a VPS è il primo intervento, non l’ultimo.
2. LCP: identificare quale elemento attiva LCP con Chrome DevTools o la Web Vitals extension, poi ottimizzare quell’elemento specifico. Di norma è un’immagine hero: formato moderno, dimensioni corrette, preload esplicito.
3. CLS: aggiungere dimensioni esplicite a ogni immagine e iframe nel codice, gestire i font con font-display: swap.
4. INP: audit degli script di terze parti con il tab Performance di DevTools. Rimuovere o differire tutto ciò che non è strettamente necessario al primo caricamento.
5. Cache e CDN: configurare Cloudflare e attivare la cache lato server per le pagine statiche.

Per siti WordPress con molti plugin, WP Rocket o Perfmatters coprono buona parte di questi interventi con configurazione guidata. Per siti su framework moderni come Astro o Next.js, molte ottimizzazioni sono già nell’architettura del framework e richiedono solo la corretta impostazione del deploy e dell’ambiente di hosting.

Un dettaglio spesso trascurato per attività umbre: se il pubblico target è prevalentemente locale (Perugia, Foligno, Spoleto, Terni), un server in Italia con bassa latenza verso le reti TIM e Vodafone regionali fa differenza sui dati CrUX reali rispetto a server in Nord Europa o USA.

Il punto critico da non perdere

Il CrUX si aggiorna ogni 28 giorni: le modifiche alle performance apportate oggi rifletteranno nei Core Web Vitals visibili in Search Console tra circa un mese. Chi ottimizza il sito adesso vedrà il segnale aggiornato a giugno 2026. Aspettare ancora un mese significa perdere un altro ciclo di aggiornamento.