INP sostituisce FID tra i Core Web Vitals: cosa misura e cosa monitorare - init.d
EN

# INP sostituisce FID tra i Core Web Vitals: cosa misura e cosa monitorare

Alessandro Corbelli~7 min read min
Table of Contents

Dal 12 marzo 2024 cambia una delle metriche con cui Google valuta la qualità di una pagina web. Una metrica chiamata FID viene ritirata e sostituita da un’altra, INP. Il cambiamento riguarda i Core Web Vitals, cioè l’insieme di indicatori che misurano l’esperienza di caricamento e uso di un sito. Non è una piccola modifica tecnica di nicchia: tocca sia la sensazione che prova chi usa il sito, sia il modo in cui Google tiene conto delle prestazioni nel posizionamento. Vale quindi la pena capire cosa cambia davvero, in parole semplici.

Cosa sono i Core Web Vitals

I Core Web Vitals sono un piccolo gruppo di metriche con cui Google prova a misurare, con numeri concreti, quanto è piacevole usare una pagina. Non giudicano il contenuto né la grafica: guardano il comportamento tecnico. Storicamente sono tre, ognuna con una domanda semplice dietro.

  • LCP (Largest Contentful Paint): quanto tempo passa prima che compaia il contenuto principale, che dipende anche da quanto è rapida la prima risposta del server? Considerata buona sotto i 2,5 secondi.
  • CLS (Cumulative Layout Shift): quanto gli elementi “saltano” mentre la pagina si carica? Considerata buona sotto 0,1.
  • La terza riguarda la reattività, cioè quanto la pagina risponde in fretta quando si tocca o si clicca qualcosa. È proprio questa a cambiare.

Fino a marzo 2024 la reattività veniva misurata con FID (First Input Delay). Da quella data viene misurata con INP (Interaction to Next Paint).

Cos’è INP e cosa misura

INP sta per Interaction to Next Paint, che si può tradurre come “dall’interazione al prossimo disegno sullo schermo”. Misura una cosa che chiunque ha provato senza saperle dare un nome: quel piccolo ritardo tra il momento in cui si clicca un pulsante, si apre un menù o si spunta una casella, e il momento in cui lo schermo mostra che qualcosa è successo.

Quando quel ritardo è breve, il sito sembra pronto e vivo. Quando è lungo, resta la sensazione di aver premuto a vuoto: si è tentati di cliccare di nuovo, e la pagina dà l’impressione di essere bloccata o rotta, anche quando non lo è.

Secondo la documentazione di web.dev, il tempo di un’interazione si scompone in tre parti:

  • il ritardo di input, cioè il tempo prima che il browser inizi a eseguire il codice legato all’interazione (spesso perché è occupato con altro);
  • il tempo di elaborazione, cioè quanto ci mette il codice a fare il proprio lavoro in risposta al clic;
  • il ritardo di presentazione, cioè il tempo che serve poi per disegnare il risultato aggiornato sullo schermo.

INP tiene conto di tutte e tre le parti. Contano come interazioni i clic con il mouse, i tocchi su schermo e la pressione dei tasti; non contano invece lo scorrimento della pagina né il semplice passaggio del puntatore sopra un elemento.

Cosa cambia rispetto a FID

Il vecchio FID misurava solo il ritardo di input della prima interazione della visita. Aveva due limiti importanti. Il primo: guardava soltanto il primo tocco, quindi se il primo clic era rapido ma tutti i successivi erano lenti, il punteggio restava buono pur non riflettendo l’esperienza reale. Il secondo: misurava solo l’attesa iniziale, ignorando quanto tempo il codice impiegava poi a rispondere e a mostrare il risultato.

INP corregge entrambi i punti. Osserva tutte le interazioni durante l’intera visita, non solo la prima, e considera l’intero percorso, dal clic fino a quando lo schermo si aggiorna. Il valore riportato è vicino all’interazione più lenta osservata (escludendo i casi rari e isolati), così da rappresentare l’esperienza peggiore che l’utente ha davvero incontrato, non quella migliore. In pratica è una misura più onesta e più difficile da “far sembrare buona” per caso.

La soglia: buona sotto i 200 ms

Il riferimento pratico è semplice. La documentazione di web.dev indica tre fasce:

  • buona: INP pari o inferiore a 200 millisecondi;
  • da migliorare: tra 200 e 500 millisecondi;
  • scarsa: oltre 500 millisecondi.

Un millisecondo è un millesimo di secondo, quindi 200 ms sono un quinto di secondo: la soglia che separa una pagina che sembra reattiva da una che inizia a dare la sensazione di lentezza.

