Migliorare la velocità del sito: capire e ottimizzare i Core Web Vitals

Per migliorare la velocità del suo sito, misuri prima con PageSpeed Insights dove sono i problemi e poi intervenga sui freni maggiori: immagini troppo grandi, cache assente, font e script bloccanti e una risposta lenta del server. Google valuta l’esperienza utente con tre indicatori, i Core Web Vitals. Questo articolo spiega cosa significano, come misurarli correttamente e quali interventi rendono di più, con indicazioni specifiche per WordPress.

I tre Core Web Vitals e le loro soglie

Le soglie sono quelle di Google (web.dev, stato: ottobre 2026). Una pagina le rispetta quando almeno il 75 per cento delle visualizzazioni è nella fascia verde, separatamente per dispositivi mobili e desktop. Nel marzo 2024 l’INP ha sostituito il precedente indicatore FID (First Input Delay).

Vale la pena guardare anche il Time to First Byte (TTFB), cioè il tempo fino alla prima risposta del server. Google considera buono un valore di 0,8 secondi o meno. Il TTFB non è un Core Web Vital, ma incide direttamente sull’LCP: ciò che il server consegna tardi, il browser non può mostrarlo presto.

Misurare bene: dati di laboratorio e dati sul campo

• PageSpeed Insights (pagespeed.web.dev) mostra in alto i dati sul campo di utenti reali di Chrome degli ultimi 28 giorni, se ce ne sono abbastanza, e sotto un test di laboratorio con Lighthouse e suggerimenti concreti.
• Il rapporto «Core Web Vitals» di Google Search Console riassume i dati sul campo per gruppi di pagine simili e indica quali URL hanno risultati scarsi. Dopo una correzione può avviare lì una convalida.
• Chrome DevTools, con Lighthouse e la scheda Performance, sono utili per i test mentre lavora al sito.

Per la valutazione di Google contano i dati sul campo, non il punteggio del test di laboratorio. I siti più piccoli hanno spesso troppe poche visite per avere dati sul campo; allora il test di laboratorio è il miglior riferimento. Provi sempre anche la versione mobile, che di solito è più lenta di quella desktop.

Consiglio: Misuri diverse pagine tipiche, non solo la pagina iniziale: ad esempio una pagina prodotto o servizio, un articolo del blog e il modulo di contatto. Poi cambi una sola cosa alla volta e misuri di nuovo.

Immagini: la causa più frequente di un LCP scarso

In molte pagine l’elemento LCP è un’immagine grande, per esempio un’immagine di copertina o uno slider. Qui questi interventi sono i più efficaci:

• Fornire le immagini nella dimensione effettivamente visualizzata e offrire con srcset dimensioni diverse per smartphone e desktop.
• Usare formati moderni: WebP o AVIF sono di solito molto più leggeri di JPEG o PNG a parità di qualità.
• Non ritardare il caricamento dell’immagine principale nell’area visibile (niente lazy loading) e darle priorità con fetchpriority="high"; le immagini più in basso, invece, con lazy loading.
• Indicare larghezza e altezza di ogni immagine, così il browser riserva lo spazio. Questo evita spostamenti e migliora il CLS.
• Rinunciare agli slider in testata se basta un’unica immagine.

Cache e risposta del server

Ogni pagina che il server non deve prima comporre arriva più in fretta ai visitatori. Tre livelli sono importanti:

• Cache delle pagine: memorizza le pagine HTML già pronte. Sui server LiteSpeed se ne occupa LSCache direttamente nel server web.
• Cache del browser: con le giuste intestazioni di cache il browser non riscarica immagini, CSS e JavaScript alla visita successiva.
• Cache degli oggetti, ad esempio Redis: accelera pagine dinamiche come il carrello o l’area riservata, che non si possono memorizzare come pagina intera.

Se il TTFB resta alto nonostante la cache, spesso la causa è il server: una versione di PHP superata, troppe poche risorse o un account sovraccarico. In quel caso aiutano una versione di PHP aggiornata o un hosting con risorse assegnate.

Font e script

Web font

