2026-03-11 · Redazione Baduno · 8 blog.readMin · Blog & Conoscenza
Comprendere i Core Web Vitals: i tre valori che contano
LCP, INP, CLS – dietro gli acronimi si celano tre semplici domande: Quanto velocemente vedo qualcosa? Quanto velocemente reagisce la pagina? Si muove durante il caricamento?
LCP: la prima impressione
Il Largest Contentful Paint misura quando viene caricato l'elemento visibile più grande – di solito l'immagine hero. Obiettivo: sotto 2,5 secondi. Leve principali: dimensione dell'immagine, formato (WebP/AVIF) e priorità dell'immagine principale.
INP: la reattività
L'Interaction to Next Paint misura la velocità di reazione della pagina a clic e input. Le pagine lente hanno quasi sempre troppo JavaScript – ogni script risparmiato è tempo di reazione guadagnato.
CLS: la stabilità
Il Cumulative Layout Shift misura se i contenuti si spostano durante il caricamento. Cause principali: immagini senza dimensioni, pubblicità caricata successivamente e web font. La soluzione è di solito semplice – attributi width e height, aree riservate.
Perché è importante
Google utilizza questi valori come segnale di ranking, ma più importante: gli utenti li percepiscono. Ogni secondo di tempo di caricamento costa conversioni misurabili. Pagine statiche e leggere – come questa – raggiungono gli obiettivi strutturalmente anziché tramite ritocchi.
Misurare i Core Web Vitals: strumenti e fonti di dati
Per una misurazione affidabile dei Core Web Vitals sono disponibili diversi strumenti. PageSpeed Insights fornisce sia dati sul campo dal Chrome User Experience Report (CrUX) sia dati di laboratorio da Lighthouse. Il report CrUX riflette le esperienze utente reali e dovrebbe fungere da fonte primaria. Lighthouse, invece, simula una connessione media ed è adatto per suggerimenti di ottimizzazione mirati. Per un monitoraggio continuo, si consiglia l'integrazione in strumenti come Search Console o soluzioni di terze parti che mostrano tendenze storiche. Importante: non affidatevi solo ai valori di laboratorio – possono discostarsi dalla realtà. Combinate entrambe le prospettive e testate su diversi dispositivi e reti.
Errori comuni nell'ottimizzazione
Molti siti web falliscono a causa di errori evitabili. Un classico: immagini senza indicazioni di altezza e larghezza, che scatenano il CLS. Anche il caricamento ritardato dei contenuti visibili (Lazy Loading) per l'immagine hero peggiora l'LCP. Un altro ostacolo sono i font non ottimizzati: i font con `font-display: swap` prevengono il testo invisibile, ma possono causare spostamenti del layout se il font di fallback ha una larghezza diversa. Per quanto riguarda la reattività (INP), spesso la causa sono lunghe attività del thread principale dovute a script di terze parti, strumenti di analisi o risorse non caricate in modo asincrono. Anche troppi file CSS e JS senza bundling appesantiscono il percorso di rendering. Evitate questi errori verificando l'impatto di ogni modifica sulle tre metriche e lavorando con un budget per i tempi di caricamento e l'esecuzione degli script.
L'interazione tra LCP, INP e CLS
Le tre Core Web Vitals non sono indipendenti tra loro. Le ottimizzazioni per una metrica possono influenzarne un'altra. Esempio: risparmiare JavaScript non solo migliora l'INP, ma riduce anche il tempo di caricamento del contenuto principale (LCP), poiché l'albero di rendering viene costruito più velocemente. Allo stesso tempo, meno contenuti dinamici riducono il rischio di spostamenti del layout (CLS). Un altro esempio: l'uso di `font-display: optional` previene l'invisibilità del testo, ma può portare al mancato caricamento del font, compromettendo la leggibilità ma migliorando i valori CLS. Qui bisogna trovare compromessi: date priorità alla metrica che ha il maggiore impatto per i vostri utenti. Di solito, l'LCP è il più critico per la percezione, seguito dall'INP per le pagine interattive e dal CLS per i layout ricchi di contenuti.
LCP, INP, CLS – dietro gli acronimi si celano tre semplici domande: Quanto velocemente vedo qualcosa? Quanto velocemente reagisce la pagina? Si muove durante il caricamento?
Mobile e Desktop: sfide diverse
Gli stessi valori soglia per LCP (2,5 s), INP (200 ms) e CLS (0,1) valgono per dispositivi mobile e desktop. Tuttavia, gli approcci di ottimizzazione differiscono. I dispositivi mobile hanno processori più deboli e connessioni più lente, quindi il JavaScript non necessario ha un impatto particolarmente negativo. Anche la larghezza di banda di rete è inferiore: le immagini grandi appesantiscono maggiormente l'LCP. Inoltre, le dimensioni dello schermo sono più piccole, rendendo meno tollerabili gli spostamenti del layout causati da elementi caricati successivamente. Sul desktop, invece, un numero eccessivo di script può compromettere la reattività, poiché il thread principale viene bloccato. Pertanto, testate sempre prima su dispositivi mobile con connessione 3G. Utilizzate la modalità di throttling in Lighthouse o simulate condizioni reali. Una pagina ottimizzata per il mobile è solitamente buona anche per il desktop, ma non viceversa.
Ottimizzazione del server e della rete: la leva invisibile
I Core Web Vitals non iniziano solo nel browser, ma già sul server. Il Time to First Byte (TTFB) indica quanto tempo impiega il server a rispondere a una richiesta. Un TTFB elevato ritarda tutto il resto – LCP ne risente perché il primo contenuto arriva più tardi. Ottimizzate quindi la vostra infrastruttura server: utilizzate Content Delivery Network (CDN) per avvicinare i contenuti geograficamente ai vostri utenti. Gli asset statici come immagini, CSS e JavaScript possono essere distribuiti eccellentemente tramite CDN, mentre i contenuti dinamici possono essere accelerati con caching intelligente o edge computing. Un'altra leva è la scelta del provider di hosting: l'hosting condiviso con molti vicini può far lievitare il TTFB. Optate per server dedicati o soluzioni cloud con connessione rapida. Anche il rendering lato server (SSR) rispetto alla generazione di siti statici (SSG) ha un impatto: SSR genera HTML dinamicamente, aumentando il TTFB, mentre SSG fornisce file HTML precalcolati ed è estremamente veloce. Per molti siti web è utile un modello ibrido: contenuti statici tramite SSG, parti dinamiche tramite chiamate API. Misurate regolarmente il vostro TTFB con strumenti come WebPageTest e puntate a valori inferiori a 200 millisecondi. Tenete presente: ogni millisecondo di latenza del server si aggiunge al tempo di caricamento totale – e gli utenti sono impazienti.
Budget delle performance: controllare attivamente i Core Web Vitals
Invece di ottimizzare in modo reattivo, integra i budget di performance nel tuo processo di sviluppo. Un budget di performance stabilisce limiti vincolanti per metriche come LCP, INP o CLS – simile a un budget finanziario che non può essere superato. Definisci per ogni pagina importante valori target che siano dal 10 al 20 percento al di sotto delle soglie ufficiali, per avere un margine di fluttuazione. Monitora questi budget automaticamente nella tua pipeline di integrazione continua: ogni build viene controllata e, se un budget viene superato, il build fallisce. In questo modo eviti che nuove funzionalità peggiorino l'esperienza utente. Il supporto degli strumenti è offerto da Lighthouse CI, Sitespeed.io o script personalizzati che valutano i Core Web Vitals da Lighthouse o dati reali degli utenti. Assicurati di considerare sia i dati di laboratorio che quelli sul campo. Un budget per LCP potrebbe essere, ad esempio, 2,0 secondi in laboratorio e 2,3 secondi sul campo (75° percentile). Per INP sono realistici 150 ms in laboratorio e 180 ms sul campo. CLS dovrebbe rimanere al di sotto di 0,05. Comunica questi budget al team e rendili parte integrante della Definition of Done. In questo modo garantisci che le performance non siano un ripensamento successivo, ma vengano considerate fin dall'inizio.
Ottimizzazione lato server: TTFB e budget di rendering
I Core Web Vitals non possono essere migliorati solo con l'ottimizzazione frontend. Un fattore spesso sottovalutato è il tempo di risposta del server (Time to First Byte, TTFB). Un server lento ritarda l'inizio dell'intero processo di caricamento. Puntate a un TTFB inferiore a 800 millisecondi. Utilizzate meccanismi di caching come Redis o Varnish, ottimizzate le query del database e affidatevi a un'infrastruttura di hosting veloce. Anche la scelta del Content Delivery Network (CDN) è importante: un CDN riduce la distanza geografica dall'utente e distribuisce più rapidamente gli asset statici. Inoltre, dovreste definire un budget di rendering – un limite prefissato per il tempo massimo di esecuzione degli script durante la costruzione della pagina. Dividete il budget tra LCP, INP e CLS. Ad esempio, LCP potrebbe occupare al massimo 1,8 secondi di tempo server e 0,7 secondi di tempo client. Monitorate il rispetto del budget con strumenti come Lighthouse o WebPageTest. Con il server-side rendering (SSR) o la generazione statica riducete il carico client. Tuttavia, considerate che SSR può aumentare il TTFB – testate diversi approcci. Una combinazione equilibrata di prestazioni del server e CDN garantisce Core Web Vitals stabili.
Monitoraggio e sorveglianza continua in produzione
Ottimizzazioni una tantum non bastano: i Core Web Vitals devono essere monitorati costantemente. Integrate il Real User Monitoring (RUM) per raccogliere dati reali degli utenti. Strumenti come Google Analytics con il report Web Vitals o soluzioni open-source come Grafana con l'API CrUX consentono confronti storici. Impostate soglie e create allarmi quando i valori superano i target (LCP > 2,5 s, INP > 200 ms, CLS > 0,1). Osservate le tendenze: se una metrica peggiora nell'arco di settimane, potrebbe essere necessario un refactoring. Soprattutto in caso di aggiornamenti regolari dei contenuti (blog, shop, notizie), il monitoraggio continuo è essenziale. Anche modifiche esterne – come l'integrazione di nuovi script di terze parti – possono peggiorare i valori. Prima di ogni rilascio, eseguite un test Lighthouse e documentate i risultati. Inoltre, si raccomanda il monitoraggio sintetico da più sedi in condizioni controllate. In questo modo, individuate i problemi in anticipo, prima che influiscano sugli utenti. Ricordate: i Core Web Vitals sono un processo continuo, non un progetto una tantum. Solo con un monitoraggio sistematico le vostre pagine rimarranno performanti a lungo termine e competitive nei risultati di ricerca.
blog.faqT
Come posso migliorare i Core Web Vitals nel mio CMS come WordPress?
In WordPress, un tema ottimizzato, un plugin di cache e la compressione delle immagini aiutano. Evitate plugin eccessivi, in particolare quelli che caricano JavaScript in modo differito. Utilizzate un plugin per le performance che disattivi il lazy loading per le immagini (per i contenuti visibili) ed estragga il CSS critico. Testate i risultati con PageSpeed Insights.
I Core Web Vitals sono un segnale di ranking diretto di Google?
Sì, i Core Web Vitals fanno parte del segnale Page Experience nel ranking dal giugno 2021. Tuttavia, sono solo uno dei tanti fattori. Una buona esperienza utente grazie a tempi di caricamento rapidi e layout stabili ha un impatto misurabile sulle conversioni e sulle frequenze di rimbalzo, indipendentemente dal ranking.
