First Input Delay (FID): metrica ritirata

TL;DR — First Input Delay (FID) è una metrica vecchia. Misurava quanto a lungo la pagina faceva aspettare qualcuno prima di poter persino iniziare a reagire al suo primo clic o tocco. Google l’ha ritirata a marzo 2024 e l’ha sostituita con INP, poi l’ha rimossa completamente dai suoi strumenti a settembre 2024. Quindi non c’è più nulla da correggere, ma vale la pena sapere che cos’era se trovi «FID» nei vecchi report.

Che cos’era First Input Delay

Quando tocchi un pulsante e per un istante non succede nulla, la pagina sembra rotta, anche se sembra caricata. First Input Delay (FID) era il modo di Google per dare un numero a quella specifica frustrazione.

FID misurava una sola cosa circoscritta: l’intervallo tra la prima interazione con una pagina (un clic, un tocco o la pressione di un tasto) e il momento in cui il browser era effettivamente libero di iniziare a rispondere. Se il browser era occupato a eseguire JavaScript quando toccavi lo schermo, il tocco doveva aspettare in coda. Quella attesa era il «delay».

Due cose che non misurava:

• Quanto tempo impiegava il codice del pulsante a essere eseguito una volta iniziato.
• Quanto tempo impiegava la pagina ad aggiornarsi visivamente dopo.

Solo l’attesa prima che potesse iniziare qualsiasi cosa. Questa specificità è uno dei motivi principali per cui alla fine è stata sostituita.

Che cosa contava come buon punteggio

FID veniva misurata in millisecondi:

• Buono: 100 ms o meno
• Da migliorare: 100–300 ms
• Scarso: oltre 300 ms

Perché non devi più preoccupartene

Questa è la parte importante per chi legge nel 2026: FID è ritirata. Google l’ha sostituita come Core Web Vital con INP (Interaction to Next Paint) il 12 marzo 2024; Search Console ha smesso di mostrare FID lo stesso giorno. PageSpeed Insights e l’API CrUX hanno continuato a riportarla un po’ più a lungo, poi l’hanno rimossa il 9 settembre 2024. Se un tutorial o una vecchia dashboard elenca ancora FID come Core Web Vital attuale, quel contenuto non è aggiornato.

INP fa lo stesso lavoro meglio: invece di misurare solo l’attesa della prima interazione, misura la reattività completa di ogni interazione durante una visita. Se oggi vuoi rendere il sito più scattante, la metrica da osservare è INP, non FID.

Vuoi la storia completa — le soglie esatte, perché FID è stata progettata in modo così circoscritto, dove si trovano ancora i vecchi dati FID e come si rapporta a INP? Passa alla scheda Advanced.

TL;DR — FID è stata il Core Web Vital della reattività fino a quando INP l’ha sostituita il 12 marzo 2024, la stessa data in cui Search Console l’ha rimossa dal report. Gli strumenti Chrome, PageSpeed Insights e l’API CrUX live l’hanno mantenuta un po’ più a lungo e l’hanno eliminata il 9 settembre 2024, ciascuno secondo il proprio calendario. Misurava solo il ritardo di input della prima interazione, non il tempo di esecuzione dell’handler né il repaint, deliberatamente, per evitare incentivi perversi. Soglie: buono ≤100 ms, scarso >300 ms al p75, solo dati sul campo (Total Blocking Time era il proxy di laboratorio, una diagnostica correlata, non una formula di conversione). Non confondere queste soglie con i 200/500 ms di INP e non provare a convertire il numero di una metrica in quello dell’altra. Una FID scarsa dipendeva dalla contesa sul main thread, cioè task JavaScript lunghi, che è esattamente ciò che causa INP e TBT scarsi; quindi le correzioni storiche sono ancora utili. I dati FID storici sopravvivono nel dataset CrUX BigQuery (fino alla release 202409), ma sono spariti ovunque dai sistemi live.

Che cosa misurava davvero FID

La definizione di Google era precisa. Secondo web.dev: “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.”