• Ospitare i font sul proprio sito invece di caricarli da server esterni. Si risparmiano connessioni ed è anche meglio per la protezione dei dati.
• Caricare solo gli stili necessari, ad esempio regular e bold, nel formato WOFF2.
• Con font-display: swap il browser mostra subito il testo con un font sostitutivo.
• Precaricare il font più importante con rel="preload".

JavaScript e servizi di terzi

L’INP soffre soprattutto di molto JavaScript che blocca il browser. I responsabili tipici sono widget di chat, script di tracciamento e pubblicità, banner dei cookie con molti servizi integrati, contenuti incorporati dai social media e page builder pesanti.

• Eliminare gli script non necessari invece di limitarsi a ottimizzarli.
• Caricare gli script con defer o async, così non bloccano la costruzione della pagina.
• Caricare video e mappe solo dopo un clic: prima un’immagine di anteprima, poi l’incorporamento.
• Ridurre e unire CSS e JavaScript, ma provare il sito dopo ogni modifica.

Evitare gli spostamenti del layout (CLS)

Poche cose sono più fastidiose di un pulsante che si sposta proprio mentre lo si tocca, perché più in alto si sta ancora caricando qualcosa. Il CLS misura proprio questi spostamenti. Le cause più frequenti e i rimedi:

• Immagini, video e iframe senza dimensioni: indicare larghezza e altezza o un rapporto fisso (aspect-ratio).
• Elementi caricati in seguito, come banner dei cookie, barre di avviso o spazi pubblicitari: mostrarli sopra il contenuto o riservare lo spazio in anticipo.
• Web font che cambiano la larghezza del testo quando sostituiscono il font di riserva: scegliere un font di riserva con proporzioni simili.
• Contenuti inseriti con JavaScript sopra l’area visibile: inserirli solo dopo un’azione del visitatore.

CDN: quando conviene

Una content delivery network (CDN) memorizza i file statici su server in molti Paesi e li consegna dalla sede più vicina. È utile soprattutto se i suoi visitatori sono distribuiti su più continenti. Se il suo sito si rivolge soprattutto a clienti in Svizzera e nel Liechtenstein, cache, immagini ottimizzate e una risposta veloce del server di solito rendono di più. Una CDN può comunque avere senso, ad esempio con molte immagini grandi o molti download.

WordPress: le leve principali

• Usare un plugin di cache adatto al server web. Su LiteSpeed è LiteSpeed Cache, che può anche ottimizzare CSS e JavaScript, gestire il lazy loading e convertire le immagini in WebP o AVIF tramite il servizio QUIC.cloud.
• WordPress supporta WebP dalla versione 5.8 e AVIF dalla versione 6.5. Dalla versione 6.3 WordPress aggiunge automaticamente fetchpriority="high" all’immagine che probabilmente sarà l’elemento LCP.
• Usare un tema a blocchi leggero invece di un page builder pesante.
• Controllare regolarmente i plugin e rimuovere tutto ciò che non serve.
• Ripulire il database: vecchie revisioni, commenti spam e transient scaduti, dopo aver fatto un backup.
• Usare una versione di PHP aggiornata; WordPress consiglia attualmente PHP 8.3 o più recente.

Consiglio: Altri consigli pratici si trovano nel nostro articolo «Velocizzare WordPress: 8 interventi che funzionano davvero».

Procedere in questo ordine

1. Registrare lo stato attuale per mobile e desktop con PageSpeed Insights e Search Console.
2. Individuare l’elemento LCP (PageSpeed Insights lo indica) e ottimizzarlo in modo mirato, di solito l’immagine principale.
3. Attivare la cache delle pagine e verificare il TTFB.
4. Convertire le immagini in WebP o AVIF e indicare larghezza e altezza.
5. Ospitare i font sul proprio sito e ridurre gli script di terzi.
6. Misurare di nuovo dopo ogni modifica e controllare i dati sul campo dopo alcune settimane.

Sui pacchetti WordPress di HostOn, LiteSpeed Cache è preconfigurato e i siti funzionano su server LiteSpeed con spazio NVMe. Cache delle pagine e risposta del server sono così coperte; immagini, font e script restano compito del sito stesso.