Un dettaglio importante su come si legge il valore: non si guarda l’utente più fortunato, ma il 75° percentile delle visite reali, misurato separatamente per dispositivi mobili e desktop. In parole povere, per essere considerato buono un sito deve rispondere sotto i 200 ms per almeno il 75% delle visite. È un modo per non nascondere i problemi dietro la media: conta che l’esperienza sia buona per la grande maggioranza, non solo in condizioni ideali.

Perché conta per la SEO e il calendario del cambiamento

I Core Web Vitals non servono solo a fare ordine: sono uno dei fattori che Google considera per l’esperienza di pagina, e quindi possono influire sul posizionamento nei risultati di ricerca. Non sono l’unico né il più importante criterio, ma a parità di contenuto un sito reattivo parte avvantaggiato rispetto a uno che risponde in ritardo. Il legame con la SEO è quindi indiretto ma reale, e passa soprattutto dall’esperienza offerta a chi visita davvero il sito.

Sul fronte pratico, il passaggio è già avvenuto: dal 12 marzo 2024 INP è a tutti gli effetti un Core Web Vital e FID non lo è più. Google ha annunciato il cambiamento con largo anticipo, a maggio 2023, e la metrica era disponibile in forma sperimentale già da prima. Il ritiro di FID è graduale sul piano degli strumenti: è stato rimosso subito dal report principale di Search Console, mentre altri strumenti hanno previsto un periodo di transizione per dare tempo a chi sviluppa di adeguarsi. Chi teneva d’occhio FID, insomma, deve semplicemente spostare l’attenzione su INP.

Come si tiene sotto controllo e si migliora

La prima cosa utile è misurare con dati reali. INP si valuta al meglio sul campo, cioè sulle visite effettive, non solo in laboratorio: strumenti come Search Console (nel report Core Web Vitals), PageSpeed Insights e i dati CrUX di Chrome mostrano il valore raccolto dagli utenti veri, sui loro dispositivi e sulle loro connessioni.

Sul piano delle cause, un INP alto in genere significa che il dispositivo dell’utente è troppo occupato a eseguire codice per rispondere in fretta alle interazioni. Le leve generali seguono di conseguenza, e agiscono soprattutto sul lato del browser.

  • Alleggerire il lavoro del browser. Meno codice viene eseguito in risposta a un clic, prima lo schermo può aggiornarsi. Ridurre il lavoro superfluo che si attiva a ogni interazione, per esempio affidando ad ancoraggi CSS nativi posizionamenti oggi gestiti con script su misura, è spesso l’intervento più efficace.
  • Spezzare le operazioni lunghe. Un compito pesante e ininterrotto tiene occupato il browser e blocca le risposte. Suddividerlo in parti più piccole lascia spazio per gestire le interazioni tra un pezzo e l’altro.
  • Contenere script e componenti di terze parti. Widget, tracker e strumenti esterni aggiungono lavoro che non sempre è visibile ma che pesa sulla reattività. Vale la pena verificarne il costo reale: su un e-commerce pieno di moduli è spesso il primo posto dove guardare.
  • Dare priorità a ciò che l’utente vede e tocca. Rimandare le attività non urgenti, così che le interazioni immediate abbiano la precedenza, aiuta a tenere basso il ritardo percepito.

Come sempre in questi casi, conviene misurare prima e dopo ogni modifica: la reattività dipende da tanti fattori e la strada giusta è capire dove il browser perde tempo, invece di cambiare tutto a caso.

In sintesi

Dal 12 marzo 2024 la reattività di una pagina si misura con INP al posto di FID. INP guarda tutte le interazioni della visita e considera l’intero percorso dal clic al risultato visibile, offrendo una fotografia più realistica di come il sito risponde. La soglia da tenere a mente è 200 millisecondi per almeno il 75% delle visite. Conta per due motivi che si tengono: un sito più reattivo è più piacevole da usare e, di riflesso, parte con qualche vantaggio anche lato SEO. Il punto di partenza resta lo stesso: misurare con dati reali, capire dove nasce il ritardo e intervenire sul livello giusto.

Fonti

Tux versione Gandalf, mascotte del blog init.d

init.d è il team di Alessandro Corbelli, sistemista Linux e sviluppatore backend con oltre vent’anni di esperienza. Progetta e gestisce infrastrutture cloud (Google Cloud, AWS, Azure), server farm e architetture ad alta disponibilità, e sviluppa software su misura in Laravel/PHP e Vue - dalla piattaforma di food delivery Take2Me ai gestionali dei nostri clienti. Su questo blog condividiamo note tecniche su Linux, sistemistica, sviluppo, DevOps ed e-commerce.


Altri articoli