Obiettivi Core Web Vitals e perché contano nel 2026
I Core Web Vitals sono diventati un segnale di ranking Google nel 2021. Da allora tutti i principali fornitori di browser, CDN e framework si sono allineati sulle stesse tre soglie. Nel 2024, Google ha sostituito il vecchio First Input Delay (FID) con l'Interaction to Next Paint (INP), alzando significativamente l'asticella — il FID misurava solo la prima interazione, mentre l'INP traccia ogni interazione durante tutta la sessione. Nel 2026, le tre metriche che determinano se si supera o meno il test sono:
| Metrica | Cosa misura | Buono | Da migliorare | Scarso |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | Tempo fino al rendering del più grande elemento above-the-fold | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP — Interaction to Next Paint | Peggior latenza di interazione durante la sessione | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Totale dei movimenti imprevisti degli elementi visibili | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Tutte le soglie sono valutate al 75° percentile dei dati reali dal Chrome User Experience Report (CrUX). Questo significa che il 25% dei vostri visitatori reali può sperimentare valori peggiori della mediana — dovete ottimizzare per la coda più lenta del vostro pubblico, non solo per la media. Il fallimento di una sola metrica posiziona la pagina nel bucket "da migliorare" o "scarso", che correla negativamente con i ranking per le query competitive.
Al di là della SEO, l'argomento commerciale per le prestazioni è chiaro. Studi condotti in e-commerce e SaaS B2B mostrano costantemente che un miglioramento di 100 ms nel tempo di caricamento della pagina correla con un aumento del tasso di conversione dell'1–2%. Per questo motivo, i nostri team di sviluppo di applicazioni web strumentano i CWV dal primo giorno di ogni nuova costruzione, non come un ripensamento post-lancio.
Ottimizzazione del bundle frontend
JavaScript è il singolo maggiore contributore a LCP lento e INP scarso nelle applicazioni web moderne. Un bundle monolitico sovradimensionato costringe il browser ad analizzare e compilare centinaia di kilobyte di script prima di poter renderizzare un singolo frame significativo. Nel 2026, l'obiettivo per la maggior parte delle applicazioni in produzione è un peso JavaScript totale inferiore a 200 KB compressi al caricamento iniziale.
Gli interventi chiave includono: code splitting basato sulle route con import dinamici per i componenti pesanti (editor di testo ricco, librerie di grafici), disciplina di tree-shaking con le grandi librerie, audit regolari delle dipendenze con strumenti di analisi dei bundle, e governance degli script di terze parti — i pixel analytics e i widget di chat possono aggiungere 80–200 KB ciascuno. La compressione Brotli (livello 11) risparmia un ulteriore 15–20% rispetto a gzip sui bundle JS.
Immagini, font e caricamento above-the-fold
L'elemento LCP è quasi sempre un'immagine — immagine hero, foto del prodotto o sfondo. Gestire correttamente quella singola immagine è la modifica con il ROI più alto che la maggior parte dei team può fare.
Selezione del formato: AVIF supera WebP del 20–30% a parità di qualità visiva, e WebP supera JPEG del 25–35%. Nel 2026, Safari 17+ e tutti i browser Chromium supportano AVIF, rendendolo il formato predefinito per le nuove build. Usare <picture> con sorgente AVIF e fallback JPEG.
fetchpriority="high" sull'immagine LCP è la modifica di attributo singolo più impattante disponibile nel 2026. Indica al browser di recuperare l'immagine LCP immediatamente, prima degli script e dei fogli di stile. Combinare sempre con loading="eager" — non impostare mai loading="lazy" sull'elemento LCP.
Strategia di caricamento dei font: Per ogni font web personalizzato caricato, si pagano due penalità: un round-trip di rete e uno spostamento del layout se le metriche di fallback differiscono dal font caricato. Nel 2026, l'approccio consigliato è font-display: optional per il testo del corpo e un <link rel="preload"> per il peso principale usato above-the-fold.
Strategia di caching e configurazione CDN
Un CDN avvicina geograficamente gli asset statici agli utenti ed elimina i round-trip verso l'origine per i visitatori ripetuti. Correttamente configurato, è una delle misure singole più impattanti per il LCP.
Header di cache immutabili per gli asset con hash: Il bundler aggiunge un hash del contenuto a ogni nome di file di output: main.a4f2c91b.js. Servire questi file con Cache-Control: public, max-age=31536000, immutable. Il documento HTML stesso deve essere servito con Cache-Control: no-cache o un TTL breve con validazione.
Purge della cache CDN al deployment: Configurare un hook di deployment che pulisce la cache HTML — l'API purge-by-URL di Cloudflare, l'API di invalidazione di AWS CloudFront o il purge istantaneo di Fastly — come ultimo passo della pipeline CI/CD.
HTTP/2 Early Hints (103): Permette al CDN di inviare hint di preload per le risorse critiche (font, CSS principale) prima che l'origine abbia terminato di generare la risposta HTML. Questo risparmia 50–150 ms sulle pagine con TTFB elevato. Cloudflare e Fastly supportano gli Early Hints dal 2025.
Tuning delle prestazioni backend e database
Le ottimizzazioni frontend riducono il lavoro del browser, ma non possono compensare un backend che impiega 1,5 secondi per restituire una risposta API. Quando il LCP è nell'intervallo 3–5 secondi dopo tutte le correzioni frontend, il collo di bottiglia è quasi sempre il server.
Prima il profiling delle query: Eseguire EXPLAIN ANALYZE (PostgreSQL) o EXPLAIN FORMAT=JSON (MySQL) sulle query più lente. Cercare: scansioni sequenziali su tabelle grandi, join con loop annidati su set di risultati non delimitati, e indici mancanti sulle chiavi esterne usate in JOIN o WHERE.
Eliminazione delle query N+1: Il pattern N+1 — caricare una lista di N record e poi emettere una query per record per i dati correlati — è la causa più comune di endpoint API lenti nei codebase basati su ORM. In Django, usare select_related e prefetch_related. In TypeORM, usare leftJoinAndSelect. In Prisma, usare include.
Connection pooling: Le connessioni al database sono costose — tipicamente 20–100 ms. Usare un pooler di connessioni: PgBouncer in modalità transazione per PostgreSQL, o opzioni cloud-native come AWS RDS Proxy. Il passaggio dalle connessioni dirette a PgBouncer può ridurre la latenza API p95 da 600 ms a 80 ms.
Read replica per le query pesanti: Le dashboard analitiche e gli endpoint di reporting dovrebbero essere instradati verso una read replica — il lag di replica è tipicamente di 10–100 ms, accettabile per tutte le letture non transazionali.
Caching a livello applicativo: Aggiungere una cache Redis o Valkey davanti ai calcoli costosi o alle chiamate API di terze parti. Impostare TTL conservativi per i dati transazionali (30–60 s) e TTL più lunghi per i dati di riferimento (5–30 min).
INP runtime: correggere la latenza delle interazioni
L'INP misura il tempo dal momento in cui un utente interagisce (clic, tocco, tasto) al momento in cui il browser renderizza il frame successivo in risposta. Il budget di 200 ms è stretto: è necessario eseguire il gestore di eventi, aggiornare lo stato, ri-renderizzare l'albero dei componenti e dipingere — tutto entro duecento millisecondi.
Usare il pannello Performance di Chrome DevTools su un workflow reale: Registrare una sessione di 30 secondi della pagina più interattiva. Ordinare per "Long Tasks" — qualsiasi attività oltre 50 ms è candidata all'ottimizzazione. Non ottimizzare basandosi sui punteggi INP di Lighthouse.
React 18 Concurrent rendering: startTransition contrassegna gli aggiornamenti di stato come non urgenti, consentendo al browser di dipingere un frame intermedio mentre viene calcolato l'aggiornamento costoso. Usarlo per tutto ciò che non deve essere riflesso immediatamente: risultati di filtri di ricerca, colonne di tabelle ordinate, liste paginate.
Virtualizzazione per liste e tabelle lunghe: Renderizzare 1.000 nodi DOM in una tabella di dati è un killer garantito dell'INP. TanStack Virtual renderizza solo le righe visibili più un piccolo buffer — riducendo tipicamente il conteggio dei nodi DOM da 1.000 a 30–50. Il miglioramento dell'INP è spesso dell'80–90%.
Evitare il layout thrashing: Leggere una proprietà di layout (scrollTop, getBoundingClientRect) dopo una scrittura forza il browser a ricalcolare il layout in modo sincrono. Raggruppare tutte le letture prima delle scritture, o usare le API moderne ResizeObserver e IntersectionObserver.
Misurazione con Lighthouse, CI e RUM
I team di ingegneria delle performance efficaci utilizzano un sistema a tre livelli:
Livello 1 — Laboratorio: Lighthouse in CI. Eseguire Lighthouse contro ogni pull request usando lighthouse-ci. Impostare budget di asserzione: performance >= 90, lcp <= 2500, cls <= 0,1. Far fallire la build se un PR abbassa le prestazioni sotto il budget.
Livello 2 — Sintetico: Test pianificati da agenti geografici. Strumenti come Catchpoint, Pingdom o SpeedCurve eseguono da browser reali in posizioni geografiche fisse (p.es. US East, Germania, Singapore) su un piano di 15 minuti o orario. Allertare se il LCP p75 supera 3 s per qualsiasi regione.
Livello 3 — RUM: Real User Monitoring. Questa è la fonte di verità. La libreria web-vitals (di Google, open source) cattura INP, LCP, CLS, TTFB e FCP da sessioni reali del browser. Il costo dello sviluppo di applicazioni web personalizzate è sempre più alto quando la strumentazione delle prestazioni viene aggiunta dopo il lancio; integrarla dal primo sprint.
Definire e applicare i budget di performance
Un budget di performance è un vincolo contrattuale sulle metriche chiave. Senza budget, le prestazioni si degradano gradualmente — uno script di terze parti qui, un refactoring rapido lì — finché il team non si trova di fronte a un costoso sprint di remediation.
| Dimensione del budget | Valore target | Meccanismo di applicazione | Soglia di allerta |
|---|---|---|---|
| JS totale (caricamento iniziale, gzip) | ≤ 200 KB | Limite di dimensione bundler, LHCI | > 250 KB = bloccare PR |
| Immagine hero (elemento LCP) | ≤ 80 KB (AVIF) | Controllo CI immagini | > 150 KB = avviso |
| LCP (campo, p75) | ≤ 2,5 s | Report RUM settimanale | > 3,0 s = PagerDuty |
| INP (campo, p75) | ≤ 200 ms | Report RUM settimanale | > 350 ms = allerta Slack |
| CLS (campo, p75) | ≤ 0,1 | LHCI + RUM | > 0,15 = allerta Slack |
| Tempo di risposta API p95 | ≤ 200 ms | APM (DataDog/Grafana) | > 500 ms = PagerDuty |
| Numero di font personalizzati | ≤ 2 famiglie × 2 pesi | Regola del design system | Revisione PR manuale |
Vale anche la pena esaminare come l'ingegneria delle performance interagisce con le decisioni architetturali. Il nostro articolo su come costruire un SaaS multi-tenant copre i pattern di sharding del database e di connection pooling che influenzano direttamente i tempi di risposta backend. Se si stanno valutando i framework, il nostro confronto Next.js vs React per le applicazioni web B2B copre come i Server Components e lo streaming SSR in Next.js 14 influenzano i CWV fin dall'inizio.
FAQ
Quali sono gli obiettivi Core Web Vitals per il 2026?
Le soglie "Buono" di Google sono: LCP sotto 2,5 secondi (Largest Contentful Paint), INP sotto 200 millisecondi (Interaction to Next Paint, che ha sostituito il FID) e CLS sotto 0,1 (Cumulative Layout Shift). Questi vengono misurati al 75° percentile dei dati reali dal Chrome User Experience Report. Il fallimento di anche una sola soglia può penalizzare i ranking su Google Search.
Qual è il modo più rapido per migliorare il LCP?
Gli interventi con il miglior ROI per il LCP: (1) servire l'immagine hero da un CDN con HTTP/2 e un TTL di cache di 1 anno, (2) aggiungere fetchpriority="high" e rimuovere qualsiasi attributo lazy dall'immagine above-the-fold, (3) usare AVIF o WebP con un srcset correttamente dimensionato, e (4) preconnettere alle origini terze presto nel head. Insieme, questi tipicamente portano il LCP da 4–6 s a meno di 2,5 s.
Come si corregge l'INP su un SPA React o Vue?
L'INP misura il tempo dall'input utente al rendering del frame successivo. Cause comuni negli SPA: gestori di eventi sincroni, grandi alberi di componenti e letture che forzano il layout (getBoundingClientRect) all'interno dei gestori di clic. Correzioni: startTransition (React 18+), virtualizzazione per le liste lunghe (TanStack Virtual), debouncing degli input, ed evitare le letture di layout all'interno dei gestori di eventi.
Cosa causa il CLS e come si corregge?
Il CLS è causato da elementi che si spostano dopo il caricamento: immagini senza attributi width/height, annunci caricati in modo asincrono, font web che causano FOIT/FOUT, e contenuto iniettato above the fold. Correzioni: impostare sempre width e height sulle immagini; usare font-display: optional o swap con un fallback strettamente corrispondente; riservare spazio per gli annunci con min-height.
Un CDN da solo risolve le prestazioni delle applicazioni web?
Un CDN è necessario ma non sufficiente. Un CDN riduce la latenza degli asset statici ma non può fare nulla se le risposte API impiegano 800 ms a causa di una query N+1. Le vere prestazioni richiedono un approccio full stack: CDN più header HTTP cache più ottimizzazione delle query backend più connection pooling più riduzione della dimensione del bundle frontend più ottimizzazione runtime (INP).
Come si misurano le prestazioni degli utenti reali, non solo Lighthouse?
Lighthouse è uno strumento di laboratorio — simula un singolo caricamento su una connessione limitata. Per i dati sul campo, usare: (1) il report Core Web Vitals di Google Search Console, (2) la libreria JS web-vitals che invia INP/LCP/CLS alla propria analytics, (3) strumenti RUM commerciali come DataDog RUM, Sentry Performance o Grafana Faro. Ottimizzare sempre sulla base dei dati sul campo p75.
Cos'è un budget di performance JavaScript e come si imposta?
Un budget di performance è un limite fisso su una metrica — ad esempio, dimensione totale del bundle JS sotto 200 KB compressi, LCP sotto 2,5 s o INP sotto 200 ms. Impostare i budget: (1) misurando le baseline attuali, (2) fissando obiettivi basati sulle soglie Core Web Vitals, (3) applicando con limiti di dimensione del bundler e Lighthouse CI nella pipeline. Un budget senza applicazione automatizzata si degrada nel corso degli sprint.
Ultimo aggiornamento: 12 giugno 2026. Soglie delle metriche da web.dev/explore/metrics. Dettagli di implementazione basati su Chrome 124+, React 18, Next.js 14 e le attuali capacità dei fornitori CDN.