Leggilo con attenzione, perché l’ambito è tutta la storia. FID catturava il ritardo prima che potesse iniziare l’elaborazione, e nient’altro. Non quanto tempo impiegava l’event handler. Non quanto tempo impiegava la pagina a dipingere il risultato. Solo l’attesa.

Perché il browser non era «in grado di iniziare»? web.dev è diretto sulla causa: “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” C’è un solo main thread e, se sta analizzando o eseguendo JavaScript quando l’utente agisce, l’interazione resta in coda finché il task non termina. Faccio lo stesso punto nella mia guida Ahrefs su FID: esiste un solo main thread, JavaScript compete per eseguire task su di esso e, mentre un task è in esecuzione, la pagina non può rispondere all’input; quel blocco è il ritardo realmente percepito dall’utente.

Perché FID misurava solo il ritardo (non l’intera interazione)

Sembra un difetto di progettazione finché non si comprende il ragionamento. Google misurava solo il ritardo di input di proposito. Inserire nel calcolo il tempo di esecuzione dell’handler e il repaint avrebbe potuto, come spiega web.dev, incentivare gli sviluppatori a manipolare la metrica: avrebbero potuto avvolgere la logica dell’event handler in una callback asincrona per separarla dal task dell’interazione e far sembrare migliore il numero, mentre l’esperienza reale sarebbe peggiorata. Quindi FID è rimasta circoscritta.

Questa specificità è anche il limite fatale di FID. Una pagina poteva avere una FID eccellente e sembrare comunque lenta, perché ogni interazione dopo la prima non veniva misurata e la parte lenta di un’interazione è spesso l’elaborazione e il repaint ignorati da FID. È proprio il vuoto che INP è stata costruita per colmare.

Le soglie — e quella che molti sbagliano

Misurata al 75° percentile dei caricamenti di pagina, separati tra mobile e desktop. Le indicazioni di web.dev dicevano semplicemente che i siti dovevano puntare a un First Input Delay di 100 millisecondi o meno. Anche il mio articolo su FID usa gli stessi valori: buono ≤100 ms, da migliorare >100 ms e ≤300 ms, scarso >300 ms.

L’errore comune: confondere le soglie di FID con quelle di INP. Sono numeri diversi per metriche diverse. FID = 100 ms buono / 300 ms scarso. INP = 200 ms buono / 500 ms scarso. Diversi riepiloghi di terze parti, e perfino passaggi di contenuto automatizzati, confondono le due metriche; quindi, se vedi citati «200 ms» come soglia buona di FID, è sbagliato.

FID era una metrica solo da campo

Non potevi mai ottenere FID da Lighthouse o da uno strumento di laboratorio, perché richiedeva la prima interazione reale di un utente reale: web.dev afferma chiaramente che FID è una metrica misurabile solo sul campo, poiché richiede che un utente reale interagisca con la pagina. Gli strumenti di laboratorio non fanno clic, quindi non avevano nulla da misurare per FID.

Il sostituto di laboratorio è sempre stato Total Blocking Time (TBT). Come scrivo nella mia guida a PageSpeed Insights, nei dati di laboratorio non troverai FID o INP: richiedono clic sulla pagina che i test di laboratorio non riproducono, quindi usi Total Blocking Time come metrica proxy su cui lavorare. Il rapporto ha superato FID: oggi TBT è il proxy di laboratorio per INP.

Vale la pena formulare chiaramente una precisazione: TBT è una diagnostica correlata, non una formula di conversione. Non è mai esistita un’equazione che trasformasse un numero TBT in un numero FID esatto e non esiste nemmeno per INP: un punteggio TBT scarso indica che il lavoro sul main thread è probabilmente una causa, non quale sarebbe stato il tuo FID o INP sul campo.

Perché FID è stata ritirata: la transizione a INP

La sostituzione di FID era stata annunciata con largo anticipo. Secondo web.dev, INP è diventata ufficialmente un Core Web Vital e ha sostituito FID il 12 marzo 2024, quando FID è stata deprecata e rimossa dal programma. La motivazione dichiarata da Google: con il tempo è diventato chiaro che serviva una nuova metrica per catturare aspetti dell’interattività che FID non rilevava.

