Core/Dash Dimension: Input Type (INP)

Dimensione: Input Type INP (inpit)

La dimensione Input Type (INP) registra il tipo di evento DOM che ha innescato la singola interazione peggiore durante la visita di un utente sulla pagina. Il valore è il nome non elaborato dell'evento proveniente dalla Event Timing API del browser: click, keydown, pointerdown, pointerup, keypress e pochi altri.

L'INP è una metrica basata sul caso peggiore. Non fa la media delle interazioni. Trova l'unica interazione che ha impiegato più tempo dall'input al paint successivo e riporta quella durata. La dimensione del tipo di input (input type) ti dice cosa stava facendo l'utente in quell'esatto momento. Questa è la differenza tra sapere che "L'INP è di 450ms" e sapere che "L'INP è di 450ms perché l'utente ha digitato nel tuo campo di ricerca".

L'Event Timing API raggruppa gli eventi correlati in un'unica interazione logica. Un tocco su un touchscreen attiva pointerdown, pointerup e click come un unico gruppo. Il singolo gestore di eventi più lungo all'interno di quel gruppo determina la latenza dell'interazione. CoreDash registra il tipo di evento del gestore più lungo, ovvero quello che ha reso lenta l'interazione.

Perché l'Input Type è Importante per l'INP

Ogni tipo di input mappa a una parte diversa della tua codebase JavaScript. Se vedi keydown come input type dominante su una pagina con un pessimo INP, sai immediatamente che il problema risiede nei gestori delle battute sulla tastiera: autocompletamento, ricerca durante la digitazione (search-as-you-type), validazione dei moduli eseguita a ogni pressione di tasto. Se vedi click, il problema è nei gestori di pulsanti e link: logica di navigazione, aggiornamenti di stato, aperture di modali, chiamate analitiche eseguite in modo sincrono.

Senza questa dimensione, un'analisi INP inizia con sessioni di profiling, passaggi di riproduzione e supposizioni su quale interazione stesse tentando l'utente del 75° percentile. Con la dimensione dell'input type, passi direttamente al gestore pertinente. Il risparmio di tempo è reale.

Il tipo di input rivela anche le differenze di piattaforma. Un sito con una forte navigazione da tastiera da parte di power user mostrerà un'alta percentuale di eventi keydown che causano un pessimo INP. Un prodotto utilizzato principalmente su dispositivi mobili mostrerà una dominanza di pointerdown. La stessa pagina, lo stesso punteggio INP, la stessa correzione applicata a gestori diversi a seconda di chi siano effettivamente i tuoi utenti.

I Tipi di Input

click e pointerdown

Questi sono i tipi di input più comuni nei dati di CoreDash, rappresentando circa il 75% degli eventi peggiori per l'INP. Su desktop, click rappresenta il rilascio del pulsante del mouse. Su mobile, un tocco attiva l'intera catena: pointerdown si attiva per primo quando il dito tocca lo schermo, poi pointerup quando si solleva, quindi click alla fine. CoreDash registra l'evento di questa catena che ha avuto il gestore più lungo.

I gestori di clic sono la posizione principale in cui avviene il pesante lavoro sincrono di JavaScript. Un singolo clic su un elemento di navigazione può innescare aggiornamenti di gestione dello stato, mutazioni del DOM, eventi analitici e un re-render, tutto nella stessa attività (task). Ogni millisecondo di lavoro sincrono in un gestore di clic è un millisecondo aggiunto all'INP.

La soluzione per i gestori di clic lenti è la scomposizione delle attività (task decomposition). Usa <code>scheduler.yield()</code> per suddividere il gestore in attività più piccole e consentire al browser di eseguire il render tra di esse. Sposta il lavoro non critico, come le chiamate analitiche, in un setTimeout con ritardo zero, o differiscile interamente a requestIdleCallback. Il browser ha solo bisogno di completare il lavoro che influisce sulla risposta visiva prima del paint successivo. Tutto il resto può aspettare.

keydown

L'input da tastiera rappresenta circa il 15% degli eventi INP peggiori nei dati di CoreDash, ma produce alcuni dei punteggi più eclatanti. La ragione è la frequenza: un utente che digita in un campo di ricerca innesca keydown a ogni singola battuta. Se il tuo gestore impiega 200ms, l'utente subisce 200ms di lag dopo ogni carattere digitato. Una query di ricerca di 10 caratteri diventa 2 secondi di blocking time accumulato.

