Velocità del sito web e Core Web Vitals: Una guida completa

Cosa significano i Core Web Vitals in linguaggio semplice

Iniziamo con le basi.Core Web Vitals sono tre metriche che Google utilizza per misurare come una pagina si carica realmente attraverso gli occhi di un vero umano, non di un robot. Rispondono a tre semplici domande: il contenuto principale è apparso rapidamente, il sito ha reagito rapidamente alla tua azione e il layout è rimasto fermo sotto il tuo dito.

LCP — quanto velocemente appare il contenuto principale

LCP (Largest Contentful Paint) è il momento in cui il più grande elemento visibile termina il rendering: di solito un'immagine principale, un titolo o un grande banner. Un visitatore considera la pagina caricata quando quel blocco appare, non quando arriva l'ultimo script del footer. Un obiettivo solido nel 2026 è di circa 2,5 secondi su una connessione mobile tipica.

INP — quanto velocemente il sito risponde

INP (Interaction to Next Paint)ha sostituito il vecchio FID e misura la reattività: tocchi un pulsante, apri un menu, inizi a digitare — e quanti millisecondi passano prima che l'interfaccia reagisca visibilmente. Se non succede nulla per mezzo secondo dopo un clic, il cervello è convinto che il sito si sia bloccato. Un intervallo confortevole è sotto i 200 millisecondi.

CLS — quanto è stabile il layout

CLS (Cumulative Layout Shift)cattura il bug più fastidioso: punti a un pulsante, un'immagine o un banner si carica sopra di esso, tutto salta in basso e clicchi la cosa sbagliata. È uno spostamento cumulativo del layout, e più è vicino a zero, più il sito sembra ordinato. Un valore sano è sotto 0.1.

Ricorda una formula semplice: LCP riguarda il vedere, INP riguarda il toccare, CLS riguarda il non saltare. Google raccoglie tutti e tre da utenti reali di Chrome e li tratta come parte di un segnale di qualità della pagina per il ranking.

Perché la velocità influisce su SEO e conversione

Siamo diretti: un sito lento perde soldi alla porta, prima che il visitatore abbia letto una sola parola. Ogni secondo extra di attesa aumenta la percentuale di persone che chiudono la scheda e se ne vanno verso un concorrente che si apre istantaneamente.

Velocità e posizionamento nei motori di ricerca

I Core Web Vitals sono un fattore di ranking ufficiale. Questo non significa che una pagina veloce ma vuota batte una lenta ma esperta: il contenuto viene ancora prima. Ma quando due pezzi sono vicini in qualità, la velocità diventa il fattore decisivo che ti solleva più in alto. Un sito veloce viene anche indicizzato più a fondo — con lo stesso budget di scansione, il bot raggiunge più delle tue pagine.

Velocità e denaro

Nei progetti commerciali il legame tra velocità del sito webe ricavi è evidente. Accelerare il primo schermo solleva notevolmente il checkout e la conversione dei moduli, abbassa il tuo costo di acquisizione (smetti di perdere metà del tuo traffico a pagamento sulla schermata di caricamento) e aumenta quanto in profondità le persone navigano. Abbiamo visto questo ripetutamente nel nostro lavoro di sviluppo e ottimizzazione: le prestazioni tecniche ripagano più velocemente di un'altra campagna pubblicitaria.

C'è anche uno strato di reputazione. Un sito lento viene letto subconscientemente come inaffidabile: se tutto qui è a scatti, posso fidarmi del mio pagamento? La velocità è la prima stretta di mano del tuo marchio, e dovrebbe sembrare sicura.

Come misurare la velocità: laboratorio vs campo

Prima di correggere qualsiasi cosa, misura onestamente. E qui è fondamentale separare due tipi di dati fondamentalmente diversi, perché le persone li confondono costantemente.

Dati di laboratorio

Laboratorio le misurazioni vengono effettuate da uno strumento in condizioni controllate: una connessione fissa, un dispositivo definito, un ambiente pulito. Questo è Lighthouse (integrato in Chrome DevTools) e la sezione laboratorio di PageSpeed Insights. Il vantaggio è la ripetibilità: cambi il codice e vedi immediatamente se le cose sono migliorate. Lo svantaggio è che si tratta di una simulazione, non di persone reali.

Dati di campo

Campo i dati sono metriche raccolte da veri utenti di Chrome (il dataset CrUX). Questi sono esattamente quelli che Google utilizza per il ranking. Mostrano come il sito si comporta su dispositivi reali, reti reali e geografie reali. I numeri di campo sono misurati al 75° percentile: l'obiettivo è che il sito sia veloce non in media, ma per tre quarti del pubblico.

Un ordine di misurazione pratico

