Misurare le performance reali del sito: PageSpeed, CrUX e Core Web Vitals

Problema che risolvi: “Il sito è lento” è un’opinione finché non hai numeri confrontabili con soglie ufficiali e dati di campo.

Cosa fai in ~15 minuti: ottieni un report PageSpeed Insights (lab + campo), leggi LCP / INP / CLS e annoti un backlog di 3 azioni.

Come sai che funziona: hai URL, data del test e valori numerici ripetibili (stesso URL, stesso strumento → confronto prima/dopo).

Core Web Vitals oggi (2024+)

Google classifica come Core Web Vitals attuali (materiale ufficiale web.dev/vitals):

Non confondere lab (Lighthouse simula rete/CPU) e campo (utenti reali, es. CrUX nel report PSI).

Passo 1 — PageSpeed Insights

1. Vai su PageSpeed Insights.
2. Incolla l’URL pubblico (produzione, non localhost — per locale usa Lighthouse in Chrome, vedi sotto).
3. Scegli Mobile e avvia l’analisi.

Cosa guardare per prima cosa:

• Sezione Core Web Vitals assessment (dati di campo se il sito ha traffico sufficiente in CrUX; altrimenti vedrai messaggi sul campione limitato).
• Opportunities e Diagnostics in Lighthouse: sono suggerimenti prioritizzati (immagini, JS, font, LCP element).

Esporta o salva screenshot: ti servono per regressioni dopo un deploy.

Passo 2 — Dati di campo (CrUX) nel report

PageSpeed mostra Origin o URL field data quando disponibile. Se vedi “Insufficient real-user data”, non significa che il sito sia veloce: significa solo che CrUX non ha abbastanza campioni per quella URL/origin nel periodo considerato.

In quel caso:

• usa comunque il report lab come checklist tecnica;
• misura in produzione con RUM (vedi § strumenti avanzati) o attendi traffico su URL canoniche principali.

Riferimento progetto CrUX: Chrome UX Report.

Passo 3 — Lighthouse in locale (Chrome DevTools)

Per localhost o staging dietro VPN:

1. Chrome → F12 → tab Lighthouse (o “Performance” per profilo manuale).
2. Modalità Navigation + dispositivo Mobile.
3. Avvia e leggi gli stessi indicatori (LCP, CLS; per INP in locale valuta anche Interaction trace nel pannello Performance durante click reali).

Passo 4 — Tre fix ad alto rendimento (dopo il primo report)

Ordine tipico quando Lighthouse segnala problemi classici:

1. LCP: ottimizza l’immagine o il blocco LCP (dimensioni responsive, fetchpriority="high" dove appropriato, CDN, evitare lazy sul hero).
2. JS: riduci bundle e script di terze parti (analytics, chat, A/B) — spesso il maggior colpevole di INP/lunghi task.
3. CLS: dimensioni esplicite per immagini/embed e non inserire banner sopra il contenuto dopo il paint.

Ogni intervento si valida rilanciando PSI o Lighthouse e confrontando le stesse metriche.

Strumenti avanzati (opzionali)

• Search Console → rapporto Core Web Vitals per trend su gruppi di URL (richiede proprietà verificata).
• RUM (es. strumenti analytics che raccolgono web-vitals in JS): unico modo affidabile per INP su utenti reali per app SPA.

Libreria: web-vitals (GitHub).

Cosa non fare

• Non citare percentuali di fatturato per 100 ms di ritardo senza modello di business e dati tuoi — variano per settore e funnel.
• Non ottimizzare il punteggio Lighthouse “a ideologia” se i campi CrUX sono già verdi su LCP/INP/CLS per le pagine che contano.

Sintesi

1. PSI su URL reale → leggi LCP, INP, CLS (campo + lab).
2. Lighthouse locale per staging/localhost.
3. Applica 1–3 fix mirati e ripeti la misura con la stessa procedura.

Il costo del “sito lento” per il tuo business si argomenta solo dopo questi numeri e dopo aver collegato metriche a funnel (es. calo conversione su pagina con INP alto) — non con aneddoti di altri retailer.