Core Web Vitals: perché la velocità è diventata SEO

Il cambiamento silenzioso del 2021

Nel maggio 2021 Google ha integrato ufficialmente i Core Web Vitals nel suo algoritmo di posizionamento. Nei 18 mesi precedenti, il motore di ricerca aveva comunicato gradualmente perché gli sviluppatori si preparassero. Molti non l’hanno preso sul serio. Cinque anni dopo, il divario di posizionamento tra i siti che hanno ottimizzato e quelli che non l’hanno fatto è enorme.

I Core Web Vitals non sono un dettaglio tecnico. Sono diventati un criterio di selezione pari alla pertinenza dei contenuti sulle ricerche competitive. Su parole chiave con forte intento transazionale («agenzia SEO Ginevra», «creazione sito internet Svizzera»), un sito con un Lighthouse a 70 non si posiziona, anche con un contenuto oggettivamente superiore a quello del sito con Lighthouse 95 che occupa la prima posizione.

Questo articolo spiega cosa misurano davvero i Core Web Vitals, perché Google attribuisce loro tanta importanza e come rispettarli nel 2026.

Le tre metriche che contano

Google pubblica una decina di metriche di prestazione tramite Lighthouse. Solo tre fanno parte dei Core Web Vitals ufficiali nel 2026.

Largest Contentful Paint (LCP) misura il tempo di caricamento dell’elemento visibile più grande sullo schermo alla prima visualizzazione. Di solito è un’immagine hero, un titolo H1 o un video. L’obiettivo di Google: meno di 2,5 secondi. Oltre i 4 secondi, l’esperienza è giudicata scadente.

Interaction to Next Paint (INP) ha sostituito nel 2024 il vecchio First Input Delay (FID). L’INP misura il ritardo tra l’interazione dell’utente (clic, tocco, pressione di un tasto) e il momento in cui la pagina risponde visivamente. Obiettivo: meno di 200 ms. Oltre i 500 ms, scadente.

Cumulative Layout Shift (CLS) misura gli spostamenti visivi del layout durante il caricamento. L’avete visto tutti: state per cliccare un pulsante, in alto si carica un banner pubblicitario, il pulsante si sposta e cliccate su qualcos’altro. Obiettivo: un punteggio inferiore a 0,1.

Insieme, queste tre metriche misurano una cosa sola: la qualità reale dell’esperienza utente durante il caricamento e l’interazione. Non un punteggio astratto, non una media di marketing. Il tempo di attesa reale.

Perché Google attribuisce tanta importanza a queste metriche

Tre ragioni strutturali, in ordine di importanza.

Il mobile ha schiacciato il desktop. Nel 2026 il 65 % delle ricerche su Google proviene da smartphone. Su mobile, la minima lentezza ha un impatto enorme sull’esperienza utente: connessione 4G o 5G variabile, processore meno potente, attenzione breve. Google non può permettersi di spingere risultati lenti in prima posizione, altrimenti le persone usano meno Google.

La concorrenza dei social network e dell’IA. Quando cercate un’informazione, potete scegliere tra Google, TikTok (45 % degli under 30), ChatGPT e altri LLM con ricerca web. Google non ha più il monopolio. Se la sua esperienza diventa frustrante, i suoi utenti se ne vanno. Spingere siti lenti in prima posizione peggiora il suo prodotto.

La misurazione è diventata precisa e anonima. Con il Chrome User Experience Report (CrUX), Google misura i tempi di esperienza reali su decine di milioni di sessioni effettive, senza cookie individuali. Questi dati alimentano l’algoritmo in tempo reale. Un sito che peggiora i propri Core Web Vitals vede il traffico calare nelle settimane successive.

Cosa peggiora l’LCP

L’LCP è la metrica più legata alla stack tecnica del sito. Cinque cause principali.

Immagini troppo pesanti o non ottimizzate. Un’immagine hero da 2 MB su mobile = almeno 2 secondi di caricamento su una 4G media. La soluzione: compressione WebP o AVIF (formati moderni dal 30 al 50 % più leggeri del JPEG), immagini responsive con srcset adattato a ogni viewport e lazy loading per ciò che sta sotto la linea di piega.

Font web bloccanti. Un font personalizzato caricato in modo sincrono blocca il rendering finché non arriva. La soluzione: font-display: swap per mostrare subito un font di ripiego, oppure servire i font in locale per evitare la latenza di un servizio terzo.

CSS e JavaScript che bloccano il rendering. Qualsiasi file nel <head> senza async o defer blocca il rendering. La soluzione: estrarre il CSS critico inline nell’HTML, caricare il resto in modo non bloccante, suddividere i bundle JavaScript in chunk logici.

Tempo di risposta elevato. Un server che risponde in 500 ms (TTFB elevato) aggiunge meccanicamente 500 ms all’LCP. La soluzione: HTTP/2 o HTTP/3, compressione Brotli.

Stack tecnica inadatta. WordPress con 30 plugin, o una SPA React che idrata lato client una pagina editoriale, appesantiscono inevitabilmente l’LCP. La soluzione: scegliere una stack moderna adatta al tipo di pagina (Astro per l’editoriale, Next.js per l’interattivo, Remix per il transazionale).

Cosa peggiora l’INP

L’INP è legato alla quantità di JavaScript in esecuzione nel momento in cui l’utente interagisce con la pagina.