1. Esegui i tuoi modelli chiave (home, categoria, prodotto, modulo) attraverso PageSpeed Insights — separatamente per mobile e desktop.
2. Guarda prima i Core Web Vitals di campo se esistono; usa il punteggio di laboratorio come strumento di debug.
3. Apri la scheda Performance in DevTools e scopri quale elemento guida LCP e quali script bloccano il thread principale.

La regola d'oro: ottimizza per il campo, esegui il debug per il laboratorio. Inseguire un bel cento in Lighthouse senza considerare gli utenti reali è lavoro fatto per uno screenshot, non per il business.

LCP: cosa copre e come migliorarlo

LCP è di solito ciò che le persone intendono quando dicono che il sito impiega un'eternità a caricarsi. Migliorarlo significa mostrare prima l'elemento principale della prima schermata. Rompiamolo in parti.

Di cosa è fatto LCP

LCP ha quattro ingredienti: il tempo di risposta del server (TTFB), un ritardo prima che la risorsa inizi a caricarsi, il tempo di caricamento della risorsa stessa e il tempo di rendering. Ognuno di essi può essere il collo di bottiglia, quindi il trattamento inizia con la diagnosi, non con le supposizioni.

Cosa accelera effettivamente LCP

• Una risposta rapida del server.Mantieni TTFB basso: caching lato server, hosting adeguato e poche query pesanti al database nella generazione del primo schermo.
• Priorità per la risorsa principale.L'immagine LCP o il font del titolo dovrebbero caricarsi con alta priorità (preload), non nella coda generale.
• Niente caricamento pigro per il primo schermo.Un errore classico è mettere il caricamento pigro sul banner superiore. Riserva il caricamento pigro per ciò che si trova sotto la piega.
• Un elemento LCP leggero e correttamente compresso.Un enorme PNG da 2 MB rovinerà la metrica anche su un server veloce.

Una parola sul blocco del rendering. Se il browser deve scaricare ed eseguire pesanti CSS e JavaScript prima di mostrare il primo schermo, LCP è ritardato esattamente da quel tempo. Ecco perché il CSS critico è in linea mentre gli script secondari sono spinti in basso e differiti.

INP e CLS: reattività e stabilità

Se LCP riguarda la visione, INP e CLS riguardano il senso di qualità dopo il caricamento. Spesso sono sottovalutati, e questo è un errore: sono esattamente ciò che fa sentire un sito costruito con cura.

Come migliorare INP

Un cattivo INP quasi sempre significa che il thread principale del browser è occupato con pesante JavaScript. L'utente tocca — ma in quel momento il thread sta elaborando analisi, guidando uno slider o renderizzando un widget, e la reazione è ritardata. Cosa aiuta:

• Dividi compiti lunghi in compiti brevi, dando al browser pause per gestire i clic.
• Rimuovi o differisci script di terze parti che lavorano in background.
• Evita gestori pesanti ad ogni movimento e pressione di tasti.
• Sposta i calcoli opzionali fuori dal momento di interazione.

Come rimuovere i cambiamenti di layout (CLS)

Il CLS si cura con disciplina nel markup. Le regole principali:

