Come eseguire un audit dei Core Web Vitals nel 2026 (e cosa è cambiato da quando INP ha sostituito FID)

TL;DR: Nel 2026 i Core Web Vitals sono LCP, INP e CLS. Il FID è stato ritirato e l’INP lo ha sostituito il 12 marzo 2024. Il peso di ranking è inferiore a quanto sostengono molti SEO (la documentazione di Google ribadisce che la rilevanza batte l’esperienza di pagina), ma l’impatto sulla UX è concreto e l’audit resta conveniente. Questa è la guida che consegno ai clienti: tre soglie di metrica, strumenti in due passaggi (lab più field), una lista di fix ordinata per ritorno e una cadenza trimestrale che evita di far sprecare tempo all’ingegneria su task poco utili.

Eseguo audit trimestrali su un portafoglio di siti mid-market per mindnow e seojuice.io. Ogni volta qualcuno mi chiede se serve un altro sprint sui Core Web Vitals. La risposta onesta è quasi sempre no. Il protocollo è cambiato nel 2024, il peso di ranking è ridotto e la maggior parte di ciò che si legge sui CWV sovrastima il beneficio in traffico organico. L’audit però conta, perché le pagine lente continuano a drenare conversioni e l’INP è davvero diverso dal FID. Questo articolo è il playbook di audit: non un how-to tecnico sull’ottimizzazione dell’INP (il team di web.dev lo spiega meglio di me), ma il livello di interpretazione che ci sta sopra.

Cosa è cambiato nei Core Web Vitals tra il 2024 e il 2026

La novità principale: First Input Delay (FID) è stato deprecato e Interaction to Next Paint (INP) è diventato un Core Web Vital ufficiale il 12 marzo 2024. Il team di Chrome lo ha annunciato direttamente:

"INP diventerà ufficialmente un Core Web Vital e sostituirà FID il 12 marzo di quest’anno." Jeremy Wagner e Rick Viscomi, web.dev blog, marzo 2024

Se il tuo template di audit estrae ancora il FID, stai usando una metrica deprecata. Search Console ha rimosso il FID lo stesso giorno. PageSpeed Insights ora mostra l’INP. La libreria JavaScript Web Vitals v4 ha deprecato la misurazione del FID. Gli strumenti di laboratorio che riportano ancora il FID sono utili per il triage, non per decisioni di ranking.

Perché lo scambio. Il FID misurava solo la prima interazione su una pagina e solo il ritardo di input di quella interazione. Un sito poteva avere un primo click veloce e comunque bloccarsi a ogni click successivo. Inoltre era facilmente manipolabile: non si rinviava nulla al landing, poi si caricava tutto al secondo evento. L’INP colma entrambe le lacune campionando ogni interazione e includendo l’intero ritardo fino al paint successivo:

"INP migliora rispetto a FID osservando tutte le interazioni su una pagina, dal ritardo di input all’esecuzione degli event handler, fino a quando il browser dipinge il frame successivo." Jeremy Wagner e Barry Pollard, web.dev, Interaction to Next Paint

Effetto pratico sugli audit: la maggior parte dei siti che erano verdi su FID ora risultano gialli o rossi su INP. Il cambiamento è meccanico, non significa che il sito sia peggiorato. Pianifica il nuovo baseline prima di dire agli stakeholder che lo score è calato.

Altri due cambiamenti minori rientrano nella finestra 2024-2026. CrUX, la fonte di field-data dietro il report CWV di Search Console, ha aumentato la profondità del campionamento, quindi le soglie al 75° percentile si basano su più sessioni. LCP ha guadagnato una diagnostica di sotto-parti (TTFB, ritardo di caricamento risorsa, ritardo di render dell’elemento) in PageSpeed Insights, l’aggiunta di diagnostica più utile degli ultimi anni.

Le tre metriche attuali e le loro soglie di audit

Tre metriche, una tabella di soglia, applicata al 75° percentile del traffico reale su mobile e desktop separatamente. La pagina canonica di web.dev è esplicita sul ruolo:

"I Core Web Vitals sono il sottoinsieme di Web Vitals che si applica a tutte le pagine web, dovrebbe essere misurato da ogni proprietario di sito e viene mostrato in tutti gli strumenti Google." Philip Walton, web.dev, Web Vitals

Il taglio al 75° percentile è il dettaglio che più operatori ignorano. Non serve che ogni sessione rientri nella soglia, basta che lo facciano i tre quarti. Il segmento più lento di dispositivi, reti e pagine può restare nella fascia gialla e l’URL otterrà comunque la valutazione Good in CrUX.

