Di fronte a un PageSpeed Score al 100%, è facile tirare un sospiro di sollievo. Verde ovunque, Core Web Vitals “passed”, performance apparentemente impeccabile.
Eppure, come ha spiegato Karlijn Löwik (CEO di RUMvision) durante il suo intervento al Meet Magento Italy 2025, quel numero spesso non racconta la verità sull’esperienza reale dei tuoi utenti.
Lo speech, dal titolo provocatorio “Why your PageSpeed Score is lying to you”, parte proprio da questa contraddizione: siti che “sulla carta” sono velocissimi, ma che continuano a generare lamentele, carrelli abbandonati e conversioni sotto le aspettative.
Il mito del PageSpeed Score perfetto
Chi lavora su Magento lo conosce bene lo scenario:
“Il sito è lento”
“Impossibile, Lighthouse mi dà 99/100”
Il problema è che Lighthouse e PageSpeed Insights misurano performance sintetiche, non ciò che vivono davvero i clienti.
Karlijn Löwik lo dice chiaramente: un punteggio alto non garantisce una buona esperienza utente.
Nel 2025 la web performance è diventata estremamente complessa:
- Lighthouse
- PageSpeed Insights
- Core Web Vitals
- Google Search Console
- GTmetrix
- WebPageTest
- Real User Monitoring (RUM)
Tutti strumenti utili, ma non equivalenti. Trattarli come se misurassero la stessa cosa porta a conclusioni sbagliate.
Perché la velocità conta davvero (e non per Google)
La velocità non è solo un fattore SEO.
È un fattore di conversione.
Durante lo speech viene ricordato un dato chiave:
- 1 secondo di ritardo può costare circa il 7% delle conversioni
La velocità di un sito non è una fissazione da sviluppatori o un semplice requisito imposto da Google. È una leva di business. Nessuno ama aspettare che una pagina si carichi, soprattutto quando si trova in una fase delicata del funnel come la scheda prodotto o il checkout. Durante lo speech viene ricordato come anche un solo secondo di ritardo possa avere un impatto diretto sulle conversioni, riducendole in modo sensibile.
Per questo Karlijn introduce il concetto di SUX – Site Speed User Experience: non basta che una pagina sia veloce nei test, deve esserlo per le persone reali, nei loro contesti reali.
Core Web Vitals: cosa misurano davvero
Nel 2025 la performance web ruota attorno ai Core Web Vitals: LCP per il caricamento, CLS per la stabilità visiva e INP per l’interattività. Sono metriche importanti, perché rappresentano momenti chiave dell’esperienza utente e sono utilizzate da Google come segnale di ranking.
Il problema nasce quando queste metriche vengono interpretate come una verità assoluta. Karlijn sottolinea come il panorama degli strumenti di misurazione sia diventato estremamente frammentato: Lighthouse, PageSpeed Insights, Search Console, tool di test sintetici e soluzioni di Real User Monitoring convivono, ma misurano cose diverse. Trattarli come equivalenti porta spesso a confusione e a decisioni sbagliate.
Le tre metriche fondamentali:
- LCP – Largest Contentful Paint
Velocità di caricamento percepita - CLS – Cumulative Layout Shift
Stabilità visiva della pagina - INP – Interaction to Next Paint
Reattività dell’interfaccia
sono metriche importanti, ma non esaustive.
Ed è qui che nasce il problema.
Perché Lighthouse “mente” (senza volerlo)
Karlijn Löwik individua diversi limiti strutturali di Lighthouse.
Lighthouse rimane uno strumento utile, ma il suo limite principale è strutturale: è un test di laboratorio. Viene eseguito su dispositivi simulati o sul computer dello sviluppatore, in condizioni che raramente corrispondono a quelle dei veri utenti.
Inoltre Lighthouse osserva solo il caricamento iniziale della pagina. Una volta che il load è completato, il test si ferma. Ma un E-Commerce non finisce di “vivere” dopo il caricamento: ci sono click, interazioni, filtri, variazioni di prodotto, JavaScript che entra in gioco dopo. Tutto questo resta fuori dal perimetro del punteggio.
Il punto centrale dello speech è molto chiaro: Lighthouse non misura persone, misura scenari artificiali. E questo diventa un problema quando il punteggio viene usato come obiettivo finale.
In sostanza:
1. È un test di laboratorio
Lighthouse:
- gira su un device simulato (spesso un Moto G4)
- oppure sul tuo computer super performante
- non rappresenta le condizioni reali dei tuoi utenti
2. Non misura l’esperienza dopo il caricamento
La pagina:
- si carica
- Lighthouse si ferma
Ma l’esperienza utente continua:
- click
- scroll
- interazioni
- caricamenti dinamici
- JavaScript post-load
Tutto questo non viene osservato.
3. Non misura davvero l’interattività reale
- INP non è misurabile correttamente in Lighthouse
- le terze parti (tag, cookie, heatmap, A/B test) sono solo parzialmente considerate
- il Total Blocking Time non sempre corrisponde a un problema percepito dagli utenti
4. Non sono utenti reali
Il punto centrale dello speech:
Lighthouse è un robot. I tuoi utenti no.
Quando il punteggio diventa il problema
Uno degli aspetti più critici evidenziati da Karlijn è il rischio di ottimizzare il sito per “piacere” a Lighthouse. Inseguire il 100/100 porta spesso a soluzioni che funzionano bene nei test ma peggiorano l’esperienza reale, come caricare JavaScript solo al primo click o rimandare troppe risorse critiche.
Il risultato è paradossale: il punteggio sale, ma l’utente percepisce un sito più lento e meno reattivo. Ed è proprio qui che emerge una verità semplice ma spesso dimenticata: gli utenti non vedono il PageSpeed Score, sentono il sito.
Karlijn fa esempi concreti:
- JavaScript caricato solo on-interaction
- lazy loading eccessivo
- soluzioni che “ingannano” Lighthouse
Risultato:
- Lighthouse migliora
- l’utente clicca
- tutto deve caricarsi insieme
- esperienza peggiore
Il punteggio sale, le conversioni scendono.
Field data vs Lab data: la differenza chiave
| Tipo di dato | Cosa misura |
|---|---|
| Lab data (Lighthouse) | Performance simulate |
| Field data (Core Web Vitals, RUM) | Esperienza reale degli utenti |
Google stessa raccomanda di:
dare priorità ai Core Web Vitals di campo rispetto ai punteggi Lighthouse
Anche i Core Web Vitals non raccontano tutta la storia
Superare i Core Web Vitals non significa che tutto vada bene.
Perché?
1. Dati basati sul 75° percentile
- il 25% degli utenti peggiori non è rappresentato
- proprio quelli più lenti, spesso più frustrati
2. Solo utenti Chrome
- Safari, Firefox, Edge, Opera non contano
- ma comprano lo stesso
3. Dati aggregati su 28 giorni
Per un E-Commerce è un’enormità:
- Black Friday
- saldi
- campagne ADV
- banner promozionali
- A/B test
Scoprire dopo 28 giorni che un banner ha rotto il CLS significa aver già perso soldi.
Magento, performance e realtà degli utenti
Uno dei passaggi più interessanti riguarda Magento:
- il TTFB dipende fortemente da:
- hosting
- backend
- caching
- una cattiva strategia di cache può:
- rendere inutili CDN e full page cache
- moltiplicare i tempi di risposta
Esempio concreto citato:
- parametri di tracking (es. Google Shopping, campagne ADV)
- non inclusi nelle regole di cache
- cache miss
- differenze di caricamento enormi (3.000 ms vs 762 ms)
Utenti diversi, esperienze diverse
Un altro messaggio chiave dello speech è che non esiste un’esperienza unica. Connessione, device, memoria, potenza del processore, caching del browser e tipo di navigazione influiscono enormemente sulle prestazioni percepite. Un iPhone di fascia alta e uno smartphone Android di fascia media possono vivere lo stesso sito in modo completamente diverso, ma questa differenza raramente emerge dai dati aggregati.
Il Real User Monitoring serve proprio a questo: osservare cosa succede davvero, senza supposizioni.
Nessun utente in sostanza vive lo stesso sito nello stesso modo:
- connessioni lente
- telefoni di fascia media
- device datati
- utenti nuovi vs utenti di ritorno
- cache del browser
- back/forward cache
- speculative rules
Gli utenti nuovi, spesso arrivati da campagne a pagamento, sono quelli:
- con meno cache
- con esperienza peggiore
- più difficili da convertire
Ed è proprio su di loro che Core Web Vitals spesso non dà visibilità sufficiente.
Interattività e device: un dato invisibile a Google
Altro punto chiave:
- iPhone → interazioni più fluide
- device Android di fascia media → peggiori performance
Questo:
- non emerge dai Core Web Vitals
- ma incide sull’esperienza reale
La memoria del device viene usata come proxy per identificare device più vecchi e meno performanti.
La performance è un lavoro di squadra
Secondo Karlijn, non esiste una soluzione unica. Servono:
- sviluppatori consapevoli della web performance
- dati reali (RUM) + dati sintetici
- frontend ottimizzato (es. Hyvä)
- hosting adeguato a Magento
- backend ottimizzato
- regole di caching intelligenti
- SEO e marketing coinvolti nelle scelte sulle terze parti
Senza comunicazione, il risultato è:
- JavaScript in eccesso
- cookie manager pesanti
- rendering client-side
- cache inefficace
- utenti su device lenti penalizzati
L’“ultimate web performance setup”
Il flusso suggerito nello speech è chiaro:
- Identifica il problema più grave per gli utenti reali (RUM)
- Riproducilo con strumenti di test (DevTools, WebPageTest)
- Correggilo nel codice
- Usa Lighthouse in CI/CD per evitare regressioni
- Valida il fix con dati reali
- Monitora costantemente
Lighthouse non va eliminato, va usato nel contesto giusto.
Il vero “flex” nel 2025
Se non puoi più vantarti del 100/100 su Lighthouse, qual è il vero obiettivo?
Secondo Karlijn:
99% delle pagine critiche performanti al 90° percentile
Quello sì che significa:
- utenti soddisfatti
- conversioni più alte
- Magento performante
- business sano
E sì, lo shop mostrato come esempio finale era un Magento, tra i più veloci nel dataset analizzato.
La performance come lavoro di squadra
Migliorare la performance non è responsabilità di un singolo ruolo. Servono sviluppatori consapevoli, dati affidabili, frontend ottimizzati, hosting adeguato, backend sotto controllo e una collaborazione reale con marketing e SEO, soprattutto quando entrano in gioco terze parti, script e strumenti di tracciamento.
L’accumulo di piccoli “aggiustamenti” non coordinati – un nuovo banner, un A/B test, una heatmap, un cookie manager – può trasformarsi rapidamente in un problema serio per gli utenti su device meno performanti.
Conclusione
Il messaggio dello speech è chiaro:
- il PageSpeed Score è un numero
- l’esperienza utente è realtà
- ottimizzare per i punteggi è una scorciatoia pericolosa
- ottimizzare per gli utenti è ciò che fa crescere un E-Commerce
Nel 2025, misurare meglio vale più che misurare di più.
E su Magento, questo fa la differenza tra un sito “verde” e uno che vende davvero.