01 — Cosa sono i Core Web Vitals
I Core Web Vitals sono tre metriche che Google ha standardizzato nel 2020 per misurare l'esperienza utente reale di una pagina web.
LCP (Largest Contentful Paint) misura quando il sito sembra caricato. CLS (Cumulative Layout Shift) misura quanto il layout salta durante il caricamento. INP (Interaction to Next Paint) misura quanto velocemente risponde alle azioni dell'utente.
Google ha sostituito FID con INP a marzo 2024 perché INP è più rappresentativa dell'esperienza reale: misura ogni interazione, non solo la prima. Le soglie attuali sono: LCP < 2.5s, CLS < 0.1, INP < 200ms. Per "passare il check" tutte e tre devono essere nel range "good" sul 75% degli utenti.
02 — Perché Google li usa per il ranking
"Page Experience" è dal 2021 un fattore ufficiale di ranking. Google ha smesso di pretendere che i siti siano solo rilevanti: pretende anche che siano usabili.
Il peso dei Core Web Vitals nel ranking non è enorme di per sé (Google dichiara "tiebreaker quando i contenuti sono comparabili") MA si compone con altri segnali. Bounce rate alto su mobile (causato da LCP lento), session duration ridotta (causata da INP cattivo), pogo-sticking (utente torna ai SERP perché il sito è inutilizzabile). Tutti questi sono segnali secondari che spingono il sito in basso.
L'effetto reale è asimmetrico: avere CWV verdi non ti dà boost, ma averli rossi ti fa scivolare. È un "qualifier", non un "amplifier". Per chi fa SEO seriamente è una condizione necessaria.
Aldilà del ranking puro, c'è il dato di conversione. Ogni 100ms in più di LCP riduce le conversioni e-commerce dell'1% (dato Akamai/Cloudflare medio settore). Per un e-commerce con 100k€ di volume mensile, fare passare LCP da 4s a 2s vale, in soldi reali, multipli del costo dell'audit.
03 — Le 3 metriche spiegate (e come si fixano)
- LCP< 2.5s
Largest Contentful Paint
Misura il tempo necessario perché il più grande elemento visibile (immagine hero, titolo principale, video poster) appaia sullo schermo. È il proxy migliore per 'quando il sito sembra caricato all'utente'.
Fix in ordine di impatto
- Hero servito in AVIF/WebP invece di PNG/JPEG
- fetchpriority="high" sull'immagine cover
- Preload del font display above-the-fold
- Eliminazione del CSS render-blocking
- Hosting con TTFB sotto 600ms
- CLS< 0.1
Cumulative Layout Shift
Misura quanto il layout 'salta' durante il caricamento. Un layout shift è quando un elemento si sposta perché qualcosa carica dopo (immagine senza dimensioni, banner cookie, font che cambia metriche). Misurato in unità adimensionali da 0 a infinito.
Fix in ordine di impatto
- Dimensioni esplicite (width/height) su ogni <img>, <iframe>, <video>
- Spazio riservato per banner cookie (es. min-height: 80px)
- Font-display swap con size-adjust per minimizzare il salto fallback→display
- Sticky header con altezza fissa, non 'auto'
- Skeleton loader con stesse dimensioni del contenuto finale
- INP< 200ms
Interaction to Next Paint
Misura quanto tempo il sito impiega a reagire a un'interazione (click, tap, key press). Sostituisce FID dal marzo 2024. Un sito che risponde in 500ms si percepisce 'rotto' anche se tutto funziona.
Fix in ordine di impatto
- Long task spezzati con scheduler.yield() o setTimeout
- Eventi pesanti spostati in requestIdleCallback
- Hydration React/Vue ottimizzata (server components, lazy hydration)
- JavaScript bundle splitato per route, non monolitico
- Listener pesanti debounced o throttled
04 — I 4 tool che servono davvero
Niente di esotico. Quattro tool, gratuiti o integrati, coprono il 95% dell'audit.
- 01
PageSpeed Insights
pagespeed.web.dev
Test rapido. Una volta inserito l'URL, ti dà sia lab data (Lighthouse) che field data (CrUX, dati reali degli utenti negli ultimi 28 giorni). Quello che davvero conta per Google è il field data.
- 02
WebPageTest
webpagetest.org
Test profondo. Filmstrip frame-by-frame, waterfall request, breakdown TTFB/render/scripting/loading. Permette di vedere DOVE si perde il tempo, non solo quanto.
- 03
Chrome DevTools Performance
integrato
Quando devi capire perché un'interazione è lenta (INP). Registra una sessione, guarda il flame chart, identifica i long task. È lo strumento che usano i developer per i fix più tecnici.
- 04
CrUX Dashboard (BigQuery o Looker Studio)
BigQuery
Per siti grandi, dashboard sui dati Chrome reali aggregati (Chrome User Experience Report). Mostra come performano i tuoi utenti reali, non un test lab. È il dato che Google usa per il ranking.
05 — Come fare un audit serio in 30 minuti
- Identifica le 5 page critiche. Non testare tutto: testa quelle che portano traffico/conversioni (home, lista prodotti/servizi, dettaglio top-3, checkout se e-commerce).
- PageSpeed Insights su ogni page. Guarda field data, not lab. I numeri lab (Lighthouse) sono test in laboratorio. I field data (CrUX) sono utenti reali. Differenza enorme.
- Identifica la metrica peggiore per ogni page. Se LCP è 4.2s, INP è 280ms, CLS è 0.05 → priorità è LCP. Non fare 30 fix random: fai 3-5 fix sulla metrica che fallisce.
- WebPageTest waterfall sulla page peggiore. Guarda quale request blocca il render (di solito CSS o font), quale request è quella del LCP element, quanto tempo passa prima del paint. Da qui escono i fix specifici.
- Elenco fix prioritari, non lista alfabetica. Output dell'audit: 3-5 fix in ordine di impatto/effort, ognuno con stima di delta atteso. "Sostituire hero PNG con AVIF + fetchpriority" → atteso -800ms LCP.
06 — Fix in ordine di priorità (per la maggior parte dei siti)
Per ~80% dei siti che vedo, l'ordine di fix che muove davvero l'ago è questo:
- Image optimization (AVIF/WebP + lazy loading + dimensioni). Hero da 3MB in PNG → 80KB in AVIF è la differenza più grossa che vedrai. Effort basso, impact alto su LCP e CLS.
- Font loading. next/font, preload selettivo, size-adjust. Riduce CLS quasi a zero, accelera LCP del 200-400ms.
- Render-blocking CSS/JS cleanup. Critical CSS inline, JavaScript splittato per route, defer su tutto ciò che non serve above-the-fold. Riduce LCP di 500-1500ms su siti pesanti.
- Hosting/TTFB. Se TTFB è sopra 600ms anche dopo cache, il problema è lato server. CDN, edge caching, hosting tuned. Per siti WordPress: WP Engine, SiteGround, Kinsta. Per Next.js: Vercel, Cloudflare.
- INP optimization. Solitamente l'ultimo fix. Long task spezzati, hydration ottimizzata, listener throttled. Senza JavaScript pesante INP è quasi sempre verde di default.
Quando questi cinque step sono fatti, l'80% dei siti passa il check. Il 20% restante richiede interventi più profondi. Refactor architetturale, cambio CMS, riscrittura componenti pesanti. Lì serve l'audit completo, non più la checklist.