Step di audit per ogni metrica. LCP: estrai le sotto-parti da PageSpeed Insights. Se il TTFB supera 800 ms, il fix è lato server o CDN, non front-end. Se domina il ritardo di render dell’elemento, il fix è il preload dell’immagine o CSS critico. INP: apri la pagina su un Android di fascia media, interagisci con ogni elemento cliccabile, osserva nel pannello Performance i long task oltre 50 ms. L’interazione più lenta è quella che fa score. CLS: scrolla la pagina su connessione lenta. Se il layout salta durante lo swap del font o il caricamento dell’immagine above-the-fold, il fix è spazio riservato (CSS aspect-ratio) o font-display swap con fallback metric-matched.

Un anti-pattern di audit da abbandonare: non ottimizzare il punteggio Performance di Lighthouse come proxy dei CWV. Il punteggio Performance è un composito di metriche lab ponderate che include Speed Index e Total Blocking Time, nessuna delle quali è un Core Web Vital. Un sito può fare 95 in Lighthouse Performance e fallire i CWV sui dati field perché Lighthouse simula un solo profilo dispositivo mentre i CWV misurano tutti i visitatori reali.

Come Google usa davvero i CWV nel ranking

Leggi la documentazione sull’esperienza di pagina di Google. La sintesi è secca:

"Google Search punta sempre a mostrare i contenuti più rilevanti, anche se l’esperienza di pagina è sotto la media." Google Search Central, Page Experience documentation

Questa frase è nascosta nelle FAQ sotto "Quanto conta l’esperienza di pagina per il ranking?". È la cosa più importante che Google abbia scritto pubblicamente sul peso dei CWV, e gran parte dei contenuti SEO la ignora. Rilevanza e autorità dominano. L’esperienza di pagina è uno dei tanti segnali che spinge il ranking quando la rilevanza è in pareggio.

Lo stesso documento attutisce la propria cautela. Google conferma che "I Core Web Vitals vengono usati dai nostri sistemi di ranking", e subito chiarisce: "Non esiste un singolo segnale. I nostri sistemi di ranking principali considerano una varietà di segnali che si allineano all’esperienza di pagina complessiva." (Entrambe le citazioni dalla stessa documentazione.)

Come leggere le tre frasi insieme. I CWV sono nel sistema. Non pesano molto. Non esiste un unico punteggio di page experience che ribalti il ranking; è un cluster di segnali che aiuta Google a sciogliere i pareggi quando gli altri segnali sono simili. La cornice onesta per gli stakeholder: migliorare i CWV su una pagina con contenuti deboli e pochi backlink non la salverà. Migliorare i CWV su una pagina con contenuti forti e link autorevoli che sta in posizione 4 o 5 può plausibilmente contribuire a un passaggio in posizione 2 o 3 in alcuni mesi. La matematica parte dalla rilevanza.

Per lo scenario dei segnali di ranking più ampio, il nostro articolo su confidence e audit dei segnali di ranking copre il resto. I CWV sono un pannello di una dashboard più vasta: trattali così.

Cosa guardano davvero i motori di ricerca AI

Protocollo diverso. Google AI Mode, la navigazione di ChatGPT, Perplexity e lo strumento web di Claude sono sistemi di retrieval-and-summarization. Recuperano la tua pagina, ne analizzano i contenuti pertinenti e li citano o parafrasano all’utente. La velocità di pagina nel senso dei Core Web Vitals non rientra nei loro criteri di selezione; il fetch è server-side e il loro budget di tempo è più generoso di quello di un utente reale.

Ciò che conta per loro: reattività del server (un TTFB di 30 secondi fa scadere il crawler), HTTPS, contenuto che si renda senza JavaScript (o che il fetcher possa eseguire), dati strutturati parsabili e HTML semantico chiaro. Coincidono con i CWV solo sul TTFB; il resto è un audit diverso. Ottimizzare l’INP per la navigazione di ChatGPT è lavoro sprecato: l’agente non interagisce con la tua pagina.

Implicazione pratica per l’audit 2026. Mantieni un singolo target TTFB (sotto 800 ms) che serva entrambi gli audit. Scollega il lavoro su INP e CLS da quello sull’AI search; hanno priorità differenti. Se il tuo mix di traffico si sta spostando verso sessioni riferite dall’AI, l’ora di ingegneria rende di più su renderabilità del contenuto e dati strutturati che su 50 ms tolti a un’interazione.

Strumenti per misurare i Core Web Vitals nel 2026

Il toolset si è consolidato dal 2022. Sei strumenti coprono il workflow lab-plus-field necessario alla maggior parte degli operatori.