La timeline aveva due momenti distinti, da tenere separati perché è facile (e comune, anche nei contenuti automatizzati) fonderli in un’unica data:

1. 12 marzo 2024 — ritirata come Core Web Vital. INP ha preso il posto di FID; FID non faceva più parte dell’insieme Core rilevante per il ranking. Search Console ha rimosso FID dal suo report Core Web Vitals lo stesso giorno.
2. 9 settembre 2024 — rimossa dagli strumenti, secondo calendari specifici dei prodotti. Secondo web.dev, a quella data FID non era più supportata negli strumenti Chrome. PageSpeed Insights ha smesso di mostrare i dati FID degli utenti reali e l’API CrUX ha smesso di fornire la metrica in futuro; il dataset CrUX BigQuery ha smesso di aggiungere nuovi campi FID a partire dalla release 202409, anche se i mesi precedenti sono rimasti interrogabili.

Non è corretto dire che ogni superficie Google abbia rimosso FID il 9 settembre: il termine di Search Console era sei mesi prima, legato alla sostituzione con INP, non alla successiva pulizia degli strumenti.

L’articolo di web.dev su FID ora inizia con l’avviso del ritiro: First Input Delay non è più un Core Web Vital ed è stata sostituita dalla metrica Interaction to Next Paint (INP). Anche la documentazione attuale di Google Search Central sui Core Web Vitals non cita affatto FID: tratta solo LCP, INP e CLS. Quando il documento ufficiale sul ranking smette di nominare una metrica, è difficile immaginare un ritiro più chiaro.

FID e INP: che cosa è cambiato

Le due metriche misurano cose davvero diverse, ed è per questo che non puoi semplicemente mappare l’una sull’altra:

Il filo conduttore è questo: FID misurava la porta d’ingresso di una singola interazione; INP misura l’intero percorso di ogni interazione. Non esiste una formula che converta un vecchio numero FID in un numero INP equivalente e il FID di una pagina rispetto alle altre non predice il suo ranking INP rispetto alle stesse pagine: misurano insiemi di interazioni diversi rispetto a endpoint diversi, quindi qualsiasi somiglianza tra i due numeri in una pagina è casuale, non una regola. Vedi Interaction to Next Paint per l’analisi completa della metrica che l’ha sostituita.

Dove si trovano ancora i vecchi dati FID

Il ritiro non ha fatto evaporare lo storico. Ecco che cosa è sparito e che cosa resta:

• Sparito (live/attuale): il report Core Web Vitals di Search Console ha rimosso FID il 12 marzo 2024, il giorno in cui INP ha preso il suo posto. L’interfaccia di PageSpeed Insights e l’API CrUX live hanno continuato a riportarla un po’ più a lungo e si sono fermate il 9 settembre 2024.
• Ancora presente (storico): i dati FID precedenti al termine restano interrogabili nel dataset pubblico CrUX BigQuery, ma solo fino al dataset 202409; BigQuery ha smesso di aggiungere nuovi campi FID a partire da quella release, anche se i mesi precedenti sono rimasti. Se devi ricostruire la vecchia storia della reattività di un sito, è lì che devi guardare, non negli strumenti live. Fissa il mese del dataset quando citi un numero, etichettalo come storico e non trattare una cifra FID legacy come numericamente confrontabile con una cifra INP attuale: non esiste una conversione tra le due (vedi la tabella di confronto).

FID conta ancora oggi?

Direttamente, no: non c’è più nulla da misurare o riportare, quindi non c’è nulla da «correggere». Ma le cause di una FID scarsa e le cause di un INP scarso sono quasi identiche: task JavaScript lunghi che monopolizzano il main thread. Quindi il lavoro già fatto per migliorare FID non è stato sprecato. Come segnalo nella mia guida su FID, anche se FID è stata sostituita da INP a marzo 2024, vale ancora la pena lavorare sugli stessi problemi di fondo: molte delle cose che migliorano TBT e FID migliorano anche INP.

Le correzioni che riducevano FID sono le stesse che oggi aiutano INP e TBT:

