Perché PageSpeed dà 68 su mobile e 96 su desktop
Abbiamo misurato la nostra homepage quattro volte in un quarto d'ora. Sono usciti 96, 90, 85 e 68. Stessa pagina, stesso giorno, nessuna modifica in mezzo. La differenza non è il sito: è chi tiene il cronometro.
Cosa è successo. Il 7 agosto abbiamo passato la homepage di cittago.com a PageSpeed Insights e, dieci minuti dopo, allo stesso identico strumento fatto girare dal nostro server. Il punteggio prestazioni è uscito 68 la prima volta e 90 la seconda. Sul desktop 96 e 99. Nel mezzo non abbiamo toccato niente.
Per chi non vale. Se il tuo sito ha già abbastanza traffico da mostrare i dati degli utenti reali — il riquadro in cima al rapporto, quello che a noi dice „No Data“ — guarda quelli e chiudi questa pagina. Sono migliori di qualunque simulazione.
Perché conviene leggerlo. Perché il punteggio mobile è la cosa che più spesso fa spendere soldi nel posto sbagliato. Qui trovi da dove nasce, quanto oscilla e quali due righe del rapporto valgono più del numero grande.
- Quanto cambia il punteggio della stessa pagina da una macchina all'altra: l'abbiamo misurato, sono 22 punti.
- Quanto oscilla tra due corse consecutive sulla stessa macchina, a tredici secondi di distanza.
- Quale metrica pesa il 30% del voto, e perché quasi nessuno la guarda.
- Cosa pesa davvero sulla nostra homepage, in byte, con il conto sotto gli occhi.
Apri pagespeed.web.dev, incolla l'indirizzo del tuo sito, aspetta trenta secondi. Esce un cerchio con un numero dentro. Se è verde ti rilassi, se è arancione ti si stringe lo stomaco, e se qualcuno te lo manda per email con scritto „il sito è lento“ parte una settimana di lavoro.
Il 7 agosto quel numero, per la nostra homepage, era 68. Dieci minuti dopo, la stessa pagina misurata con lo stesso programma nella stessa versione, faceva 90. Nel frattempo non avevamo cambiato una virgola.
Non è un bug e non è una scusa. È il modo in cui funziona la misurazione, e il giorno in cui lo capisci smetti di rincorrere un cerchio colorato e cominci a guardare le due righe che contano davvero.
Facciamo ottimizzazione della velocità delle pagine per i clienti e teniamo online un test di velocità del sito gratuito, quindi questi rapporti li leggiamo tutti i giorni. Il sito nuovo di Cittago è online dal 6 luglio 2026, il primo articolo è del 12 luglio e il lavoro serio sui contenuti è partito il 27. È un sito giovane, con i suoi difetti al sole: perfetto per fare la prova in pubblico invece che su un esempio inventato.
Cos'è il punteggio di PageSpeed Insights
Definizione. Il punteggio prestazioni di PageSpeed Insights è il voto da 0 a 100 che Lighthouse assegna a un singolo caricamento di una singola pagina, simulato su un telefono economico con una rete lenta, combinando cinque misure di tempo in una media pesata.
Ogni parola di quella frase serve. Un solo caricamento: non una media della settimana. Una sola pagina: non il sito. Simulato: nessun utente reale è coinvolto. Telefono economico e rete lenta: è una prova da sforzo, non la giornata media del tuo cliente.
Le fasce di colore sono documentate da Google: 0–49 rosso, 50–89 arancione, 90–100 verde (documentazione Lighthouse). Un 68 finisce quindi in mezzo alla fascia arancione, che è la più larga delle tre e la più ansiogena, perché non ti dice né che stai bene né che stai male.
Quattro numeri per la stessa pagina, in quindici minuti
Ecco cosa abbiamo fatto, nell'ordine. Prima due corse su PageSpeed Insights, mobile e desktop, alle 13:32. Poi, dal nostro server, quattro corse di Lighthouse — lo stesso motore che gira dentro PageSpeed Insights — tra le 13:42 e le 13:45.
| Chi misura | Modalità | Punteggio | LCP | Blocco (TBT) | Ora |
|---|---|---|---|---|---|
| PageSpeed Insights | mobile | 68 | 7,0 s | 190 ms | 13:32 |
| Il nostro server | mobile, 2ª corsa | 85 | 2,7 s | 420 ms | 13:42 |
| Il nostro server | mobile, 1ª corsa | 90 | 1,8 s | 340 ms | 13:42 |
| PageSpeed Insights | desktop | 96 | 0,7 s | 150 ms | 13:32 |
| Il nostro server | desktop | 99 | 0,8 s | 0 ms | 13:43 |
Fonte: rapporti PageSpeed Insights del 7 agosto 2026 (schermate qui sotto) e rapporti Lighthouse 13.4.1 generati in un container sul nostro server lo stesso giorno. Pagina misurata: https://cittago.com/. Nessuna modifica al sito tra la prima e l'ultima corsa. Le righe sono ordinate dal punteggio più basso al più alto.
Ventidue punti di differenza tra due misurazioni mobili della stessa pagina, a dieci minuti l'una dall'altra, con la stessa versione di Lighthouse. Se ti hanno mandato uno screenshot con scritto „guarda che disastro“, la prima domanda utile non è „cosa sistemiamo“. È „chi ha fatto la prova, e da dove“.
Guarda le altre tre colonne per un secondo. Accessibilità 100, best practices 100, SEO 100 — identiche in tutt'e due le prove. Quelle categorie sono liste di controllo: o l'attributo c'è o non c'è. Le prestazioni no. Le prestazioni sono un cronometro, e un cronometro dipende da chi corre.
Accessibilità, SEO e best practices ti dicono cosa hai fatto. Le prestazioni ti dicono com'è andata quella volta lì.
La macchina di Google e la nostra non hanno visto lo stesso sito
Le due corse mobili avevano la stessa configurazione, e non a occhio: sta scritta dentro i rapporti. Telefono emulato moto g power (2022), schermo 412×823, rete simulata con 150 ms di latenza e circa 1,6 Mbps, processore rallentato di quattro volte. Lighthouse 13.4.1 in tutt'e due i casi.
Eppure i risultati raccontano due storie diverse, e la cosa interessante è che non si contraddicono: descrivono due colli di bottiglia diversi.
| Metrica | PageSpeed Insights | Il nostro server | Cosa racconta |
|---|---|---|---|
| Blocco del processore (TBT) | 190 ms | 340 ms | La macchina di Google ha lavorato di CPU meglio della nostra |
| Comparsa dell'elemento più grande (LCP) | 7,0 s | 1,8 s | Ma ha impiegato quasi quattro volte tanto a ricevere la pagina |
| Primo contenuto a schermo (FCP) | 2,9 s | 1,7 s | Anche l'inizio è arrivato più tardi |
| Punteggio finale | 68 | 90 | Il ritardo di consegna vale più della potenza di calcolo |
Confronto tra il rapporto PageSpeed Insights mobile del 7 agosto 2026 e la prima corsa Lighthouse mobile dello stesso giorno dal nostro server. Le impostazioni di emulazione e di rallentamento sono identiche; cambiano la macchina fisica e la distanza di rete tra chi misura e il sito.
Tradotto: il processore della macchina di Google era più veloce del nostro, quindi ha masticato il JavaScript prima. Ma la pagina, in byte, le è arrivata molto più lentamente. E siccome la comparsa dell'elemento più grande pesa il 25% del voto, quel ritardo si porta via il punteggio.
Perché la consegna cambia così tanto? Perché tra chi misura e il tuo server ci sono chilometri, un CDN e, quasi sempre, qualche controllo di sicurezza. Sono le stesse tre cose che cambiano per il tuo cliente a Bergamo rispetto al tuo cliente a Palermo. Non è un difetto della prova: è il pezzo di realtà che la prova include e che tu non controlli.
Confronta punteggi solo se vengono dalla stessa fonte. Il numero di PageSpeed Insights di oggi si confronta con quello di PageSpeed Insights di martedì scorso, non con quello che ti ha mandato l'agenzia dal suo portatile. Sono due termometri diversi, e nessuno dei due è rotto.
Due corse a tredici secondi: 90 e 85
Poi abbiamo fatto la prova più scomoda: la stessa macchina, la stessa pagina, due volte di fila. Tra la fine della prima e l'inizio della seconda sono passati tredici secondi.
Prima corsa: 90. Seconda corsa: 85. La comparsa dell'elemento più grande è passata da 1,8 a 2,7 secondi, il blocco del processore da 340 a 420 millisecondi. Stesso container, stesso indirizzo, stesso identico comando.
Cinque punti sono la distanza che separa un rapporto „verde“ da un rapporto „arancione“ quando sei sul bordo dei 90. Google elenca fra le cause della fluttuazione il routing del traffico, le differenze tra i dispositivi, le estensioni del browser e persino l'antivirus. Noi ne aggiungiamo una molto più banale, che vediamo tutti i giorni: la macchina che misura sta facendo anche altro.
La regola che ne segue è noiosa e fa risparmiare settimane: tre corse, prendi quella di mezzo. Se corri una volta sola stai misurando anche il rumore, e poi passi il pomeriggio a cercare la causa di cinque punti che non esistono.
Il voto è una media di cinque cronometri
Il numero grande non è una misura: è una media pesata di cinque misure. I pesi sono pubblici e valgono la pena di essere imparati, perché ti dicono su cosa vale la pena lavorare.
| Metrica | Peso | In parole povere |
|---|---|---|
| Total Blocking Time | 30% | Per quanto tempo la pagina non risponde ai tuoi tocchi perché il telefono sta eseguendo codice |
| Largest Contentful Paint | 25% | Quando compare l'elemento più grande della schermata iniziale: di solito la foto grande o il titolo |
| Cumulative Layout Shift | 25% | Quanto la pagina balla mentre carica, spostandoti sotto il dito il pulsante che stavi per premere |
| First Contentful Paint | 10% | Quando compare il primo pixel di contenuto, qualunque esso sia |
| Speed Index | 10% | Quanto in fretta la parte visibile si riempie, nel complesso |
Pesi pubblicati da Google nella documentazione sul calcolo del punteggio Lighthouse, letta il 7 agosto 2026. Google ha cambiato i pesi in passato e può rifarlo: prima di usarli in una decisione, ricontrolla la pagina.
La riga in cima è quella che sorprende tutti. Il fattore singolo più pesante non è la velocità con cui la pagina appare, ma per quanto tempo resta sorda ai tuoi tocchi. Trenta per cento del voto per una cosa che quasi nessuno guarda, perché nel rapporto sta in basso a destra ed è scritta in millisecondi.
Ha anche una conseguenza pratica scomoda: comprimere le immagini è il lavoro più facile e più visibile, ma tocca il 25% del voto nel migliore dei casi. Il codice che gira all'avvio ne tocca il 30%, e quasi sempre non è tuo.
„No Data“: la riga che nessuno legge
In cima al rapporto c'è un riquadro che si chiama Discover what your real users are experiencing. Sul nostro rapporto, in tutt'e due le modalità, dice No Data.
Quel riquadro è l'unica parte del rapporto che parla di persone vere. Contiene i dati raccolti da Chrome sui visitatori reali del tuo sito negli ultimi 28 giorni, e compare solo se il traffico è abbastanza da rendere il campione affidabile. Il nostro sito è online da un mese: non lo è.
Quindi tutti e quattro i nostri numeri sono simulazioni. Sono utili — una simulazione ripetuta ti dice se una modifica ha migliorato o peggiorato le cose — ma nessuno di loro è l'esperienza di un cliente.
1. Dati di campo (il riquadro in alto, se c'è): quello che è successo ai tuoi visitatori. Vince su tutto.
2. Dati di laboratorio (il punteggio): una prova ripetibile, buona per confrontare prima e dopo.
3. Il numero preso una volta sola: un aneddoto.
Se hai traffico e il riquadro è pieno, il tuo lavoro è lì. Se il riquadro è vuoto come il nostro, il punteggio di laboratorio è quello che hai, e va usato per quello che sa fare: confrontare la stessa pagina con sé stessa, misurata sempre allo stesso modo.
Il 51,6% della nostra homepage sono tag di misurazione
Fin qui abbiamo parlato di quanto il punteggio dipenda da chi misura. Adesso la parte che dipende da noi, con i byte contati.
La nostra homepage, nella corsa delle 13:42, ha scaricato 950.782 byte in 28 richieste. Ecco da dove vengono.
| Da dove arriva | Byte | Quota | Cosa è |
|---|---|---|---|
| googletagmanager.com | 491.069 | 51,6% | Tag Manager, Google Analytics 4 e il tag di Google Ads |
| cittago.com | 446.841 | 47,0% | La pagina, i caratteri tipografici, le immagini, il nostro codice |
| static.cloudflareinsights.com | 11.577 | 1,2% | Le statistiche del CDN |
| Altri due domini Google | 1.295 | 0,1% | Chiamate di invio dati |
Fonte: sezione network-requests del rapporto Lighthouse generato dal nostro server il 7 agosto 2026 alle 13:42 su https://cittago.com/. I byte sono quelli trasferiti, già compressi.
Più della metà del peso della nostra homepage sono strumenti che servono a misurare, non a mostrare. I tre file più grossi della pagina sono, nell'ordine, il tag di Analytics (191 KB), il tag di Google Ads (181 KB) e il container di Tag Manager (119 KB). Il documento HTML, per confronto, pesa 56 KB.
Cosa succede se li togli? L'abbiamo fatto, alle 13:45, con la stessa macchina e lo stesso comando più una riga che blocca quel dominio.
| Stessa pagina, stessa macchina | Con i tag | Senza i tag |
|---|---|---|
| Punteggio prestazioni | 90 / 85 | 95 |
| Blocco del processore (TBT) | 340–420 ms | 200 ms |
| Pagina pronta all'uso (TTI) | 6,8 s | 3,7 s |
| Peso totale | 950 KB | ~460 KB |
Corse Lighthouse 13.4.1 mobile dal nostro server, 7 agosto 2026, 13:42 e 13:45. La colonna „senza i tag“ è ottenuta bloccando le richieste verso googletagmanager.com; il peso totale è il totale meno la quota di quel dominio.
Cinque punti di punteggio e tre secondi di attesa in meno prima che la pagina risponda ai tocchi. E qui arriva la parte poco eroica: quei tag restano. Ci servono per sapere quali pagine portano richieste e quali no, e quel dato vale più di cinque punti su un cronometro simulato.
È una scelta, non una svista. Ma è una scelta che va fatta con il numero davanti, non per abitudine. La domanda giusta non è „come faccio 100“: è „cosa sto comprando con i punti che sto spendendo“. Se hai tre tag di remarketing attivi per campagne finite l'anno scorso, li stai pagando ogni volta che qualcuno apre il sito dal telefono in centro.
Cosa ti serve per rifare la prova
Tutto quello che abbiamo fatto lo puoi rifare oggi, sul tuo sito, senza installare nulla. Serve questo:
- L'indirizzo esatto della pagina che porta i soldi. Non la homepage per abitudine: la scheda prodotto, la pagina del servizio, il modulo di contatto.
- Due minuti per fare tre corse invece di una, e prendere quella di mezzo.
- Un posto dove annotare i cinque numeri, con la data. Un foglio di calcolo basta e avanza. Senza lo storico, ogni misurazione è il primo giorno di scuola.
- La stessa fonte, ogni volta. Se cominci con PageSpeed Insights, continua con PageSpeed Insights.
- Chrome sul tuo computer, se vuoi anche la versione locale: il pannello Lighthouse è dentro gli strumenti per sviluppatori, e misura dalla tua rete.
Se preferisci un riepilogo già masticato, il nostro test di velocità del sito fa la prova e ti restituisce i numeri con la spiegazione accanto, senza registrazione.
Cosa il punteggio non dice
| Cosa misura | Cosa non puoi concludere |
|---|---|
| Un caricamento di una pagina | Non dice niente sul resto del sito. Il carrello può essere il doppio più lento della homepage. |
| Un telefono simulato su rete lenta | Non è il telefono del tuo cliente. Può essere peggio o molto meglio. |
| Il primo caricamento, a cache vuota | Chi torna sul sito ha già caratteri e immagini in memoria e vede tutt'altro. |
| Un numero da 0 a 100 | Non è un fattore di posizionamento. Google usa i dati di campo, non il tuo punteggio. |
| Le nostre corse dal nostro server | Misurare il proprio sito dalla propria macchina è comodo e un po' compiacente: sei vicino, e a volte in lista bianca. Non usarlo come prova di velocità per il mondo. |
L'ultima riga vale anche per noi, ed è il motivo per cui in questo articolo il numero più brutto, 68, è quello di Google e non il nostro. Se avessimo pubblicato solo il 90 misurato in casa, avremmo scritto un articolo più comodo e meno vero.
Le parole, in una tabella
| Termine | Cosa vuol dire |
|---|---|
| Lighthouse | Il programma di Google che esegue la prova. Gira dentro PageSpeed Insights, dentro Chrome e da riga di comando. |
| PageSpeed Insights | Il sito pubblico che fa girare Lighthouse sui server di Google e ti mostra il rapporto. |
| Dati di laboratorio | Una prova simulata, ripetibile, senza utenti reali. |
| Dati di campo | Le misure raccolte da Chrome sui visitatori veri, sugli ultimi 28 giorni. |
| Core Web Vitals | Le tre metriche che Google considera principali: LCP, INP e CLS. Il punteggio Lighthouse ne usa altre. |
| Throttling | Il rallentamento artificiale di rete e processore che rende la prova severa e confrontabile. |
| Emulazione | Chrome che finge di essere un telefono: schermo, densità dei pixel e nome del dispositivo. |
Come si legge in dieci minuti
- Guarda il riquadro in alto, quello dei visitatori reali. Se ha dei numeri, il resto del rapporto diventa secondario: lavora su quelli.
- Fai tre corse e prendi quella di mezzo. Una sola corsa non è una misura, è un'impressione.
- Ignora il cerchio, leggi le cinque righe. Il numero grande non ti dice cosa fare; le metriche sì.
- Parti dal blocco del processore, il TBT. Pesa il 30% e quasi sempre viene da codice di terze parti: tag, chat, banner dei cookie, widget di recensioni.
- Poi guarda la comparsa dell'elemento più grande, il LCP. Nove volte su dieci è l'immagine in cima. Se è un video o un carosello, hai trovato il tuo pomeriggio.
- Guarda il film del caricamento. Due fotogrammi bianchi all'inizio significano attesa di consegna; una pagina che si compone a scatti significa codice.
- Misura la pagina che porta i soldi, non la homepage, e rimisurala dopo ogni modifica — una modifica alla volta, altrimenti non saprai quale ha contato.
Dove ti trovi, in tre soglie
Se il riquadro dei dati reali è pieno e i tuoi valori sono nel verde, hai finito. Il punteggio di laboratorio è una curiosità. Torna a occuparti di quello che vendi.
Se il riquadro è pieno e i valori sono nel rosso, hai un problema vero, e lo hai con le persone, non con un simulatore. Comincia dalla metrica peggiore e non guardare il punteggio finché non l'hai spostata.
Se il riquadro è vuoto come il nostro, sei in laboratorio. Va benissimo: scegli una fonte, fai tre corse, scrivi i cinque numeri con la data e ripeti dopo ogni modifica. In un mese avrai una linea, e una linea vale più di dieci screenshot.
Da noi il riquadro si riempirà quando ci sarà abbastanza traffico. Quel giorno pubblichiamo i dati veri accanto a questi, e vediamo di quanto ci eravamo sbagliati. Ne riparliamo fra tre-sei mesi 😉
Domande
Domande che nessuno ci ha ancora fatto
Nessuno ci ha scritto per chiedercelo: l'articolo è di oggi. Sono le domande che verrebbero a chi legge, più quelle che escono davvero nelle conversazioni con i clienti quando arriva lo screenshot arancione.
Perché il punteggio mobile è sempre più basso di quello desktop?
Perché le due prove non usano la stessa macchina immaginaria. La prova mobile simula un telefono di fascia economica su una rete lenta, con il processore rallentato di quattro volte; quella desktop simula un computer veloce su una rete veloce. Il tuo sito è identico, cambia chi lo apre.
Nel nostro caso: 96 sul desktop e 68 sul mobile, stessa pagina, stesso minuto.
Il punteggio di PageSpeed conta per il posizionamento su Google?
Il punteggio in sé no. Quello che Google usa nel ranking sono i Core Web Vitals misurati sugli utenti reali, cioè il riquadro in cima al rapporto, non il numero grande sotto. Sono cose diverse: puoi avere 62 di punteggio e Core Web Vitals tutti verdi.
Il che, detto senza giri di parole, significa che rincorrere il cerchio verde è spesso lavoro speso male.
Quale punteggio è „buono“ per un sito aziendale?
La fascia verde parte da 90 ed è un ottimo obiettivo per una pagina di contenuto. Su un e-commerce con chat, recensioni, pixel pubblicitari e un banner dei cookie, arrivare stabilmente sopra 80 sul mobile è già un buon risultato.
Più utile del valore assoluto è la direzione: dove eri il mese scorso e dove sei adesso, misurato allo stesso modo.
Ho fatto la prova due volte e ho avuto due numeri diversi. Ho sbagliato qualcosa?
No, è normale. Nelle nostre due corse consecutive, a tredici secondi di distanza sulla stessa macchina, sono usciti 90 e 85.
La differenza nasce dal traffico di rete del momento, dal carico della macchina che misura e da mille dettagli che cambiano tra un caricamento e l'altro. Per questo si fanno tre corse e si prende quella di mezzo.
Devo togliere Google Analytics per fare più punti?
Puoi, e il guadagno è misurabile: sul nostro sito bloccare i tag ha portato il punteggio da 90 a 95 e ha tolto tre secondi al tempo in cui la pagina diventa reattiva. Ma poi non sai più da dove arrivano le richieste di preventivo.
La cosa sensata è un inventario: quali tag hai, a cosa serve ciascuno, chi guarda quei dati. Quelli che nessuno guarda da sei mesi sono peso puro.
Il banner dei cookie mi rovina il punteggio?
Spesso sì, e in due modi. È codice che gira all'avvio, quindi entra nel blocco del processore che pesa il 30%. E se copre lo schermo, può diventare lui l'elemento più grande della prima schermata, cioè quello che il cronometro aspetta.
Non è un buon motivo per toglierlo: il consenso serve. È un buon motivo per sceglierne uno leggero e per caricarlo bene.
Il mio hosting è lento o è il sito?
C'è una riga del rapporto che risponde quasi da sola: il tempo di risposta del server, cioè quanto ci mette ad arrivare la prima parte del documento. Nella nostra corsa erano 30 millisecondi.
Se quel numero è alto e tutto il resto è ragionevole, il problema è a monte del sito. Se è basso e il punteggio resta arancione, il problema è quello che il sito fa dopo essere arrivato.
Le immagini sono davvero il problema principale?
Sono il primo problema che è facile vedere, non necessariamente il primo per importanza. Le immagini toccano soprattutto la comparsa dell'elemento più grande, che pesa il 25%. Il codice che gira all'avvio tocca il blocco del processore, che pesa il 30%.
Detto questo, un'immagine da tre megabyte in cima alla pagina resta il modo più rapido di rovinare tutto, e sistemarla costa dieci minuti.
Posso confrontare il mio punteggio con quello di un concorrente?
Sì, ed è uno dei pochi confronti onesti disponibili, perché PageSpeed Insights funziona su qualunque indirizzo pubblico. Con un'accortezza: fallo lo stesso giorno, con lo stesso strumento, e su pagine dello stesso tipo — scheda prodotto contro scheda prodotto, non la sua homepage contro il tuo carrello.
E ripeti tre volte anche sul suo, altrimenti stai confrontando il tuo dato medio con il suo giorno storto.
Da dove comincio se ho un solo pomeriggio?
Nell'ordine: fai l'inventario dei tag ed elimina quelli morti; controlla che l'immagine in cima alla pagina non pesi più di un centinaio di kilobyte e che non sia nascosta da un'animazione di comparsa; misura tre volte prima e tre volte dopo.
Se dopo questo sei ancora nell'arancione, il problema è strutturale e non si risolve in un pomeriggio. Ma almeno sai che non era polvere: parte da qui il nostro lavoro di ottimizzazione della velocità, con la stessa sequenza di misure.
Ultimo aggiornamento: 7 agosto 2026. Le cifre vengono da due rapporti PageSpeed Insights su https://cittago.com/ eseguiti il 7 agosto 2026 alle 13:32 (fuso GMT+3) e da quattro rapporti Lighthouse 13.4.1 generati in un container sul nostro server tra le 13:42 e le 13:45 dello stesso giorno. I pesi delle metriche sono quelli della documentazione Lighthouse consultata in pari data. Aggiorniamo la pagina quando cambiano i pesi o quando il nostro rapporto smette di dire „No Data“.