Workflow in due passaggi. Inizia con PageSpeed Insights su un singolo URL per avere lab e field affiancati. Il numero lab dice cosa è tecnicamente raggiungibile su un profilo dispositivo pulito; il numero field dice cosa vive l’utente reale. Quando divergono, conta il field per il ranking e il gap è la diagnosi. Lab verde + field rosso indica che la tua user base usa hardware o reti più lenti dei dev.

Per report ripetibili e tracking trend, il SEOJuice Lighthouse Score Checker esegue una scansione reale della pagina e ti fornisce un URL condivisibile più i dati storici; è ciò che usiamo internamente per monitorare i progressi dei clienti senza rilanciare Lighthouse a ogni ciclo di audit. La questione più ampia di interpretazione del punteggio Lighthouse (cosa conta come score sufficiente, come si compongono le categorie) è trattata nel nostro breakdown sul punteggio SEO di Lighthouse.

Se vuoi vedere come i CWV correlano effettivamente con il traffico organico su una popolazione reale di pagine, il nostro calculatore CWV Impact mostra le correlazioni aggregate di oltre 164 000 pagine auditate. Il risultato principale è coerente con il framing di Google: le correlazioni sono reali ma moderate e variano per metrica. CLS è la più debole; LCP e INP sono più forti ma comunque sotto quanto dichiarano molte campagne marketing sui CWV.

Fix comuni ordinati per ritorno

Le ore di ingegneria sono finite. Ordina i fix per impatto sulla metrica peggiore, non per facilità di rilascio. Di seguito la lista di priorità che uso dopo sette anni di audit CWV.

Tier 1, tempo di risposta del server. Se il TTFB supera 800 ms, ogni fix front-end viene misurato su una linea di partenza in ritardo. Metti un CDN davanti all’origine. Metti in cache la risposta HTML dove possibile. Sposta le query al database fuori dal critical render path. Un miglioramento di 400 ms sul TTFB spesso sposta l’LCP di 600 ms perché i caricamenti a valle si anticipano in blocco.

Tier 1, strategia immagini. L’elemento LCP è di solito un’immagine. Precaricala con un hint ad alta priorità. Servi dimensioni responsive via srcset. Usa AVIF o WebP con fallback JPEG. Lazy-load tutte le altre immagini con l’attributo nativo loading="lazy". Non mettere in lazy-load l’immagine LCP: è l’autogol più comune negli audit CWV.

Tier 2, igiene JavaScript. Defer gli script non critici. Splitta i bundle. Audita i tag di terze parti; la maggior parte dei siti ha 4-6 script caricati dal tag manager che non meritano più tempo di main-thread. Le regressioni INP quasi sempre risalgono a uno script che schedula un long task durante l’interazione utente. Code-split dei componenti interattivi pesanti, in particolare search, filter o carousel.

Tier 2, caricamento font. Usa font-display: swap con fallback di sistema metric-matched così lo swap non genera shift. Precarica il file font principale. Se carichi tre web font, eliminale due.

Tier 3, clean-up. Imposta width e height espliciti su ogni immagine e embed. Riserva spazio per gli ads con min-height. Sposta i componenti soggetti a CLS (notifiche, banner, cookie banner) sotto la piega o rendili con trasformazioni translate che non intaccano il layout.

Cosa non fare. Non inseguire un punteggio Performance 100 in Lighthouse. Non bloccare un rilascio per una regressione CLS di 0,01. Non permettere a uno stakeholder CWV di chiedere un terzo audit prima che il secondo round di fix sia stato deployato. La metrica è rumorosa e il report ha un ritardo.

Cosa sbagliano gli AI Overviews sui CWV

Tre pattern ricorrenti nelle risposte AI Overview quando interroghi "core web vitals 2026" o simili.

Il primo è il fantasma del FID. Gli AI Overview elencano spesso ancora il FID tra i Core Web Vitals. I dati di training sono anteriori a marzo 2024 e l’annuncio di deprecazione non ha peso sufficiente nell’indice. Verifica sempre su web.dev o Search Central, non sul riassunto AI.

Il secondo è l’inflazione del peso di ranking. Molti riassunti AI riducono il linguaggio sfumato di Google a "I Core Web Vitals sono un fattore chiave di ranking". L’espressione "fattore chiave" compare nei post di marketing memorizzati dal modello; la documentazione Google reale dice che la rilevanza batte l’esperienza di pagina. La compressione azzera la sfumatura.

Il terzo è il loop auto-referenziale AI-search. Gli AI Overview consigliano di ottimizzare per i motori di ricerca AI via CWV. Come visto, i motori AI non misurano il tuo INP. La velocità di pagina in senso CWV è irrilevante per il retrieval. Il training set confonde "sito veloce = buon SEO" senza distinguere la superficie di ricerca.