1. Imposta sempre larghezza e altezza (o rapporto d'aspetto) su immagini e video in modo che lo spazio sia riservato in anticipo.
2. Riserva spazio per banner, widget e spazi pubblicitari invece di lasciare che spingano il contenuto quando appaiono.
3. Carica i font in modo che la sostituzione del font di sistema con uno personalizzato non sposti il testo (corretto font-display e metriche di fallback).
4. Non inserire mai contenuti sopra a ciò che l'utente vede già — solo sotto di esso.

I pagamenti e i moduli sono un punto dolente speciale. Nel nostroprogetto del servizio di pagamento Payoraabbiamo osservato con particolare attenzione la stabilità della prima schermata: quando ci sono di mezzo soldi, un layout che salta e una risposta lenta del pulsante riducono direttamente la fiducia e il numero di transazioni completate.

Le principali cause di un sito lento

Buone notizie: i siti lenti hanno poche cause, e sono sorprendentemente tipiche. In nove casi su dieci, qualcuno in questa lista è da incolpare.

Immagini pesanti

Il peso assoluto della dimensione della pagina. Foto a risoluzione completa, screenshot PNG di diversi megabyte, immagini che il browser riduce a una piccola dimensione ma scarica completamente. Spesso l'immagine è anche l'elemento LCP, quindi è un doppio colpo.

Font

Diversi pesi in formati pesanti, caricati da un dominio esterno, senza preload — e il testo lampeggia o appare in ritardo, spostando il layout mentre si muove.

CSS e JavaScript bloccanti

Bundle giganti che devono essere scaricati ed eseguiti prima della prima visualizzazione. I framework pesanti sono particolarmente spreconi dove un paio di righe di codice sarebbero sufficienti.

Script di terze parti

Chat, pixel, una dozzina di tag di analisi, widget sociali, test A/B. Ognuno è leggero da solo, ma insieme consumano il thread principale e rovinano l'INP. Questa è la categoria più sottovalutata.

Hosting lento e alto TTFB

Se il server impiega un secondo prima di rispondere, nessuna magia del front-end può nascondere completamente questo. Hosting economico sovraccarico, nessuna cache del server, query del database pesanti — tutto ciò si trova alla base del LCP.

La lezione pratica: non affrettarti a risolvere tutto in una volta. Misura prima, trova la tua principale fonte di perdita — e colpisci quella.

Ottimizzazione delle immagini: formati e caricamento pigro

Poiché le immagini sono il peso massimo, l'ottimizzazione della velocità inizia quasi sempre da lì. Questa è la vittoria più veloce e visibile con il rischio più basso.

Formati moderni

Passa a WebP, e dove possibile a AVIF. A qualità comparabile pesano notevolmente meno rispetto ai classici JPEG e PNG. Per icone e grafiche semplici usa SVG: è vettoriale, senza peso e perfettamente nitido su qualsiasi schermo.

Dimensionamento corretto e reattività

Non servire mai un'immagine più larga di quanto venga effettivamente visualizzata. Prepara diverse dimensioni e collegale tramite srcset in modo che un telefono ottenga una versione compatta e un desktop una grande. Un'immagine hero da 4000 pixel in un contenitore da 800 pixel è megabyte e secondi sprecati.

Lazy loading — ma con saggezza

• Aggiungi loading="lazy" per le immagini sotto il primo schermo in modo che non interferiscano con la pittura iniziale.
• Ma carica immediatamente e con priorità l'immagine LCP del primo schermo — il lazy loading qui fa solo danni.
• Imposta sempre le dimensioni in modo che il lazy loading non causi spostamenti del layout (quello stesso CLS).

E non dimenticare la compressione. Eseguire le risorse attraverso un buon ottimizzatore riduce spesso il peso del 40–70% senza perdita di qualità visibile. Per i siti di contenuto, si tratta letteralmente di secondi gratuiti.

Font, CSS critico e JavaScript eccessivo

Dopo le immagini, la seconda zona più importante è il codice che il browser deve elaborare prima di mostrare la pagina. La maggior parte dei problemi di blocco del rendering si nasconde qui.

Font

• Mantieni il numero minimo di pesi: due sono spesso sufficienti.
• Usa woff2 e fornisci i font dal tuo dominio.
• Precarica il font chiave per la prima schermata.
• Imposta font-display: swap in modo che il testo sia leggibile immediatamente invece di aspettare il font.

CSS critico

L'idea è semplice: gli stili necessari per la prima schermata sono in linea direttamente nell'HTML, e il resto del CSS si carica in seguito. In questo modo il browser dipinge la parte superiore della pagina senza aspettare l'intero foglio di stile. Rimuovi anche le regole morte: nel corso degli anni un sito accumula molte di esse.

Meno JavaScript

L'ottimizzazione più onesta è non caricare ciò di cui puoi fare a meno. Controlla se stai caricando un framework pesante per un paio di effetti. Rimanda gli script secondari con defer e async, dividi il pacchetto e carica il codice su richiesta. Audit separatamente i widget di terze parti: ogni chat, pixel e tag deve giustificare il suo posto nel budget delle prestazioni. Abbiamo trattato come questo si adatta ai siti multilingue senza appesantire la pagina nel nostro articolo su sito multilingue e SEO.

Caching, CDN, HTTP/2 e hosting

L'ottimizzazione del front-end raggiunge un limite se le fondamenta — il server e la consegna — sono lenti. Questi elementi ripagano su ogni pagina contemporaneamente.

Caching

Funziona su due livelli.Cache del server evita di rigenerare ripetutamente una pagina pesante e riduce direttamente il TTFB.Cache del browser (intestazioni Cache-Control corrette per le risorse statiche) significa che durante le visite di ritorno immagini, font e script non vengono scaricati di nuovo.

CDN

Una rete di distribuzione dei contenuti serve risorse statiche dal server più vicino all'utente geograficamente. Più lontano è il tuo pubblico dall'origine, più forte è l'effetto: la latenza diminuisce e il primo byte arriva più velocemente.

HTTP/2, HTTP/3 e compressione

• Abilita un protocollo moderno (HTTP/2 o HTTP/3) — carica dozzine di piccoli file in parallelo in modo più efficiente.
• Abilita la compressione delle risorse testuali (Brotli o gzip) sul server.
• Minifica HTML, CSS e JS, rimuovendo spazi bianchi e commenti.

Hosting e TTFB

Un server adeguato non è un lusso ma una base. Nel progetto di mercato freelance 24freelance marketplace project abbiamo colpito esattamente il livello del server: senza caching e ottimizzazione delle query il primo byte si trascinava, e nessuna quantità di lavoro sulle immagini ha raggiunto i numeri target fino a quando non abbiamo messo in ordine il backend.

Velocità sui dispositivi mobili

Una verità importante del 2026: Google valuta il tuo sito principalmente in base alla sua versione mobile, e la maggior parte del traffico proviene dai telefoni. E un telefono significa un processore più debole, una rete meno stabile e meno pazienza da parte dell'utente.

Perché il mobile è più severo

Ciò che si esegue istantaneamente su un potente laptop richiede diverse volte di più su uno smartphone medio. JavaScript pesante colpisce particolarmente duro l'INP su mobile proprio perché il processore è più debole e impiega più tempo per completare ogni compito.

Cosa fare

• Testa con un dispositivo limitato e un'emulazione di rete lenta, non solo sul tuo dispositivo di punta.
• Rendi i controlli abbastanza grandi e riserva spazio in anticipo per evitare tocchi e spostamenti accidentali.
• Riduci al minimo gli script di terze parti, specialmente — il loro costo su mobile è diverse volte più alto.
• Servi immagini di dimensioni mobili, non quelle desktop ridotte dal browser.

La buona notizia: se un sito funziona bene su un telefono medio in una rete mediocre, sarà quasi certamente veloce su desktop. Quindi ottimizza per il peggior scenario realistico, non per il tuo monitor di lavoro.

Monitoraggio e controllo continuo

La velocità non è un progetto una tantum ma una forma di igiene. Un sito vive: i contenuti vengono aggiunti, nuovi widget e banner arrivano, il codice viene aggiornato — e le prestazioni degradano silenziosamente. Senza monitoraggio, apprendi di un problema dai cali delle vendite, non da un rapporto.

Come tenere il polso della situazione

• Controlla regolarmente i Core Web Vitals di campo in Google Search Console — mostra la vera tendenza per il tuo pubblico.
• Imposta controlli automatici dei modelli chiave per catturare le regressioni subito dopo un rilascio, non un mese dopo.
• Stabilisci un budget per le prestazioni — un limite di peso della pagina e conteggio degli script che il team non può superare.
• Tratta ogni nuovo script di terze parti come una decisione separata: cosa offre all'azienda e cosa costa in velocità.

Chi se ne occupa

In pratica, è utile rendere una persona responsabile della velocità — altrimenti la metrica diventa di nessuno e cala per prima. Se non hai una persona del genere nel team, il ruolo può essere esternalizzato: noi, ad esempio, ci occupiamo di audit periodici e supporto alle prestazioni, che è più facile da organizzare attraverso il nostro modulo di contatto.

L'idea principale: misura prima e dopo ogni cambiamento importante. L'affermazione che le cose siano diventate più veloci deve essere provata, non solo percepita.

Una checklist pratica per la velocità del sito

Raccogliamo tutto in un'unica lista applicata. Lavora su di essa dall'alto verso il basso — gli elementi sono grossomodo ordinati per rapporto effetto-sforzo. Non devi fare tutto in una volta, ma ogni punto merita di essere esaminato.

Misura e dai priorità

1. Misura i tuoi modelli chiave in PageSpeed Insights (mobile e desktop) e registra i Core Web Vitals attuali.
2. Trova l'elemento LCP di ciascun modello importante e il suo principale collo di bottiglia.

Immagini

1. Converti le immagini in WebP o AVIF e le icone in SVG.
2. Fornisci dimensioni responsive tramite srcset, mai più grandi del contenitore.
3. Abilita il caricamento pigro sotto il primo schermo; carica l'immagine LCP con priorità.
4. Imposta le dimensioni delle immagini in modo che non ci siano spostamenti del layout.

Codice e font

1. Includi il CSS critico e carica il resto in seguito.
2. Riduci i pesi dei font, aggiungi preload e font-display: swap.
3. Ritarda gli script con defer/async e rimuovi CSS e JS non utilizzati.
4. Audita i widget di terze parti e elimina tutto ciò che è superfluo.

Server e consegna

1. Abilita la cache del server e riduci il TTFB.
2. Configura la cache del browser per le risorse statiche e la compressione Brotli/gzip.
3. Aggiungi un CDN e un protocollo moderno, HTTP/2 o HTTP/3.
4. Minifica HTML, CSS e JS.

Controllo

1. Verifica il risultato su un'emulazione di dispositivo mobile limitata.
2. Configura il monitoraggio delle metriche di campo e un budget di prestazioni.
3. Rimedi misura prima e dopo — registra il successo in numeri.

Segui questa checklist onestamente e otterrai non solo un punteggio carino ma un sito più veloce, più stabile e più redditizio. E questo, alla fine, è il punto.

FAQ