Core Web Vitals di Initpc: desktop superato, mobile in lavorazione

Un e-commerce con oltre 280.000 prodotti non si velocizza una volta per tutte: si velocizza per strati, si misura, e poi si ricomincia dal punto in cui i numeri dicono che il lavoro non è finito. Su Initpc.it, l'e-commerce che seguiamo come partner tecnico dal 2006, il lavoro sulle prestazioni è andato avanti in questo modo: prima il desktop, dove oggi i Core Web Vitals sono superati, poi il mobile, dove il cantiere è aperto e lo dichiariamo.

Questa pagina mostra i test reali di Google PageSpeed Insights eseguiti il 27 agosto 2026, senza selezionare i risultati: il report desktop e quello mobile, con i dati sul campo degli utenti reali (Chrome UX Report, ultimi 28 giorni) e quelli di laboratorio (Lighthouse). Preferiamo un cantiere dichiarato a un numero di comodo.

È uno dei capitoli del case study Initpc: le prestazioni dipendono da tutto ciò che sta sotto — la cache a più livelli dell'infrastruttura e la ricerca spostata su Elasticsearch — e questa pagina racconta l'ultimo strato, quello che il visitatore vede.

Come misuriamo: dati sul campo e dati di laboratorio

PageSpeed Insights mette insieme due cose diverse. I dati sul campo arrivano dal Chrome UX Report: sono le visite reali degli utenti negli ultimi 28 giorni, su dispositivi e connessioni reali, ed è su questi che Google valuta i Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). I dati di laboratorio sono un caricamento singolo simulato da Lighthouse, su un dispositivo emulato e una rete limitata: utili per diagnosticare, non per giudicare.

Per un e-commerce contano i primi. È sui dati sul campo che si decide se la valutazione dei Core Web Vitals è "superata" o "non superata", ed è lì che guardiamo per decidere dove intervenire. I punteggi di laboratorio servono a trovare le cause.

Desktop: Core Web Vitals superati

Il lavoro sul desktop è arrivato per primo, perché per un negozio di forniture per l'ufficio è ancora il canale con cui compra buona parte delle aziende. Il report del 27 agosto 2026 dà questo risultato.

Desktop — 27/08/2026	Valore	Soglia Google
Valutazione Core Web Vitals (campo, 28 giorni)	superata	—
LCP sul campo	1,5 s	≤ 2,5 s
INP sul campo	77 ms	≤ 200 ms
CLS sul campo	0,01	≤ 0,1
FCP sul campo	1,3 s	—
TTFB sul campo	0,9 s	—
Punteggio prestazioni (laboratorio)	95	—
Accessibilità / Best practice / SEO	92 / 92 / 100	—

In laboratorio, su desktop emulato, il primo contenuto compare a 0,4 s, l'LCP a 1,5 s, il Total Blocking Time è di 40 ms e il CLS 0,003. Non è un risultato che si ottiene con un plugin di cache: è la somma di Varnish che serve le pagine già generate, di Redis che risparmia query al database, delle immagini di catalogo ottimizzate e della ricerca che non pesa più su MariaDB.

Lo stesso report elenca ciò che resta da migliorare anche sul desktop — immagini (1.174 KiB di risparmio stimato), richieste che bloccano il rendering (450 ms), durate di cache (270 KiB) — e lo prendiamo come lista di lavoro, non come contestazione del risultato.

Mobile: cantiere aperto, dichiarato

Sul mobile il quadro è diverso, e lo scriviamo com'è. Stesso giorno, stessa pagina.

Mobile — 27/08/2026	Valore	Soglia Google
Valutazione Core Web Vitals (campo, 28 giorni)	non superata	—
LCP sul campo	2,4 s	≤ 2,5 s
INP sul campo	289 ms	≤ 200 ms
CLS sul campo	0,07	≤ 0,1
FCP sul campo	1,8 s	—
TTFB sul campo	1,2 s	—
Punteggio prestazioni (laboratorio, Moto G Power emulato, 4G lenta)	53	—
Accessibilità / Best practice / SEO	95 / 92 / 100	—

I dati sul campo dicono dove sta il problema: l'LCP a 2,4 s è dentro la soglia per un soffio, il CLS è a posto, mentre l'INP a 289 ms — il tempo che passa fra un tocco e la risposta visibile della pagina — supera i 200 ms ed è ciò che fa fallire la valutazione. In laboratorio, su un telefono di fascia media emulato con rete 4G lenta, il quadro si amplifica: primo contenuto a 4,4 s, LCP a 12,4 s, Speed Index 7,1 s, 310 ms di blocco del thread principale.

Cosa dice la diagnostica mobile e su cosa stiamo lavorando

Il report mobile indica con precisione le cause, e coincidono con il piano di lavoro in corso:

Rilievo di Lighthouse (mobile)	Stima di Google	Cosa stiamo facendo
Richieste che bloccano il rendering	2.070 ms	Ridurre CSS e JavaScript caricati prima del primo dipinto: critical CSS in linea per header e hero, il resto differito
JavaScript inutilizzato	565 KiB	Rimuovere o caricare a richiesta gli script dei plugin che non servono sulla pagina corrente
Attività lunghe nel thread principale	8	È la causa diretta dell'INP: spezzare i lavori lunghi, rinviare gli script di terze parti dopo l'interazione
Animazioni non composite	8 elementi	Portare le animazioni su proprietà gestite dal compositore (transform, opacity)
Caricamento delle immagini	207 KiB	Dimensioni e formati specifici per il mobile, lazy loading dove l'immagine è fuori schermo
Durate di cache	270 KiB	Allungare i tempi di cache delle risorse statiche sul livello HAProxy/Varnish
JavaScript legacy	47 KiB	Smettere di servire polyfill ai browser che non ne hanno bisogno

Lavoriamo su desktop e mobile con lo stesso metodo: una modifica alla volta, misurata con Lighthouse e Chrome DevTools sulla pagina reale, tenuta solo se i numeri migliorano. L'obiettivo dichiarato per il mobile è superare la valutazione dei Core Web Vitals sul campo — INP sotto i 200 ms, LCP con margine sotto i 2,5 s — e aggiorneremo questa pagina con i report successivi, con le stesse catture e le stesse date.

Perché il mobile è più difficile su un catalogo grande

Non è una scusa, è una constatazione tecnica. Una pagina di categoria con decine di prodotti, filtri, prezzi e disponibilità porta con sé più HTML, più immagini e più script di una pagina vetrina. Sul desktop la CPU e la rete assorbono il peso; su un telefono di fascia media con rete lenta ogni chilobyte di JavaScript diventa tempo di blocco, e ogni script di terze parti — recensioni, pagamenti, analytics — compete con la risposta al tocco dell'utente.

Per questo il lavoro mobile è in gran parte un lavoro di sottrazione: meno script prima del primo dipinto, meno lavoro sul thread principale, immagini della misura giusta. È lo stesso approccio che abbiamo seguito sul nostro sito, e che raccontiamo nel caso da WordPress a CMS proprietario.

Cosa può aspettarsi chi ha un e-commerce simile

Che un test Google non sia un voto definitivo ma una fotografia con una data. Che i dati sul campo valgano più del punteggio di laboratorio. E che, su un catalogo grande, la velocità venga dall'architettura prima che dal tema: cache al livello giusto, ricerca fuori dal database, immagini governate a monte. È il lavoro che facciamo nei servizi di assistenza server aziendali e di sviluppo e-commerce, e il quadro completo è nell'architettura completa del progetto Initpc.