Il page speed è la velocità con cui una pagina diventa visibile e utilizzabile per chi la apre. Non è un numero solo: Google ne misura tre aspetti separati e li calcola sui dati raccolti dai browser degli utenti reali, non su un test simulato.
Questa differenza tra dato reale e dato simulato spiega quasi tutte le discussioni che nascono attorno alla velocità di un sito: il punteggio colorato che restituisce PageSpeed Insights e la valutazione che Google usa per il ranking sono due cose diverse, prodotte da due sistemi diversi. Chi le confonde ottimizza per mesi il numero sbagliato.
Le tre metriche che Google misura
Si chiamano Core Web Vitals e sono tre. Largest Contentful Paint (LCP) misura quanto tempo passa prima che compaia l’elemento più grande visibile nella parte alta della pagina, di solito un’immagine o un blocco di testo. Interaction to Next Paint (INP) misura il ritardo tra il momento in cui l’utente tocca qualcosa e il momento in cui lo schermo risponde. Cumulative Layout Shift (CLS) misura quanto il layout si sposta mentre la pagina finisce di caricare, quel fenomeno per cui premi un pulsante e ne colpisci un altro perché nel frattempo si è aperto un banner.
| Metrica | Cosa misura | Buono | Da migliorare | Scarso |
|---|---|---|---|---|
| LCP | Comparsa dell’elemento principale | ≤ 2,5 s | 2,5 – 4 s | > 4 s |
| INP | Risposta a un’interazione | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Spostamenti imprevisti del layout | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Due dettagli sul metodo cambiano il modo in cui va letto qualsiasi report. Il primo: la soglia non viene applicata alla media delle visite ma al 75° percentile. Google ha scelto quel valore perché garantisce che tre visite su quattro rientrino nel livello di prestazione richiesto senza che pochi casi anomali sporchino il risultato, come succederebbe al 95° percentile. Il secondo: la finestra è di 28 giorni. Un intervento fatto ieri entra nel report a scaglioni, e serve quasi un mese perché il valore si stabilizzi.
Una quarta metrica è uscita di scena da poco. INP ha sostituito First Input Delay il 12 marzo 2024, e il supporto a FID negli strumenti Chrome è terminato il 9 settembre dello stesso anno. Chi trova ancora FID in una checklist o in un report di agenzia sta leggendo un documento vecchio di almeno due anni.
Il punteggio di PageSpeed Insights non è il Core Web Vitals
Quando apri PageSpeed Insights vedi due blocchi. In alto, se il sito ha abbastanza traffico, ci sono i dati di campo: quelli veri, raccolti dai browser Chrome degli utenti che hanno visitato quella pagina negli ultimi 28 giorni, aggregati nel Chrome UX Report. Sotto c’è il punteggio da 0 a 100, che nasce da una simulazione: Lighthouse carica la pagina una volta sola, con cache vuota, su un dispositivo e una connessione impostati a tavolino.
I due blocchi possono raccontare storie opposte, e non è un difetto degli strumenti. Google ha messo per iscritto le ragioni per cui laboratorio e campo divergono: gli utenti reali arrivano spesso con parte delle risorse già in cache, usano il tasto indietro e attivano la bfcache che il test non simula, vedono contenuti personalizzati o varianti di test A/B con elementi LCP diversi, e fanno scorrere la pagina facendo comparire immagini in lazy loading che spostano il layout in un momento che nessun test riproduce. Sul fronte opposto, un ritardo di 300 millisecondi su un dispositivo lento non incide sul Total Blocking Time misurato in laboratorio ma peggiora l’INP reale.
C’è anche il fatto che il punteggio di laboratorio è instabile. Nella nostra esperienza è normale che due esecuzioni consecutive sullo stesso URL, a distanza di minuti, restituiscano valutazioni molto diverse. Il numero non è una proprietà del sito, è il risultato di una singola misurazione.
Quanto pesa la velocità nel posizionamento
Qui conviene citare Google alla lettera invece di parafrasarlo. Nella documentazione sulla page experience si legge che «non esiste un singolo segnale: i nostri sistemi di ranking principali guardano una varietà di segnali che si allineano all’esperienza complessiva della pagina», e poco sotto che «la Ricerca Google cerca sempre di mostrare il contenuto più pertinente, anche quando la page experience è scadente». Nella pagina dedicata ai Core Web Vitals c’è la frase che chiude la questione: «ottenere buoni risultati nei report non garantisce che le tue pagine si posizionino ai primi posti».
La lettura corretta la suggerisce la frase successiva della documentazione di Google Search Central: per molte query esiste tanto contenuto utile, e in quei casi una buona esperienza di pagina può contribuire al risultato. Tradotto in pratica, la velocità conta quando sei già in gara. Se il tuo problema è che nessuno ti linka, che il sito non risponde all’intento di ricerca o che il brand non ha domanda, portare l’LCP da 3,1 a 2,4 secondi non sposterà niente. Su questo vale la pena leggere quali sono davvero i fattori di ranking e in che ordine si affrontano.
Come sta messo il web, in numeri
L’edizione 2025 del Web Almanac di HTTP Archive, costruita sul dataset globale CrUX, misura quante origini superano tutte e tre le soglie. Il campione non è italiano né statunitense: è l’insieme dei siti coperti da Chrome nel mondo.
| Valutazione «buono» | Mobile | Desktop |
|---|---|---|
| Tutti e tre i Core Web Vitals | 48% | 56% |
| LCP | 62% | 74% |
| INP | 77% | 97% |
| CLS | 81% | 72% |
Tre cose saltano all’occhio. La prima: su mobile meno di un sito su due passa l’esame, quindi trovarsi sotto soglia non è un’anomalia, è la condizione della maggioranza. La seconda: il divario tra desktop e mobile si concentra sull’INP, 97% contro 77%, e questo perché la reattività dipende dal lavoro che il JavaScript scarica sul processore del telefono. La terza: la situazione migliora lentamente ma migliora, dal 36% del 2023 al 44% del 2024 al 48% del 2025 su mobile.
Un dato che ribalta un pregiudizio comune: tra i primi mille siti al mondo per traffico, la quota che passa i Core Web Vitals su mobile è 51%, e sull’INP scende al 63% contro il 77% della popolazione generale. I siti più grandi sono mediamente meno reattivi, perché sono quelli che caricano più script di terze parti.
In Italia la rete non è il collo di bottiglia
Molti articoli sulla velocità partono dal presupposto che l’utente italiano navighi in condizioni difficili. I dati istituzionali dicono un’altra cosa. Il progetto Misura Internet Mobile, gestito da AGCOM con la Fondazione Ugo Bordoni, ha misurato le reti mobili in 45 città italiane tra agosto e novembre 2023: 339 Mbps di download medio nelle misure statiche, 227 Mbps in quelle dinamiche, cioè effettuate in movimento. Milano arriva a 406 Mbps, Napoli, ultima della classifica, a 290.
Con quelle capacità, un sito lento in Italia è lento per colpa di quello che gli è stato montato sopra: script di tracciamento, chat, pixel pubblicitari, font caricati da domini esterni, plugin che nessuno ha più tolto. Non per la banda. Il che sposta il problema dall’infrastruttura alle decisioni di marketing, ed è una notizia migliore, perché le decisioni di marketing si possono cambiare in un pomeriggio.
137 URL «scadenti» e un banner dei cookie
Un caso dai nostri progetti, riportato senza il nome del cliente perché i numeri non sono pubblici. Un’azienda B2B italiana con tre siti in tre lingue apre Google Search Console e trova 137 pagine segnalate come «scadenti» sui Core Web Vitals mobile, distribuite su due domini. La reazione del CEO è quella tipica: capisce che il problema potrebbe non incidere sulla SEO, ma vedere quel numero rosso in dashboard gli dà fastidio e vuole risolverlo.
Analizzando le pagine è emerso che l’unico valore fuori soglia era l’INP da mobile, mentre su desktop era tutto a posto. La causa: le richieste partivano tutte insieme e, finché non completavano, la pagina risultava non caricata secondo le metriche dello strumento. Navigando gli stessi URL in incognito con il pannello Performance di Chrome DevTools attivo, i Core Web Vitals risultavano buoni.
Qualche mese prima, sullo stesso gruppo di siti, un altro allarme LCP era rientrato con un intervento di dieci minuti: il banner della cookie policy occupava quasi tutto lo schermo del telefono, Google lo identificava come elemento più grande della pagina e misurava il tempo di comparsa di quello. Ridotta la dimensione del banner nella console della CMP, le segnalazioni si sono chiuse. Nessuna riscrittura del tema, nessun cambio di hosting.
Il punto interessante è quello che è successo dopo. Nello stesso periodo il dominio internazionale perdeva traffico organico nonostante mesi di lavoro sui contenuti. La causa non era la velocità, era l’assenza di domanda di brand e di segnali di autorevolezza fuori dall’Italia: nessuna campagna di awareness, nessuna link building internazionale, nessuna menzione su fonti non italiane. I Core Web Vitals lì erano una rifinitura, non la leva. Nei progetti industriali e manifatturieri questo scambio di priorità è il più frequente di tutti.
Quando conviene lavorare sulla velocità
Questa è la tabella che usiamo per decidere se un intervento sulle prestazioni entra nel piano o resta in coda. Vale per un sito già indicizzato e con un minimo di traffico.
| Situazione | Priorità | Motivo |
|---|---|---|
| Dati di campo «scarso» su LCP o INP e traffico rilevante | Alta | Perdi conversioni ora, indipendentemente dal ranking |
| E-commerce o form di preventivo con volumi | Alta | L’effetto sul tasso di conversione è misurabile in settimane |
| Concorrenti equivalenti per contenuto e autorevolezza | Media | È il caso in cui la page experience può fare da discrimine |
| Punteggio Lighthouse basso ma dati di campo «buono» | Bassa | Stai guardando una simulazione, non i tuoi utenti |
| Sito nuovo o senza autorevolezza sul mercato di riferimento | Bassa | Il collo di bottiglia è la domanda, non il caricamento |
| Meno di 28 giorni dall’ultimo intervento | Nessuna | Il report non ha ancora dati sufficienti per dirti se ha funzionato |
La riga sulle conversioni ha una fonte solida alle spalle. Lo studio Milliseconds Make Millions, condotto da Deloitte per Google su 37 brand europei e statunitensi e oltre 30 milioni di sessioni monitorate per 30 giorni a fine 2019, ha misurato l’effetto di appena 0,1 secondi di miglioramento: +8,4% di tasso di conversione nel retail, +10,1% nel travel, +21,6% di invii di form nella lead generation, +9,2% di valore medio dell’ordine. Il campione è europeo e americano e riguarda i siti mobile di grandi brand: sono ordini di grandezza, non una promessa trasferibile a qualsiasi sito italiano. Ma l’effetto sulle conversioni è più diretto e più rapido dell’effetto sul posizionamento, e nella maggior parte dei casi è l’argomento che giustifica il budget.
Gli interventi in ordine di resa
L’ordine sotto segue quello che vediamo funzionare sui siti aziendali italiani, quasi tutti su CMS come WordPress, non l’ordine con cui li elencano i tool.
- Togliere script che nessuno usa più. Pixel di campagne chiuse, chat mai attivate, tool di heatmap installati per un test di due anni fa. È l’intervento con il rapporto risultato/tempo più alto e non richiede sviluppo.
- Dimensionare l’elemento LCP. Individuare quale elemento Google considera il più grande della pagina, poi decidere se serve davvero che sia quello. Un banner a tutto schermo, uno slider in home, un video di sfondo: spesso la soluzione è rimuoverlo, non ottimizzarlo.
- Servire le immagini nel formato e nella misura giusti. Formati moderni, dimensioni reali di visualizzazione, attributi width e height per bloccare lo spazio ed evitare gli spostamenti di layout. Il dettaglio operativo sta nella guida all’ottimizzazione delle immagini.
- Rimandare il JavaScript non necessario al primo rendering. È l’intervento che sposta l’INP, ed è anche quello che può rompere qualcosa: va fatto con un ambiente di staging.
- Cache e CDN. Utile e ormai standard, ma agisce sul tempo di risposta del server, che raramente è la parte peggiore del problema su un sito aziendale medio.
- Cambiare hosting. Ha senso quando il TTFB resta sopra gli 800 millisecondi anche con la cache attiva. Prima di quel punto è una spesa che sposta il problema di posto.
Nessuno di questi interventi va valutato prima di 28 giorni, per la finestra di raccolta dati di cui sopra. È la ragione per cui vale la pena inserire i Core Web Vitals tra i KPI SEO che si guardano una volta al mese e non una volta al giorno, insieme alle metriche di rendimento come il click-through rate.
Quale strumento serve a cosa
| Strumento | Tipo di dato | Quando usarlo |
|---|---|---|
| Search Console, report Segnali web essenziali | Campo, aggregato per gruppi di URL simili | Capire quante e quali pagine hanno un problema reale |
| PageSpeed Insights, blocco superiore | Campo, 28 giorni, 75° percentile | Verificare il singolo URL con dati di utenti veri |
| PageSpeed Insights, punteggio 0-100 | Laboratorio, esecuzione singola | Trovare cosa ottimizzare, non giudicare lo stato del sito |
| Chrome DevTools, pannello Performance | Locale, navigazione reale | Riprodurre il problema e vedere quale elemento lo causa |
| Chrome UX Report | Campo, storico mensile | Confrontarsi con i concorrenti e leggere il trend |
Un errore che vediamo spesso in fase di audit SEO: valutare lo stato di un sito intero eseguendo Lighthouse sulla home page. La home è quasi sempre la pagina più pesante e meno rappresentativa, e il report di Search Console ragiona per gruppi di URL simili proprio perché la home fa storia a sé. Lo stesso vale quando si incrociano i dati con Google Analytics: la media di sessione nasconde le pagine che stanno davvero male.
Dove sta il page speed nel resto del lavoro
La velocità è una voce della SEO tecnica, e la SEO tecnica è la parte del lavoro che rende il sito leggibile, non quella che lo rende autorevole. Su un progetto B2B con poche centinaia di visite al mese, spostare l’LCP di mezzo secondo produce meno effetti misurabili di una singola pagina scritta bene su una query che nessun concorrente presidia, e le stesse risorse rendono di più investite nell’ottimizzazione on-page. Su un e-commerce con diecimila sessioni al giorno, lo stesso mezzo secondo si traduce in fatturato.
Se stai valutando dove intervenire prima, le due porte d’ingresso sono la consulenza SEO, quando il problema è di visibilità, e lo sviluppo del sito, quando il problema è che la struttura sotto non regge quello che ci è stato costruito sopra.
C’è un’ultima cosa che nel settore si dice poco. Il page speed non è un progetto che si chiude, è una voce che si consuma. Ogni reparto che aggiunge un tag, ogni campagna che porta un nuovo pixel, ogni fornitore che chiede di installare il suo widget spende un po’ del budget di velocità che qualcuno aveva guadagnato mesi prima, e nessuno tiene il conto. Le aziende che restano veloci non sono quelle che hanno fatto l’ottimizzazione migliore: sono quelle in cui esiste una persona autorizzata a dire no a uno script.
Domande frequenti sul page speed
Il punteggio da 0 a 100 non è la valutazione che Google usa per il ranking: nasce da una simulazione singola in laboratorio. Sopra 90 è considerato buono, tra 50 e 89 da migliorare, sotto 50 scarso. Quello che conta davvero è il blocco superiore dello strumento, i dati di campo raccolti dagli utenti reali negli ultimi 28 giorni. Un sito può avere punteggio 62 e superare comunque tutti i Core Web Vitals.
I Core Web Vitals sono tra i segnali che i sistemi di ranking considerano, ma Google scrive nella propria documentazione che non esiste un singolo segnale di page experience e che la Ricerca mostra il contenuto più pertinente anche quando l’esperienza di pagina è scadente. La velocità diventa rilevante quando due pagine sono equivalenti per contenuto e autorevolezza.
Perché la valutazione si basa sul 75° percentile delle visite reali su 28 giorni, non sulla tua navigazione. Se un quarto degli utenti arriva da telefoni lenti o da connessioni congestionate, il valore fuori soglia è il loro. Le cause più frequenti sono un elemento LCP sovradimensionato, come un banner cookie a tutto schermo, e script di terze parti che occupano il processore del dispositivo.
Almeno 28 giorni, perché è la finestra di raccolta dei dati di campo. Nei primi giorni il report mescola le esperienze precedenti e quelle successive all’intervento, quindi un miglioramento reale può sembrare assente. Il punteggio di laboratorio invece cambia subito, ed è il motivo per cui viene usato per verificare che una modifica abbia avuto effetto tecnico.
Quello che risulta fuori soglia nei dati di campo, non quello che il tool segnala per primo. Sul web mobile la metrica più critica è l’LCP, con il 62% di origini in fascia buona secondo il Web Almanac 2025, mentre il CLS è la meno problematica con l’81%. Se sei fuori su più di una metrica, l’LCP è quasi sempre il punto da cui partire perché dipende da un elemento singolo e identificabile.