• Riduci la quantità di JavaScript che invii.
• Carica JavaScript più tardi quando puoi (async/ defer).
• Dividi i task lunghi con il code splitting, così nessun singolo task monopolizza il main thread.
• Sposta il lavoro fuori dal main thread usando i web worker.
• Usa il rendering lato server o il prerendering per ridurre il lavoro lato client.

FID è mai stata un grande fattore di ranking?

Anche quando era attiva, FID, come parte dei Core Web Vitals, non è mai stata un segnale di ranking pesante. I rappresentanti di Google hanno descritto ripetutamente i Core Web Vitals più come un criterio di spareggio che come un segnale primario, applicato solo quando gli altri elementi sono più o meno equivalenti. La mia interpretazione, nella mia guida ai Core Web Vitals, è la stessa: “I don’t think Core Web Vitals have much impact on SEO and, unless you are extremely slow, I generally won’t prioritize fixing them.” FID veniva raramente isolata nei commenti dei rappresentanti: quasi sempre se ne parlava come parte del pacchetto Core Web Vitals, non come leva di ranking autonoma.

Bing e FID

Qui non esiste di fatto un aspetto specifico di Bing. Bing non ha mai adottato i Core Web Vitals come segnale di ranking nominato nel modo in cui ha fatto Google e non ha mai pubblicato proprie soglie FID (o INP). Bing considera in generale importanti le pagine veloci e reattive, ma FID è stata una metrica dell’ecosistema Google dall’inizio alla fine.

Dove andare dopo

FID si trova sotto l’iniziativa Web Vitals, nel cluster Web Performance. Le metriche più rilevanti per FID sono:

• Interaction to Next Paint — il Core Web Vital che l’ha sostituita e quello da ottimizzare davvero oggi.
• Total Blocking Time — il proxy di laboratorio che sostituiva FID (e ora sostituisce INP) quando non potevi misurare interazioni reali.
• Core Web Vitals — il trio rilevante per il ranking (LCP, INP, CLS) di cui FID faceva parte.

Riepilogo AI

Una sintesi della versione Avanzata:

• FID = un Core Web Vital ritirato per la reattività. Misurava solo il ritardo di input della prima interazione, cioè l’attesa prima che il browser potesse iniziare a elaborare l’event handler, non il tempo di esecuzione dell’handler né il repaint.
• Soglie: buono ≤ 100 ms, da migliorare 100–300 ms, scarso > 300 ms, al 75° percentile, con distinzione mobile/desktop. Solo dati sul campo: mai misurabile in Lighthouse; Total Blocking Time era il proxy di laboratorio.
• Non confondere le soglie: FID = 100/300 ms; INP = 200/500 ms. Metriche diverse, numeri diversi.
• Causa di una FID scarsa: contesa sul main thread, cioè task JavaScript lunghi. È la stessa causa principale di INP e TBT scarsi.
• Timeline del ritiro: sostituita da INP il 12 marzo 2024, lo stesso giorno in cui Search Console ha rimosso FID dal report. Gli strumenti Chrome, PageSpeed Insights e l’API CrUX live hanno smesso di supportarla il 9 settembre 2024, ciascuno secondo il proprio calendario, non con un unico termine universale. L’attuale documentazione di Google Search Central sui CWV non la cita più.
• FID e INP: FID misurava il ritardo della prima interazione; INP misura la latenza completa di tutte le interazioni (ritardo + elaborazione + presentazione). Non esiste una formula che converta il numero di una metrica nell’altra.
• Dati storici: spariti dagli strumenti live; i dati FID precedenti al termine restano nel dataset CrUX BigQuery fino alla release 202409. Fissa il mese del dataset e non confrontarli numericamente con l’INP attuale.
• Nessuna conversione, mai: TBT è un proxy di laboratorio correlato per FID e INP, non una formula che traduca l’una nell’altra.
• Conta ancora? Non c’è nulla da correggere direttamente, ma le correzioni JavaScript (ridurre/posticipare JS, dividere i task lunghi, web worker e SSR) si trasferiscono direttamente a INP e TBT.
• Peso sul ranking: minore anche quando era attiva: i CWV erano descritti come criterio di spareggio; Patrick dice di non dare loro priorità a meno che il sito non sia estremamente lento. Bing non ha un equivalente di FID.

