Il First Input Delay (FID), noto come ritardo prima interazione, è una metrica che misura il tempo che trascorre tra l’interazione iniziale di un utente con una pagina (come un clic su un link, un tocco su un pulsante o l’uso di un controllo personalizzato basato su JavaScript) e il momento in cui il browser risponde concretamente a tale interazione, come indicato nelle guide di Google e nell’approfondimento su web.dev.
Da un punto di vista tecnico, la metrica quantifica il periodo di tempo, misurato in millisecondi, tra la prima azione intrapresa dall’utente su una pagina web e la risposta del browser a questa azione. È importante notare che questa misura non include il tempo trascorso durante lo scorrimento o lo zoom della pagina.
Come misurare il First Input Delay
La misura del ritardo prima interazione è ottenuta dalla prima azione interattiva eseguita dall’utente ed è particolarmente rilevante per le pagine in cui gli utenti devono compiere azioni.
Un FID basso indica una maggiore usabilità della pagina, mentre un FID alto si traduce in un’esperienza utente meno soddisfacente.
Il periodo di tempo tra il rendering del contenuto sulla pagina e la completa reattività di tutte le funzionalità all’interazione umana può variare notevolmente in base alle dimensioni e alla complessità del codice JavaScript che deve essere scaricato, elaborato e eseguito sul thread principale, nonché alla velocità del dispositivo o alla sua mancanza (come nel caso dei dispositivi mobili di fascia bassa), come illustrato dagli sviluppatori di Mozilla.
Per ridurre il tempo di inizializzazione del sito e mitigare i ritardi iniziali di input, è fondamentale ottimizzare il sito web e ridurre le attività che richiedono molto tempo di esecuzione.
Anche il FID rimane una metrica misurabile solo sul campo. Questo perché richiede l’interazione di un utente reale con la tua pagina e non può quindi essere valutato in un ambiente di laboratorio.
Tuttavia, c’è una metrica chiamata Total Blocking Time (TBT), cioè il tempo di blocco totale, che può essere misurata in laboratorio, presenta una forte correlazione con il FID sul campo e cattura anche i problemi che influiscono sull’interattività.
Inoltre, le ottimizzazioni che migliorano il TBT in laboratorio portano dei miglioramenti anche al FID.
Esistono quattro strumenti che possiamo utilizzare per misurare il FID:
- PageSpeed Insights
- La libreria JavaScript web-vitals
- Chrome User Experience Report
- Search Console
Data la variabilità prevista nei valori del FID, è cruciale esaminare la distribuzione dei valori in un rapporto sul FID e concentrarsi sui percentili più elevati.
Anche se la soglia del 75° percentile è la scelta comune per tutti i dati vitali fondamentali, Google consiglia specificamente di valutare il 95° e il 99° percentile per il FID.
Questi percentili mostrano le prime esperienze estremamente negative degli utenti con il tuo sito e indicano le aree che richiedono miglioramenti più urgenti.
Come ottimizzare il First Input Delay
Tra le diverse misure che possono essere adottate per ridurre il ritardo nella prima interazione, possiamo includere:
- Riduzione dell’impatto del codice di terze parti
- Diminuzione del tempo necessario per l’esecuzione di JavaScript
- Minimizzazione del carico di lavoro sul thread principale
- Riduzione del numero di richieste e delle dimensioni dei dati da trasferire
In generale, la principale causa di un basso FID è l’esecuzione intensiva di JavaScript, quindi l’ottimizzazione del modo in cui JavaScript viene analizzato, compilato ed eseguito sulla tua pagina web avrà un impatto diretto sulla sua riduzione.
Per ottimizzare questo aspetto e diminuire l’occupazione del thread principale (che impedisce al browser di rispondere alle interazioni dell’utente), è possibile seguire alcune best practise, come:
- Ottimizzare la pagina per rendere il contenuto subito disponibile all’interazione
- Ridurre il tempo di esecuzione di JavaScript, ritardando l’esecuzione di JavaScript non essenziale e minimizzando l’uso di polyfill non necessari
- Suddividere compiti lunghi in attività più piccole ed asincrone
- Utilizzare un web worker, che consente l’esecuzione di JavaScript su un thread separato in background
Google sostituirà FID con INP
L‘Interaction to Next Paint (INP) sostituirà il First Input Delay (FID) come metrica delle Core Web Vitals a partire da marzo 2024.
In un recente articolo abbiamo spiegato cos’è l’Interaction to Next Paint. INP è una metrica che utilizza dati provenienti dall’API Event Timing e valuta la reattività di una pagina web!
Un’interazione che rende una pagina non reattiva porta a un’esperienza utente scadente, ha dichiarato Google. INP osserva la latenza di tutte le interazioni che un utente ha effettuato sulla pagina e riporta un singolo valore in cui tutte (o quasi tutte) le interazioni sono state al di sotto.
Come riconoscere se la reattività è buona
Google ha fornito il seguente esempio di come appare una reattività scarsa rispetto a una buona:
Sulla sinistra, le attività prolungate bloccano l’apertura dell’accordion. Questo fa sì che l’utente clicchi più volte, pensando che l’esperienza sia interrotta.
Quando il thread principale si aggiorna, elabora gli input ritardati, con il risultato che l’accordion si apre e si chiude in modo imprevisto!
Cosa sta cambiando
La Search Console di Google includerà INP nel rapporto delle Core Web Vitals entro la fine di quest’anno.
Quando INP sostituirà FID a marzo 2024, il rapporto di Google Search Console smetterà di mostrare le metriche FID e utilizzerà quelle INP.
Perché è importante
Tutti i SEO hanno dedicato molto tempo alle Core Web Vitals e al punteggio FID. Ora gli stessi SEO dovranno spostare la loro attenzione dal FID all’INP.
Ecco una guida dettagliata su come ottimizzare INP.
Ottimizzare i Core Web Vitals non è semplice
Come avrai capito dai nostri suggerimenti, ottimizzare i Core Web Vitals non è semplice e gli interventi richiedono spesso capacità tecniche non indifferenti, che spesso dipendono tra l’altro dal tipo di struttura utilizzata dal sito web, come ad esempio il CMS e le sue dinamiche.
Proprio per questa ragione abbiamo creato una soluzione come Phantom Layer, per permettere ai nostri clienti di intervenire su tutti questi aspetti in maniera automatica, ottimizzando i Core Web Vitals in appena 48h, senza dover impiegare lunghe sessioni di sviluppo o ricorrere a impegnative consulenze tecniche.