Negli ultimi anni il punteggio di Google PageSpeed Insights è diventato una specie di “voto in pagella” per chi gestisce siti WordPress e WooCommerce. Capita spesso che un cliente chieda “perché non siamo a 100?”, come se lo score fosse l’unico obiettivo che conta. Il problema è che un punteggio perfetto su PageSpeed non garantisce un sito veloce per chi lo usa davvero, così come un punteggio medio o basso non vuol dire per forza che l’esperienza sia pessima.
In questo articolo vediamo, in modo concreto:
- come funziona davvero Google PageSpeed Insights e gli strumenti simili;
- la differenza tra lab data e field data (i Core Web Vitals reali);
- perché un punteggio alto può nascondere problemi seri;
- perché un punteggio non stellare può andare benissimo in un contesto business;
- come muoversi se vuoi risultati veri, non solo il numerino verde.
PageSpeed Insights, Lighthouse e simili: cosa misurano davvero
Google PageSpeed Insights usa il motore di Lighthouse per fare un test in ambiente controllato (lab data) e, quando ci sono, affianca a questi 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, e assegna un punteggio da 0 a 100;
- il report mostra anche le metriche reali (LCP, INP, CLS) basate sulle visite vere degli utenti.
Se vuoi approfondire come funziona PageSpeed e la distinzione tra lab e field, c’è la documentazione ufficiale:
Strumenti come GTmetrix o WebPageTest fanno una cosa simile: testano il sito in condizioni simulate, da una certa location e con un profilo di device e rete specifico.
Sono strumenti utili, ma fotografano solo una parte della realtà: la performance in laboratorio, non l’esperienza vera degli utenti in tutte le condizioni possibili.
Lab data e field data: la differenza che conta
Nel mondo delle performance web si parla di due tipi di dati.
Dati di laboratorio (lab data)
- test eseguiti in ambiente controllato, con device e rete simulati;
- ripetibili e confrontabili (stesse condizioni a ogni run);
- utili per debug, test tecnici e sviluppo.
Dati reali (field data)
- raccolti dalle visite vere degli utenti (Chrome User Experience Report, RUM, ecc.);
- includono la 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 ricorda che i Core Web Vitals servono a misurare l’esperienza reale delle persone, 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 1: PageSpeed 95 ma sito “lento” per chi compra
Uno scenario che capita spesso su un ecommerce WooCommerce:
- homepage molto leggera, poche immagini, testo minimo, caricamento quasi statico;
- test PageSpeed (mobile) che segna 95/100 sulla homepage;
- il cliente è contento del numero, ma i dati reali raccontano un’altra cosa.
Guardando i dati veri:
- Core Web Vitals con INP e LCP scadenti sulle pagine prodotto e sul checkout;
- script di tracciamento, chat, sistemi di pagamento e plugin marketing che appesantiscono solo le pagine “calde” (prodotto, carrello, checkout), non la homepage;
- gli utenti si lamentano della lentezza nel completare l’ordine, non nel caricare la home.
Morale: score quasi perfetto sulla pagina testata, ma esperienza reale pessima nel punto più importante del funnel. È il classico caso di ottimizzazione fatta “per il report” e non “per il business”.
Esempio 2: PageSpeed 60 ma sito reattivo e stabile
Altro caso frequente, soprattutto su siti B2B o portali con contenuti complessi:
- layout ricco (tabelle dati, grafici, configuratori di prodotto);
- PageSpeed su mobile intorno a 55–65, penalizzato da JavaScript inevitabile e da qualche risorsa di terze parti;
- ottimizzazione mirata lato server (HTTP/2 o HTTP/3, caching a livello di server, CDN, query ottimizzate).
Nei dati reali però si vede che:
- LCP resta sotto i 2,5s per la maggior parte delle visite;
- INP è sotto i 200ms sulle azioni chiave (click sui 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 altro
Spingere in modo ossessivo verso il 100/100 su PageSpeed porta spesso a scelte tecniche sbagliate, soprattutto su progetti WordPress/WooCommerce complessi:
- rimozione aggressiva di script (tracciamenti, heatmap, strumenti marketing) che hanno un impatto reale sul business;
- lazy loading estremo che introduce flicker e layout shift solo per accontentare il tool;
- staticizzazione forzata di pagine che devono restare dinamiche (carrello, account, prezzi variabili);
- minify e merge eccessivi che rendono debug e manutenzione un incubo e aumentano il rischio di conflitti tra plugin.
In pratica si rischia di sacrificare funzionalità, tracciamento e stabilità per un numero che il cliente può mostrare in uno screenshot, ma che non sempre corrisponde a più conversioni o a un ritorno migliore.
Cosa vuol dire 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 sulle 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 durante campagne ADV, newsletter, picchi di traffico?
- le modifiche che faccio alle performance sono sostenibili, manutenibili e non rompono i flussi critici?
La combinazione che funziona è questa:
- strumenti di laboratorio (PageSpeed, Lighthouse, GTmetrix, WebPageTest) per individuare i problemi tecnici;
- dati reali (Core Web Vitals, RUM, log server, APM) per verificare l’impatto sulle persone.
Come valutare le performance di un sito WordPress/WooCommerce
Un approccio serio alla performance non parte dal numerino, ma da un metodo chiaro:
- Definire le pagine critiche: homepage, pagine prodotto, categorie principali, carrello, checkout, form di contatto.
- Misurare i Core Web Vitals reali: 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 trovare CSS/JS lenti, immagini pesanti, TTFB alto.
- Intervenire dove ha senso: 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 PageSpeed è buono, tanto meglio; se non è perfetto ma le performance reali e i risultati di business sono in linea, non ha senso stravolgere l’architettura solo per rincorrere il 100/100.
Conclusione: lo score è un indicatore, non l’obiettivo
Google PageSpeed Insights e gli strumenti simili sono utilissimi, ma vanno usati per quello che sono: strumenti di diagnosi e supporto, non giudici finali. Un sito davvero performante è quello che:
- carica in tempi adeguati per il suo pubblico reale;
- risponde in fretta alle interazioni chiave (click, tap, compilazione form);
- resta stabile e fluido anche sotto carico;
- supporta tutte le funzionalità che servono 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: portare contatti, vendite e risultati in modo affidabile e misurabile.
Quindi non diventate matti per avere il “verde” e sistemare ogni singolo errore: è praticamente impossibile, e dipende dal template, dai plugin installati, da come è scritto il codice e da ogni impostazione delle pagine a livello SEO, HTML, CSS e JS. Concentratevi di più sull’esperienza utente, provate la velocità voi stessi e, se potete, fatela provare anche a qualcuno di cui vi fidate, che vi dia un’opinione onesta.
ACF in WordPress: come usare Advanced Custom Fields con CPT e WooCommerce
Analisi performance WordPress e WooCommerce lento: checklist completa da controllare
