Google PageSpeed Insights vs prestazioni reali: perché un punteggio alto non basta
Negli ultimi anni il punteggio di Google PageSpeed Insights è diventato una sorta di “voto in pagella” per chi gestisce siti WordPress e WooCommerce. Molti clienti chiedono: “Perché non siamo a 100?” come se lo score fosse l’unico obiettivo. Il punto è che un punteggio perfetto su PageSpeed non garantisce automaticamente un sito veloce per gli utenti reali, così come un punteggio medio o basso non significa per forza che l’esperienza sia pessima.
In questo articolo vediamo in modo professionale e concreto:
- come funziona davvero Google PageSpeed Insights e strumenti simili
- la differenza tra lab data e field data (Core Web Vitals reali)
- perché un punteggio alto può mascherare problemi seri
- perché un punteggio non stellare può essere comunque accettabile in un contesto business
- approccio corretto per chi vuole risultati, non solo numeri verdi
PageSpeed Insights, Lighthouse e strumenti simili: cosa misurano davvero
Google PageSpeed Insights utilizza il motore di Lighthouse per eseguire un test in ambiente controllato (lab data) e, quando disponibile, affianca a questi dati i Core Web Vitals reali raccolti dal Chrome User Experience Report (field data). In pratica:
- Lighthouse simula il caricamento della pagina su un dispositivo mobile “medio” con rete rallentata, assegnando un punteggio da 0 a 100.
- Il report mostra anche metriche reali (LCP, INP, CLS) basate sulle visite vere degli utenti.
Per approfondire il funzionamento di PageSpeed Insights e della distinzione lab/field, puoi vedere la documentazione ufficiale:
Strumenti come GTmetrix o WebPageTest fanno qualcosa di simile: testano il tuo sito in condizioni simulate, da una determinata location e con un device/profilo di rete specifico.
Questi strumenti sono preziosi, ma fotografano solo una parte della realtà: la performance in laboratorio, non l’esperienza completa degli utenti reali in tutte le condizioni possibili.
Lab data vs field data: la differenza che conta davvero
Nel mondo delle performance web si parla di due tipologie di dati:
Dati di laboratorio (lab data)
- Test eseguiti in ambiente controllato, con device e rete simulati.
- Ripetibili e comparabili (stesse condizioni ad ogni run).
- Ideali per debug, test A/B tecnici, sviluppo.
Dati reali (field data)
- Raccolti dalle visite vere degli utenti (Chrome User Experience Report, RUM, ecc.).
- Includono variabilità di rete, device, browser, geolocalizzazione, cache, CDN.
- Rappresentano la vera esperienza utente, quella che conta per il business e per i segnali di ranking legati ai Core Web Vitals.
Google stessa sottolinea che i Core Web Vitals sono pensati per misurare la real-world user experience, non solo il risultato di un singolo test in laboratorio.
Per analizzare i dati reali puoi usare, ad esempio:
- Google Search Console – Report Core Web Vitals
- PageSpeed Insights (sezione Field Data)
- strumenti di Real User Monitoring (RUM) di terze parti come New Relic o Datadog
Esempio reale 1: PageSpeed 95 ma sito “lento” per chi compra
Scenario concreto in un ecommerce basato su WooCommerce:
- Homepage molto leggera, poche immagini, testo minimale, caricamento quasi statico.
- Test di PageSpeed (mobile) che segna 95/100 sulla homepage.
- Il cliente è contento del numerino, ma i dati reali mostrano altro:
- Report Core Web Vitals: INP e LCP scadenti sulle pagine prodotto e sul checkout.
- Script di tracciamento, chat, sistemi di pagamento e plugin marketing appesantiscono solo le pagine “calde” (product, cart, checkout), non la homepage.
- Gli utenti lamentano lentezza nel completare l’ordine, non nel caricare la home.
Risultato: score quasi perfetto sulla pagina testata, ma esperienza reale pessima nel punto cruciale del funnel. È un esempio classico di ottimizzazione “da report” e non “da business”.
Esempio reale 2: PageSpeed 60 ma sito reattivo e stabile per gli utenti
Altro scenario comune, soprattutto su siti business B2B o portali con contenuti complessi:
- Layout ricco (tabelle dati, grafici, script di configurazione prodotti).
- PageSpeed su mobile intorno a 55–65, penalizzato da JavaScript inevitabile e da alcune risorse di terze parti.
- Ottimizzazione mirata lato server (HTTP/2 o HTTP/3, caching a livello di server, CDN, query database ottimizzate).
Nei dati reali però si vede che:
- LCP rimane sotto i 2,5s per la maggior parte delle visite.
- INP è sotto i 200ms per le azioni chiave (click su pulsanti, tab, filtri).
- CLS è praticamente nullo perché il layout è stabile.
La navigazione è fluida, il sito risponde bene, i form funzionano, i funnel non hanno attrito. Il punteggio PageSpeed non è “da poster”, ma la performance percepita dagli utenti è più che sufficiente per il business.
Perché inseguire il 100/100 può fare più danni che benefici
Spingere ossessivamente verso il 100/100 su PageSpeed Insights porta spesso a scelte tecniche sbagliate, soprattutto in progetti complessi su WordPress/WooCommerce:
- Rimozione aggressiva di script (es. tracciamenti, heatmap, strumenti marketing) che hanno un impatto reale sul business.
- Lazy loading estremo che introduce flicker e layout shift indesiderati solo per soddisfare il tool.
- SSR/Staticizzazione forzata di pagine che in realtà devono restare dinamiche (carrello, account, pricing variabili).
- Minify/merge eccessivo che rende debug e manutenzione un incubo, aumentando rischio di conflitti tra plugin.
In altre parole, si rischia di sacrificare funzionalità, tracciamento e stabilità sull’altare di un numero che il cliente può screennare, ma che non sempre corrisponde a maggiori conversioni o a un ROI migliore.
Cosa significa davvero “sito performante” per un business
Per un’azienda che usa WordPress o WooCommerce la domanda giusta non è “siamo a 100 su PageSpeed?”, ma:
- La pagina più importante (prodotto, landing, form contatti, checkout) carica e risponde in tempi accettabili sui device e reti reali dei miei utenti?
- Le metriche Core Web Vitals reali sono entro le soglie consigliate per la maggior parte delle visite?
- Il sito regge il carico sotto campagne ADV, newsletter, peak di traffico?
- Le modifiche che faccio alle performance sono sostenibili, manutenibili e non rompono i flussi critici?
In questo senso, la combinazione vincente è:
- strumenti di laboratorio (PageSpeed, Lighthouse, GTmetrix, WebPageTest) per individuare i problemi tecnici
- dati reali (Core Web Vitals, RUM, log server, APM) per validare l’impatto sulle persone
Come valutare correttamente le performance di un sito WordPress/WooCommerce
Un approccio professionale alla performance non parte dal numerino, ma da una metodologia chiara:
- Definire le pagine critiche Homepage, pagine prodotto, categorie principali, carrello, checkout, form lead.
- Misurare i Core Web Vitals reali Usare Search Console, PageSpeed (Field Data) e, se possibile, un sistema di RUM.
- Usare i tool di laboratorio per capire il perché Lighthouse, WebPageTest, DevTools per individuare CSS/JS lenti, immagini pesanti, TTFB alto.
- Intervenire dove ha senso Ottimizzare server, cache, query, risorse statiche, immagini, codice JS bloccante.
- Misurare di nuovo e confrontare Non solo PageSpeed, ma tempi reali, tassi di conversione, bounce rate.
A quel punto, se lo score di PageSpeed è buono, meglio; se non è perfetto ma le performance reali e i risultati di business sono in linea, non ha senso distruggere l’architettura solo per inseguire il 100/100.
Conclusione: score come indicatore, non come obiettivo
Google PageSpeed Insights e strumenti simili sono utilissimi, ma vanno usati per quello che sono: strumenti di diagnosi e supporto, non giudici finali assoluti. Un sito davvero performante è quello che:
- carica in tempi adeguati per il suo pubblico reale
- risponde rapidamente alle interazioni chiave (click, tap, compilazione form)
- rimane stabile e fluido anche sotto carico
- supporta tutte le funzionalità necessarie al business
Il punteggio di PageSpeed è un buon indicatore, ma non è il KPI finale. L’obiettivo non è avere un grafico verde, ma un WordPress/WooCommerce che fa il suo lavoro: generare contatti, vendite e risultati, in modo affidabile e misurabile.
Per cui non diventate matti per avere il “verde” e la correzione di tutti gli errori, è praticamente impossibile, dipende dal template, dai plugins installati, come sono stati scritti i codici, da ogni impsotazione delle pagine a livello SEO, HTML, CSS e JS, concentrati più sull’esperienza utente e verificate la velocità voi stessi e fatelo fare se possibile anche a qualche persona di cui vi fidate e chi vi dia un’opinione onesta.
