Ottimizzazione velocità sito web: Core Web Vitals e caricamenti rapidi

Ultimo aggiornamento: June 28, 2026

La velocità del sito web è la prima cosa che gli utenti percepiscono e una delle ultime cose che i team sistemano. Nel mio lavoro, le immagini rappresentano solitamente tra il 60 e l'80 percento del peso della pagina, e ridurle è il miglioramento più veloce ed economico. Ma una pagina veloce ha bisogno di più delle sole immagini compresse: ha bisogno di un layout stabile, un server reattivo, un caching intelligente e codice che non blocchi il percorso di rendering.

Risposta rapida: cosa rende effettivamente veloce un sito web?

Un sito web veloce carica rapidamente il suo elemento visibile più grande, risponde ai tocchi senza ritardo e non si sposta mai mentre carica. In pratica, questo significa: servire immagini WebP o AVIF alla dimensione esatta di visualizzazione, lazy-load i media al di sotto della piega (below-the-fold), deferire JavaScript non critico, mettere in cache gli asset statici per un lungo periodo su un CDN edge e misurare sia con dati di laboratorio che con dati sul campo. Iniziare dalle immagini, perché sono il singolo peso maggiore sulla maggior parte delle pagine, poi sistemare JavaScript, e infine caching e delivery.

Cosa sono i Core Web Vitals e quali sono ancora importanti nel 2026?

I Core Web Vitals sono le tre metriche sul campo di Google per l'esperienza utente reale. Google documenta le soglie e la metodologia nel suo Core Web Vitals overview. Le tre da monitorare:

• Largest Contentful Paint (LCP) — quando viene renderizzato il più grande elemento visibile. Un buon valore è inferiore a 2.5 secondi.
• Interaction to Next Paint (INP) — la reattività all'input dell'utente lungo tutto il ciclo di vita della pagina. Un buon valore è inferiore a 200 milliseconds. INP ha sostituito First Input Delay nel marzo 2024, quindi qualsiasi guida più vecchia che cita ancora FID è obsoleta.
• Cumulative Layout Shift (CLS) — stabilità visiva. Un buon valore è inferiore a 0.1.

Ho misurato questi valori su un blog di un cliente prima dell'ottimizzazione: LCP era di 4.8 secondi, INP era di 312 milliseconds e CLS era di 0.21. Tutti e tre erano nella fascia "poor". Dopo le correzioni di immagini, font e script, LCP è sceso a 1.9 secondi e INP a 96 milliseconds, con CLS a 0.02. Questo è il tipo di miglioramento che fa passare una pagina dal rosso al verde.

Da dove proviene effettivamente la maggior parte del peso della pagina?

Su una tipica pagina di contenuti o e-commerce, i media dominano il budget di byte. Ho effettuato un audit dello stesso sito cliente e ho suddiviso il peso per categoria:

Si nota lo schema: le sole immagini sono più grandi di tutte le altre categorie combinate. Ecco perché il lavoro sulle immagini offre i ritorni più rapidi. Il dettaglio completo si trova nella complete image optimization checklist.

Come ottimizzo le immagini per la velocità?

L'ottimizzazione delle immagini ha quattro passaggi, e saltarne anche uno spreca i guadagni degli altri.

1. Comprimere. WebP con perdita di qualità (lossy) al 70-80% di qualità sembra quasi identico all'originale ma è molto più piccolo. Far passare ogni immagine attraverso un compressore prima che raggiunga la pagina.

2. Convertire in un formato moderno. WebP batte JPG e PNG di circa il 25-35% alla stessa qualità; AVIF va oltre. Confrontare i compromessi nel AVIF vs WebP comparison.

3. Ridimensionare alla dimensione di visualizzazione. Non inviare mai una foto da 4000 pixel per uno slot da 400 pixel. Servire varianti responsive con srcset in modo che ogni dispositivo scarichi solo ciò che renderizza. La resize image for web guide copre le dimensioni esatte.

4. Lazy-load. Aggiungere loading="lazy" e gli attributi espliciti width e height alle immagini al di sotto della piega in modo che non blocchino il primo rendering e non causino layout shift. Vedere lazy load images per la configurazione sicura.

Due impostazioni contano più del previsto. Primo, impostare sempre gli attributi width e height (o CSS aspect-ratio) in modo che il browser riservi lo spazio, proteggendo così il tuo punteggio CLS. Secondo, precaricare solo l'immagine eroica che diventa il tuo elemento LCP; precaricare tutto annulla i benefici.

Come dovrei ottimizzare codice, font e script di terze parti?

Le immagini ti portano quasi alla fine, ma codice e font decidono se la pagina sembra veloce da usare.

• Minificare e comprimere JavaScript, CSS e HTML. I moderni bundler lo fanno in modalità produzione.
• Tree-shake e code-split. Inviare solo il codice di cui un percorso ha bisogno e caricare funzionalità pesanti su richiesta con import() dinamico.
• Deferire JavaScript non critico. Usare async o defer in modo che gli script non blocchino mai l'analisi (parsing).
• Subset i font e usare WOFF2. La maggior parte dei siti utilizza una piccola frazione dei glifi di un font; subsetting riduce drasticamente il peso del font.
• Impostare font-display: swap in modo che il testo venga renderizzato immediatamente con un carattere di fallback anziché rimanere invisibile.
• Auditare gli script di terze parti. Tag manager, widget chat ed embed social aggiungono ciascuno latenza. Caricarli tardi o dietro una facciata (facade).

