Core Web Vitals: perché il monitoraggio uptime non basta

In breve: Il server restituisce HTTP 200, il monitoraggio dice "UP" - e tu perdi comunque traffico da Google. I Core Web Vitals (LCP, INP, CLS) misurano l'esperienza utente reale. Un web lento è dal punto di vista di Google "down" come uno non disponibile.

In breve: Il server restituisce HTTP 200, il monitoraggio dice "UP" - e tu perdi comunque traffico da Google. I Core Web Vitals (LCP, INP, CLS) misurano l'esperienza utente reale. Un web lento è dal punto di vista di Google "down" come uno non disponibile.

Tre metriche CWV

Google ha introdotto nel 2020 i Core Web Vitals come fattore di ranking. Da marzo 2024 sono composti da:

LCP (Largest Contentful Paint) - quando appare l'elemento più grande della pagina. Bene: ≤ 2,5 s. Da migliorare: 2,5-4 s. Male: > 4 s.
INP (Interaction to Next Paint) - con quale velocità la pagina reagisce alle interazioni dell'utente (clic, tap). Ha sostituito FID a marzo 2024. Bene: ≤ 200 ms. Da migliorare: 200-500 ms. Male: > 500 ms.
CLS (Cumulative Layout Shift) - quanto gli elementi della pagina si muovono visivamente durante il caricamento. Bene: ≤ 0,1. Da migliorare: 0,1-0,25. Male: > 0,25.

Perché il monitoraggio non lo cattura

Il classico monitor di uptime invia una richiesta HTTP GET e misura:

Status code (200 = OK)
Time to first byte (TTFB)
Opzionalmente keyword match nell'HTML

Ma non renderizza la pagina nel browser. Non vede che:

Il bundle JavaScript è di 3 MB e il parsing dura 4 secondi
L'immagine hero si carica sincrona e blocca il paint
La terza parte (analytics, advertising) blocca il main thread
Il layout salta mentre gli elementi si caricano

Dal punto di vista del visitatore il web è lento e inutilizzabile - dal punto di vista del monitoraggio tutto è "UP".

Lab vs field data

I CWV si misurano in due modi:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - browser controllato, rete definita (tipicamente 4G), device specifico. Riproducibile, adatto a test di regressione dopo deploy.

Field data / RUM (Chrome User Experience Report, JS custom) - raccolta dati da visitatori reali nelle loro condizioni reali. Quello che Google usa per il ranking. Riflette la variabilità reale (client mobile 3G dal treno, desktop fiber, ecc.).

I lab data sono un buon riferimento, i field data sono la verità.

Nota: ePulz.io attualmente non traccia le metriche CWV. Per misurarle, usa strumenti specializzati (PageSpeed Insights, WebPageTest, Lighthouse CI o un proprio snippet RUM JS). Per regressioni visuali, ePulz.io offre un monitor di tipo visual che confronta screenshot - questo copre parzialmente scenari "la pagina si rende completamente diversa", ma non misura LCP/INP/CLS.

Strategia pratica di monitoraggio

Synthetic uptime check - monitor HTTP classico ogni 1-5 min. Rileva hard downtime, 5xx, certificati scaduti.
Misurazione CWV (fuori ePulz) - Lighthouse CI in deployment pipeline o cron notturno o headless Chrome una volta al giorno. Rileva la regressione dopo un deployment (LCP è salito da 1,8 s a 4,2 s dopo il deploy di un nuovo JS bundle).
Visual regression check - screenshot diff. Rileva quando la pagina si renderizza in modo completamente diverso da prima (CSS rotto, font fail, JS error).
Real User Monitoring - snippet JS nella pagina raccoglie CWV da visitatori reali. Segui il 75° percentile delle metriche.

Cause principali di CWV cattivi

LCP troppo alto:

Immagini hero grandi senza priority hint (fetchpriority="high")
Server lento / TTFB (CDN cache miss, query DB lente)
Blocking resources in <head> (analytics, font senza display=swap)
Web font caricati da CDN di terze parti senza preconnect

INP troppo alto:

Grosso bundle JS che blocca il main thread
Event listener sincroni che fanno lavoro pesante
Script di terze parti lenti (chat widgets, A/B testing)

CLS troppo alto:

Immagini senza attributi width e height espliciti
Pubblicità senza spazio riservato
Contenuti iniettati dinamicamente sopra il fold
Web font con FOUT (Flash of Unstyled Text) senza fallback corretto

Impatto SEO

Google usa i CWV come tie-breaker. A contenuto ugualmente rilevante preferisce la pagina più veloce. In nicchie competitive è decisivo.

Impatto pratico:

Un sito con CWV nel range "good" ha in media ~20% bounce rate più basso
Il conversion rate sale con ogni -100 ms LCP
Mobile-first indexing significa che Google valuta la versione mobile - testa lì

Conclusione

Il monitoraggio uptime risponde a "Il server è raggiungibile?". I Core Web Vitals rispondono a "Il web è usabile?". Entrambe le metriche sono indipendenti e entrambe devi seguirle. Il server può avere 100% uptime e il web perdere comunque traffico per LCP sopra 4 secondi.

Monitoraggio oltre l'uptime

La visual regression rileva i cambiamenti visivi anche quando il server restituisce 200. Il monitoraggio del response time cattura endpoint lenti.

Prova ePulz.io →