Effetto netto per gli operatori. Tratta le risposte AI Overview sui CWV come punto di partenza, non come fonte definitiva. Verifica sempre sulla documentazione Google e su web.dev prima di agire.

La cadenza di audit trimestrale

Quattro checkpoint l’anno, novanta minuti ciascuno. È il ritmo di cui la maggior parte dei siti mid-market ha bisogno. Più frequente è overhead; meno frequente e le regressioni atterrano prima che l’audit le intercetti.

Scarica il report Core Web Vitals di Search Console. Nota i gruppi di URL che hanno cambiato stato dall’ultimo trimestre. Per ogni gruppo cambiato, esegui PageSpeed Insights su un URL rappresentativo e cattura le diagnostiche di sotto-parti.

Esegui uno scan lab sulle tue dieci landing page principali per traffico. Confronta con il trimestre precedente. Se una pagina è peggiorata di oltre 200 ms in LCP o 50 ms in INP, segnala per revisione ingegneristica.

Campiona i field data dal tuo RUM (Web Vitals library v4). I dati CrUX che usa Google hanno 28 giorni di ritardo; i tuoi dati sono in tempo reale. Confronta la forma della distribuzione, non solo le medie.

Prioritizza la lista di fix secondo i tier sopra. Rilascia un elemento di Tier 1 per trimestre, anche quando è scomodo. Il clean-up di Tier 3 viaggia insieme ai normali rilasci. Per i siti che già fanno un audit SEO trimestrale, il nostro prodotto di audit automatizza lo scan lab di questo checkpoint così il tempo manuale va sull’interpretazione.

Cosa NON risolve questo audit

I Core Web Vitals sono un segnale di UX e di ranking leggero. Non sono un segnale di qualità contenutistica, di backlink o di brand trust. Se la tua pagina è in seconda pagina su una query competitiva, correggere il CLS non la porterà in prima. Prima servono rilevanza e autorità.

I CWV non risolvono neppure la conversione nel modo che alcuni operatori si aspettano. Un LCP più rapido di 200 ms è correlato a migliori conversioni, ma l’elasticità varia molto per tipologia di sito. I checkout e-commerce reagiscono forte; i long-form reagiscono debolmente. Misura il tuo lift prima di costruire il business case.

E i CWV non risolvono l’audit AI-search. Protocollo, fetcher e priorità diversi. Se il tuo mix di traffico si sta spostando verso sessioni AI-referred, l’audit page-experience è lo strumento sbagliato.

FAQ

Il FID è ancora un Core Web Vital? No. Il FID è stato deprecato e rimosso dal programma il 12 marzo 2024. L’INP ne ha preso il posto. Search Console ha rimosso il FID dal report CWV lo stesso giorno. Aggiorna il template di audit se lo usi ancora.

Qual è la soglia dell’INP? 200 millisecondi o meno è Buono. 200-500 ms è Da migliorare. Oltre 500 ms è Poor. La soglia si applica al 75° percentile delle interazioni reali su mobile e desktop separati.

Quanto influiscono i Core Web Vitals sul ranking Google? Meno di quanto afferma molto contenuto SEO. La documentazione di page-experience di Google dice esplicitamente che la Ricerca "punta sempre a mostrare i contenuti più rilevanti, anche se l’esperienza di pagina è sotto la media". I CWV sono un segnale reale ma uno fra tanti, e rilevanza e autorità dominano. Consideralo un tie-breaker tra pagine simili, non una leva primaria di ranking.

I motori di ricerca AI come ChatGPT o Google AI Mode usano i Core Web Vitals? No, non nello stesso modo. I loro fetcher recuperano le pagine lato server e ne analizzano il contenuto per il riassunto. La velocità di pagina in senso CWV è irrilevante per il retrieval. Disponibilità server (TTFB), render senza JS e dati strutturati sono le priorità; INP e CLS no.

Qual è l’errore di audit CWV più comune? Ottimizzare il punteggio Performance di Lighthouse come proxy dei CWV. Lighthouse Performance è un composito lab ponderato che include metriche fuori CWV (Speed Index, Total Blocking Time). Una pagina può fare 95 in Lighthouse ed essere bocciata sui CWV field perché Lighthouse simula un solo profilo dispositivo mentre i CWV misurano tutti i visitatori reali.

Con che frequenza devo auditare i Core Web Vitals? Trimestralmente è sufficiente per la maggior parte dei siti mid-market. Più spesso è overhead; i dati CrUX hanno 28 giorni di ritardo e il tuo ciclo di fix raramente è più veloce. Usa il monitoraggio RUM continuo (Web Vitals library v4) per allarmi real-time tra un audit e l’altro.