JavaScript sovradimensionato. Molti siti caricano 500 KB di JavaScript per una pagina che potrebbe funzionare con 50 KB. Ogni KB in più deve essere scaricato, analizzato, compilato ed eseguito. Su uno smartphone di fascia media, l’effetto è drammatico.

Long task bloccanti. Una funzione JavaScript che impiega più di 50 ms blocca il main thread. Se l’utente clicca in quel momento, l’interazione viene ritardata. La soluzione: spezzare i long task (setTimeout, requestIdleCallback, Web Worker per i calcoli pesanti).

Framework SPA usati male. React, Vue e Svelte sono eccellenti per le applicazioni. Per un sito vetrina sono sovradimensionati. Se usate React per una pagina «Chi siamo», pagate 200 KB di JS per niente.

Cosa peggiora il CLS

Il CLS è la meno tecnica delle tre metriche, ma la più visibile per l’utente.

Immagini senza dimensioni dichiarate. Un <img> senza width e height definiti provoca uno spostamento al caricamento. La soluzione: dichiarare sempre le dimensioni, come attributi HTML oppure in CSS con aspect-ratio.

Font web che cambiano il layout. Il passaggio da un font di ripiego al font personalizzato può spostare tutto il testo. La soluzione: scegliere un font di ripiego con metriche simili, oppure usare size-adjust in @font-face per precisare le dimensioni.

Contenuti iniettati in JavaScript dopo il primo rendering. Banner dei cookie, popup, widget di chat. La soluzione: riservare lo spazio con un segnaposto delle giuste dimensioni, oppure rinviare l’iniezione al momento opportuno (interazione dell’utente).

Pubblicità e contenuti incorporati di terzi. Gli iframe di YouTube, i widget di Twitter, i banner pubblicitari. La soluzione: riservare lo spazio con aspect-ratio o con un’altezza minima fissa.

Come testare il vostro sito

Tre strumenti da conoscere.

PageSpeed Insights (https://pagespeed.web.dev) fornisce il punteggio Lighthouse mobile e desktop, con raccomandazioni dettagliate. È lo strumento ufficiale di Google. Test puntuale, senza monitoraggio nel tempo.

Search Console (rapporto Core Web Vitals) fornisce i dati reali del vostro sito aggregati su 28 giorni, per gruppo di URL. È ciò che Google usa effettivamente per posizionarvi. Da tenere costantemente sotto controllo.

WebPageTest (https://webpagetest.org) fornisce un’analisi dettagliata del waterfall di caricamento. Eccellente per individuare i colli di bottiglia specifici.

Obiettivo 2026: Lighthouse mobile > 90 su PageSpeed Insights e il 75 % degli URL in stato «buono» nel rapporto Core Web Vitals di Search Console. Al di sotto, il vostro sito è penalizzato sulle ricerche competitive.

Cosa facciamo da Voren

Tutti i siti Voren sono progettati con i Core Web Vitals come vincolo architetturale, non come una verifica di fine progetto.

Stack adatta al tipo di pagina. Astro per i siti editoriali e aziendali (HTML statico con hydration parziale), Next.js per i siti fortemente interattivi, Remix per le applicazioni transazionali. Non consegniamo mai una SPA per un sito che non ne ha bisogno.

Immagini ottimizzate di default. Compressione WebP o AVIF automatica, immagini responsive con srcset, lazy loading sotto la linea di piega.

Font serviti in locale con font-display: swap. Niente Google Fonts in modo sincrono, nessun FOIT (Flash of Invisible Text) né FOUT visibile.

CSS critico inline. Il CSS della prima schermata è nel <head>, il resto viene caricato in modo non bloccante.

Lighthouse > 95 come obiettivo sui pacchetti Premium e Su misura, > 90 su Essenziale, misurato alla messa online.

La vera ragione che fa la differenza

Molte agenzie trattano i Core Web Vitals come un’ottimizzazione di fine progetto: si sviluppa il sito, lo si lancia, si guarda Lighthouse, si mettono le pezze. Funziona in parte, ma lascia sempre 10-20 punti sul tavolo.

La differenza si fa in fase di progettazione. Scegliere Astro invece di WordPress all’inizio del progetto vi fa guadagnare 30 punti su Lighthouse senza alcuno sforzo di ottimizzazione. Scegliere immagini compresse in WebP invece di PNG vi fa guadagnare 10 punti.

Quando queste scelte vengono fatte all’inizio del progetto, il vostro sito arriva in produzione con un Lighthouse a 95, senza ottimizzazioni faticose. Quando non vengono fatte, passate poi settimane a ottimizzare a posteriori, con guadagni marginali.

Per approfondire

Se il vostro sito ha un Lighthouse mobile inferiore a 75, è probabilmente la causa n° 1 della vostra stagnazione SEO. Prima di investire in contenuti o backlink, bisogna risolvere la base tecnica.

Richiedere un audit SEO gratuito: esaminiamo il vostro Lighthouse, i vostri Core Web Vitals, la vostra stack, e vi diciamo cosa mettere in priorità, in 7 giorni.

Scoprire i nostri pacchetti di creazione di siti: tutti i nostri siti vengono consegnati con un punteggio Lighthouse misurato alla messa online (da > 90 a > 95 secondo il pacchetto).