I colpevoli comuni sono le implementazioni di ricerca durante la digitazione (search-as-you-type) che lanciano richieste API sincrone o eseguono costose operazioni di DOM diffing a ogni battuta, e la validazione dei moduli che ricontrolla l'intero modulo a ogni pressione di tasto. Questi pattern funzionano bene su piccola scala, ma collassano in condizioni utente reali.

Le soluzioni standard sono il debouncing e l'offloading. Applica il debounce al tuo gestore di ricerca in modo che si attivi solo dopo che l'utente ha messo in pausa la digitazione, tipicamente da 200 a 300 millisecondi. Per elaborazioni più complesse come la ricerca fuzzy su un ampio set di dati locale, sposta il calcolo su un Web Worker in modo che il main thread rimanga libero di eseguire il render del frame successivo dopo ogni evento keydown.

pointerup

Gli eventi pointer up rappresentano circa l'8% dei casi peggiori per l'INP nei dati di CoreDash. pointerup si attiva alla fine di una sequenza di tocco o clic, dopo pointerdown. Alcuni framework e librerie UI associano il loro comportamento principale di "click" a pointerup anziché a click, il che sposta il gestore prima nel ciclo di vita dell'interazione.

Quando pointerup si presenta come input type dominante, l'analisi è la stessa dei gestori di clic: trova quale JavaScript viene eseguito nel gestore e separa il lavoro che deve bloccare il paint successivo dal lavoro che può essere differito. La distinzione da click è di solito una decisione a livello di framework, non a livello di applicazione, quindi la correzione potrebbe comportare l'adeguamento di come la libreria di componenti gestisce l'associazione dell'interazione (interaction binding).

Workflow di Debugging

1. Filtra per tipo di input in CoreDash: Apri la scomposizione dell'INP per un URL problematico e controlla quale tipo di input domina le interazioni peggiori. Se un tipo rappresenta più della metà dei tuoi eventi INP negativi, inizia da lì. La distribuzione ti dice dove spendere il tuo tempo di profiling.
2. Riproduci con la giusta interazione: Apri Chrome DevTools, abilita il Performance profiling ed esegui l'esatto tipo di interazione mostrato in CoreDash. Una pagina dominata da keydown dovrebbe essere testata digitando. Una pagina dominata da click dovrebbe essere testata con i clic del mouse sugli elementi con cui interagiscono i tuoi utenti. Registra la traccia e identifica le attività lunghe (long tasks) nel main thread che si attivano immediatamente dopo l'evento di input.
3. Applica la correzione specifica per il tipo e verifica: Per problemi di keydown, aggiungi il debouncing e riesegui il profilo. Per problemi di click, aggiungi le chiamate scheduler.yield() ai breakpoint logici nel gestore. Esegui il deploy in un ambiente di test, usa WebPageTest con gli script di interazione o il pannello Performance di Chrome DevTools, e conferma che la durata della task diminuisca prima del rilascio.

Regola Pratica di Ingegneria

• keydown domina il tuo pessimo INP: Aggiungi il debouncing a tutti i gestori di ricerca e autocompletamento. Un ritardo di 200ms è il punto di partenza standard. Se il calcolo è costoso anche a quel ritardo, spostalo fuori dal main thread con un Web Worker.
• click o pointerdown dominano: I tuoi gestori stanno facendo troppo lavoro sincrono prima che il browser possa eseguire il paint. Controlla ogni gestore di clic sull'URL problematico. Rimuovi le chiamate analitiche sincrone. Suddividi la logica multi-fase con scheduler.yield() tra una fase e l'altra.
• pointerup domina: Controlla se il tuo framework sta associando la logica di interazione a pointerup anziché a click. La correzione è di solito la stessa usata per i gestori di clic, ma il punto di ingresso nella codebase è diverso.
• Distribuzione mista senza un chiaro vincitore: Il problema non è un solo tipo di interazione. Esegui il profiling delle tre interazioni singole più lente tra tutti i tipi e affrontale in ordine di impatto. Non ottimizzare in modo astratto.

L'Input Type è un segnale di instradamento (routing signal). Non ti dice cosa è lento. Ti dice dove guardare. Una volta che sai se i tuoi utenti stanno cliccando, digitando o toccando quando l'INP si rompe, ogni fase successiva dell'indagine diventa più veloce e più mirata.