Documentazione ufficiale

Documentazione delle fonti primarie su FID e sul suo ritiro.

Google / web.dev

• First Input Delay (FID) — definizione della metrica, soglie, motivo per cui veniva misurato solo il ritardo di input e avviso del ritiro (Philip Walton; aggiornato il 2024-10-06).
• Chrome termina il supporto a First Input Delay — la rimozione di settembre 2024 dagli strumenti Chrome, da PSI e dall’API CrUX (Rick Viscomi).
• Interaction to Next Paint diventa un Core Web Vital il 12 marzo — l’annuncio che INP avrebbe sostituito FID (Jeremy Wagner, Rick Viscomi).
• Capire i Core Web Vitals e i risultati della Ricerca Google — l’attuale documento sul ranking, che ora elenca solo LCP, INP e CLS (non FID).
• Interaction to Next Paint (INP) — la metrica che ha sostituito FID.

MDN

• Glossario First Input Delay (FID) — una breve definizione di riferimento.

Bing / Microsoft

• Nessuna specifica per FID. Bing non ha mai pubblicato soglie FID né nominato i Core Web Vitals come segnale di ranking proprio.

Citazioni dalla fonte

Dichiarazioni ufficiali tratte dalla documentazione web.dev di Google. Ogni link è un deep link che porta al passaggio citato nella pagina fonte.

Google / web.dev — che cosa misurava FID

• “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” Vai alla citazione
• “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” Vai alla citazione

Google / web.dev — la soglia «buona»

• “To provide a good user experience, sites should strive to have a First Input Delay of 100 milliseconds or less.” Vai alla citazione

Scheda rapida First Input Delay

Stato: ritirata. Conservala per leggere dati storici e vecchi report, non come obiettivo di ottimizzazione.

FID in breve

FID e INP — non confonderle

Date chiave

• 12 marzo 2024 — INP sostituisce FID come Core Web Vital; Search Console rimuove FID dal report lo stesso giorno.
• 9 settembre 2024 — gli strumenti Chrome, PageSpeed Insights e l’API CrUX live smettono di supportare FID, ciascuno secondo il proprio calendario (non è la stessa data di GSC).

Dove si trovano ora i dati FID

• Strumenti live (UI PSI, GSC, API CrUX): spariti (GSC dal 12 marzo 2024; PSI/CrUX dal 9 settembre 2024).
• Storico precedente al termine: dataset CrUX BigQuery, fino alla release 202409. Non confrontare direttamente i suoi numeri con l’INP attuale: non esiste una conversione.

Correggere il problema di fondo (ora aiuta INP/TBT)

• Ridurre JavaScript · rimandare il caricamento async/defer · dividere i task lunghi (code splitting) · web worker · SSR/prerendering.

Errori da evitare con i dati FID legacy

Trattare FID come un Core Web Vital attuale

FID è stata sostituita da INP a marzo 2024 e rimossa dalle superfici di reporting attuali di Chrome più avanti nello stesso anno. Usa INP per il lavoro corrente sulla reattività; conserva FID solo quando interpreti dataset storici.

Confrontare FID e INP con le stesse soglie

Le soglie storiche Buono/Scarso di FID erano 100/300 ms; quelle di INP sono 200/500 ms. I numeri non sono intercambiabili perché FID misurava solo il ritardo prima dell’handler, mentre INP copre l’interazione fino al paint successivo.

Cercare FID in un test di laboratorio

FID richiedeva il primo input reale di un utente ed era solo da campo. Total Blocking Time era il proxy di laboratorio; un risultato Lighthouse non è mai stato un’osservazione FID diretta.

Ottimizzare un punteggio ritirato invece del problema dell’utente

Non conservare una dashboard FID come obiettivo. Dividi i task lunghi del main thread e riduci il JavaScript bloccante, poi misura la reattività attuale con INP sul campo.

Mettiti alla prova: First Input Delay (FID)

Cinque domande rapide su ciò che misurava FID e sul motivo per cui è stata ritirata. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche