Core Web Vitals reali: cosa misurare oltre a PageSpeed

Quando un cliente ci scrive "PageSpeed mi dà 65, vorrei salire a 95", sappiamo che dovremo prima fare una conversazione. PageSpeed Insights è uno strumento utile, ma è solo la superficie. Ottimizzare per il punteggio significa spesso non ottimizzare per gli utenti reali.

I Core Web Vitals (LCP, INP, CLS) sono una metrica seria, ma vivono in due mondi: il dato di laboratorio (lab data, Lighthouse) e il dato di campo (field data, CrUX). Confonderli porta a investire dove non serve.

Come funziona davvero PageSpeed Insights

PageSpeed Insights mostra due blocchi principali:

1. Field data (in alto): dati raccolti da utenti reali su Chrome negli ultimi 28 giorni, aggregati nel CrUX. Questi sono i Core Web Vitals che Google usa per il ranking.
2. Lab data (sotto): test automatico di Lighthouse su una connessione e device simulati. Utile per il debug, ma non rappresentativo del traffico reale.

Il punteggio Lighthouse 0-100 è una sintesi del lab data. Può salire molto alzando alcune metriche specifiche senza che l'esperienza degli utenti reali cambi davvero.

LCP - Largest Contentful Paint

LCP misura quanto tempo passa dal momento in cui l'utente arriva sulla pagina al momento in cui viene visualizzato l'elemento "principale" (di solito una hero image o un blocco di testo grande).

Soglia consigliata: sotto 2.5 secondi sul 75esimo percentile dei visitatori.

Nei siti WordPress reali, le cause più comuni di LCP alto:

• TTFB lento (server lento a rispondere): cache disabilitata, plugin pesanti che girano in wp_loaded, query non ottimizzate, hosting condiviso saturo.
• Hero image grande non ottimizzata: 4MB di JPEG da 6000px caricato a 1200px senza WebP/AVIF.
• Font web che bloccano il rendering: 6 weight di un font caricati synchronously senza font-display: swap.
• JavaScript critico bloccante: builder pesanti che caricano librerie prima di mostrare il contenuto.

Il fix richiede ordine: prima TTFB, poi immagini, poi font, poi JavaScript. Saltare l'ordine produce ottimizzazioni cosmetiche.

INP - Interaction to Next Paint

INP ha sostituito FID nel 2024 ed è la metrica più sottovalutata. Misura quanto tempo passa tra un'interazione utente (click, tap, tastiera) e il prossimo paint visibile.

Soglia consigliata: sotto 200 ms sul 75esimo percentile.

INP è il vero indicatore di "questo sito è reattivo". Su WordPress, le cause tipiche di INP alto:

• Plugin con tracciamento JS pesante: chat, analytics, heatmap, A/B testing che fanno layout thrashing.
• Theme builder che riapplicano stili al click: builder come Elementor o WPBakery con tante interazioni dinamiche.
• JavaScript in admin-ajax: chiamate sincrone su click che bloccano il main thread.
• Service worker pesanti: PWA mal configurate.

INP non si vede su Lighthouse: si vede solo sul field data. Per questo siti con punteggio Lighthouse 95 possono avere INP rosso e ranking penalizzato.

CLS - Cumulative Layout Shift

CLS misura quanto la pagina "salta" mentre carica. Soglia consigliata: sotto 0.1.

Le cause classiche su WordPress:

• immagini senza attributi width e height
• ads o banner che caricano dopo il contenuto
• font web che cambiano dimensione tra fallback e font finale
• pulsanti "accetta cookie" che spostano il contenuto

CLS si risolve con disciplina: prenotare lo spazio prima ancora di caricare l'asset, usare aspect-ratio, evitare contenuti che irrompono dopo che la pagina è composta.

Lab data vs field data: il caso del 95 finto

Capita spesso questo scenario: cliente con punteggio Lighthouse 95 e CrUX rosso. Significa che il lab test (su connessione 4G simulata, device medio, no estensioni) va bene, ma gli utenti reali (con device più vecchi, connessioni peggiori, estensioni Chrome che mangiano CPU) hanno un'esperienza peggiore.

Il rimedio non è "alzare il punteggio Lighthouse". Il rimedio è guardare il field data, capire dove gli utenti reali hanno problemi, e ottimizzare lì.

Cosa misuriamo sui siti dei clienti

Per i siti in manutenzione continuativa, monitoriamo:

• CrUX dataset mensile, segmentato per tipo di device e per origine traffico
• Real User Monitoring quando i volumi lo giustificano, con uno script leggero (web-vitals.js, dimensioni < 5KB)
• Lighthouse CI in fase di staging per scoprire regressioni prima che vadano in produzione
• Server-side TTFB misurato dal server stesso, indipendente dal client

Il TTFB lato server è particolarmente utile: separa "il sito è lento" da "il visitatore ha una connessione scadente".

Errori comuni di ottimizzazione

Cose che vediamo fare spesso e che non aiutano (o peggiorano):

• Lazy load aggressivo sull'hero: l'hero deve caricarsi subito, fare lazy load la peggiora.
• Defer di tutti gli script: se il sito ha script critici (legittimamente), differirli rompe funzionalità.
• Compressione JPEG estrema: passare da 90% a 50% di qualità abbassa il peso ma mostra immagini brutte. Meglio AVIF/WebP a qualità media.
• CDN attivata ma non configurata: il sito passa per Cloudflare ma serve cache stale, peggiorando la situazione.
• Plugin "ottimizzazione cache" cumulati: 3 plugin di cache diversi che si calpestano e generano payload duplicati.

Performance reale, non teatro

Una performance ottimization fatta bene parte da dati di campo, identifica il bottleneck reale, lo risolve con ordine, e verifica con dati reali post-intervento. Tutto il resto è teatro: punteggi che salgono di pochi punti senza che l'utente medio veda differenza.

Se vuoi una valutazione concreta del tuo sito (con field data, non punteggi Lighthouse), parliamone via chat. La prima analisi è inclusa nel pacchetto Analisi WordPress.