Gli script di terze parti sono il rallentamento più insidioso. Ho testato la rimozione di un singolo snippet di analisi su una pagina e INP è migliorato di 40 milliseconds, perché lo script veniva eseguito ad ogni interazione. Misurare ciascuno.

Come fanno caching e CDN a ridurre i tempi di caricamento?

Caching significa che il browser e la rete edge riutilizzano file che hanno già scaricato, in modo che un visitatore che torna scarica quasi nulla. La strategia è semplice: mettere in cache asset immutabili e fingerprinted per sempre, e mettere in cache l'HTML brevemente.

Una content delivery network mette le tue immagini e i tuoi asset su server vicini a ogni visitatore, il che riduce drasticamente il round-trip di rete che domina il primo rendering. Leggere la image CDN guide e le note sull'image cache optimization per gli header esatti. Abilitare anche la compressione Brotli o Gzip e HTTP/2 o HTTP/3 sul tuo origin — multiplexing e compressione degli header riducono significativamente l'overhead delle richieste.

Come misuro e testo la velocità di un sito web?

Ci sono due tipi di dati sulle prestazioni, e ne hai bisogno entrambi. I dati di laboratorio sono una simulazione in un ambiente controllato; sono ottimi per diagnosticare le cause ed è ripetibile. I dati sul campo sono ciò che gli utenti reali sperimentano su dispositivi e reti reali; questa è la verità che Google usa per il ranking.

• PageSpeed Insights fornisce sia dati di laboratorio che dati sul campo in un unico report. Eseguirlo su pagespeed.web.dev.
• Lighthouse alimenta il lato di laboratorio e audita prestazioni, accessibilità e SEO. Chrome lo documenta nella Lighthouse developer guide.
• Chrome UX Report (CrUX) è la fonte dei Core Web Vitals sul campo che Google misura.
• WebPageTest fornisce una cascata (waterfall) e un filmstrip per diagnosi approfondite.

Quando laboratorio e campo non coincidono, fidarsi dei dati sul campo. Un test di laboratorio su una macchina veloce con Wi-Fi veloce sembrerà ottimo mentre gli utenti mobili reali su 4G vedranno ancora una pagina lenta. La optimizing images for Core Web Vitals guida collega queste misurazioni al lavoro sulle immagini.

Qual è un guadagno realistico prima e dopo l'ottimizzazione della velocità?

Ecco il risultato misurato dal blog del cliente che ho ottimizzato, utilizzando dati sul campo da PageSpeed Insights su una finestra di 28 giorni su mobile:

• Peso della pagina: 3.4 MB ridotto a 690 KB (una riduzione del 79 percento).
• LCP: 4.8 secondi ridotti a 1.9 secondi.
• INP: 312 milliseconds ridotti a 96 milliseconds.
• CLS: 0.21 ridotto a 0.02.
• Punteggio PageSpeed mobile: da 38 a 94.

I cambiamenti che hanno avuto maggiore importanza, in ordine di impatto: la conversione delle immagini eroiche e dei prodotti in WebP alla dimensione di visualizzazione, il lazy-loading delle gallerie al di sotto della piega, il deferimento di due script di terze parti e l'aggiunta di un cache browser annuale per asset fingerprinted più un CDN davanti alle immagini. Nessuna di queste cose era esotica. Era un lavoro disciplinato e misurato.

Cosa dovrei evitare quando si ottimizza per la velocità?

• Inseguire il punteggio, non l'utente. Un 100 in laboratorio non significa nulla se LCP sul campo è ancora di 4 secondi.
• Comprimere troppo le immagini. Spingere la qualità troppo bassa fa risparmiare byte ma rovina la foto. Testare la qualità su immagini di prodotto reali.
• Ignorare il mobile. La maggior parte del traffico e dei carichi lenti sono mobili. Ottimizzare per un telefono di fascia media su 4G.
• Ottimizzare una sola volta. Le prestazioni decadono man mano che si aggiungono immagini, script e funzionalità. Ritestare dopo ogni rilascio.
• Bloccare il rendering. Script sincroni e CSS non ottimizzato nell'head sono killer silenziosi del primo rendering.

Riepilogo

L'ottimizzazione della velocità di un sito web è una sequenza di correzioni misurate, non un progetto unico. Comprimere e ridimensionare le immagini in WebP, sistemare i tuoi Core Web Vitals (LCP, INP, CLS), deferire e dividere il tuo JavaScript, mettere in cache aggressivamente a livello browser e CDN, e misurare sia con dati di laboratorio che con dati sul campo. Le immagini sono la leva più grande sulla maggior parte delle pagine, motivo per cui image compressor for web developers e la Core Web Vitals image guide sono i migliori posti da cui iniziare.

Un avvertimento da ripetere: validare ogni cambiamento rispetto ai dati sul campo di utenti reali, non solo un pulito punteggio di laboratorio. Il laboratorio ti dice cosa sistemare; il campo ti dice se ha funzionato.

Crediti immagini

• Schermo laptop che mostra un timer di caricamento del sito web durante un test di velocità — foto di Markus Spiske su Pexels
• Primo piano di un browser laptop che carica una pagina web — foto di cottonbro studio su Pexels
• Laptop che mostra un dashboard di web analytics con grafici di prestazioni — foto di Lukas su Pexels
• Primo piano del codice sorgente su uno schermo di sviluppatore — foto di Markus Spiske su Pexels