Dimensione Core/Dash: Tipo di input (INP)

Dimensione: Tipo di input INP (inpit)

La dimensione Tipo di input (INP) registra il tipo di evento DOM che ha scatenato la peggiore singola interazione durante la visita dell'utente alla pagina. Il valore è il nome dell'evento originale proveniente dall'Event Timing API del browser: click, keydown, pointerdown, pointerup, keypress e pochi altri.

L'INP è una metrica del caso peggiore. Non calcola la media delle interazioni. Trova la singola interazione che ha richiesto più tempo dall'input al paint successivo e ne riporta la durata. La dimensione del tipo di input ti dice cosa stava facendo l'utente in quel preciso istante. È la differenza tra sapere che "l'INP è di 450 ms" e sapere che "l'INP è di 450 ms perché l'utente stava digitando nel tuo campo di ricerca".

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

Perché il tipo di input è importante per l'INP

Ogni tipo di input corrisponde a una parte diversa del tuo codebase JavaScript. Se vedi keydown come tipo di input dominante su una pagina con un INP scarso, sai immediatamente che il problema risiede nei tuoi handler per la pressione dei tasti: autocomplete, search-as-you-type, validazione dei form eseguita a ogni pressione di un tasto. Se vedi click, il problema è nei tuoi handler di pulsanti e link: logica di navigazione, aggiornamenti di stato, aperture di modali, chiamate di analytics avviate in modo sincrono.

Senza questa dimensione, un'analisi dell'INP inizia con sessioni di profilazione, passaggi per riprodurre il problema e tentativi di indovinare quale interazione stesse provando a compiere l'utente al 75° percentile. Con la dimensione del tipo di input, passi direttamente all'handler pertinente. Il risparmio di tempo è reale.

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

I tipi di input

click e pointerdown

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

Gli handler di click sono la sede principale del lavoro JavaScript sincrono pesante. Un singolo click su un elemento di navigazione può scatenare aggiornamenti della gestione dello stato, mutazioni del DOM, eventi di analytics e un re-render, tutto all'interno dello stesso task. Ogni millisecondo di lavoro sincrono in un handler di click è un millisecondo in più aggiunto all'INP.

La soluzione per gli handler di click lenti è la scomposizione dei task. Usa <code>scheduler.yield()</code> per suddividere l'handler in task più piccoli e consentire al browser di eseguire il rendering tra di essi. Sposta il lavoro non critico, come le chiamate di analytics, in un setTimeout con ritardo zero, o rinvialo interamente a requestIdleCallback. Il browser deve completare solo il lavoro che influisce sulla risposta visiva prima del paint successivo. Tutto il resto può attendere.

keydown

L'input da tastiera rappresenta circa il 15% degli eventi con l'INP peggiore nei dati di CoreDash, ma produce alcuni dei punteggi più critici. Il motivo è la frequenza: un utente che digita in un campo di ricerca attiva keydown a ogni singola pressione di un tasto. Se il tuo handler impiega 200 ms, l'utente avverte 200 ms di ritardo dopo ogni carattere digitato. Una query di ricerca di 10 caratteri si traduce in 2 secondi di tempo di blocco accumulato.

I colpevoli più comuni sono le implementazioni search-as-you-type che avviano richieste API sincrone o eseguono un costoso diffing del DOM a ogni pressione di un tasto, e la validazione dei form che ricontrolla l'intero form a ogni tasto premuto. Questi pattern funzionano bene su piccola scala, ma crollano in condizioni d'uso reali.

Le soluzioni standard sono il debouncing e l'offloading. Applica il debouncing al tuo handler di ricerca in modo che si attivi solo quando l'utente interrompe la digitazione, solitamente dopo 200 o 300 millisecondi. Per elaborazioni più complesse, come una fuzzy search su un set di dati locale di grandi dimensioni, sposta il calcolo su un Web Worker, così che il main thread rimanga libero di eseguire il rendering del frame successivo dopo ogni evento keydown.

pointerup

Gli eventi pointer up rappresentano circa l'8% dei casi con l'INP peggiore nei dati di CoreDash. pointerup si attiva al termine di una sequenza di tocco o click, dopo pointerdown. Alcuni framework e librerie UI associano il comportamento di "click" principale a pointerup anziché a click, spostando l'handler a una fase precedente del ciclo di vita dell'interazione.

Quando pointerup si presenta come il tipo di input dominante, l'analisi è la stessa degli handler di click: individua quale JavaScript viene eseguito nell'handler e separa il lavoro che deve bloccare il paint successivo da quello che può essere rinviato. La differenza rispetto a click è solitamente una decisione a livello di framework, non di applicazione, quindi la correzione potrebbe comportare la modifica del modo in cui la libreria di componenti gestisce il binding delle interazioni.

Workflow di debug

1. Filtra per tipo di input in CoreDash: Apri il breakdown dell'INP per un URL problematico e controlla quale tipo di input domina le interazioni peggiori. Se un tipo rappresenta più della metà degli eventi con INP scarso, comincia da lì. La distribuzione ti indica dove concentrare il tempo di profilazione.
2. Riproduci il problema con l'interazione corretta: Apri i Chrome DevTools, abilita la profilazione delle Performance ed esegui l'esatto tipo di interazione mostrato in CoreDash. Una pagina dominata da keydown deve essere testata digitando. Una pagina dominata da click deve essere testata con click del mouse sugli elementi con cui interagiscono gli utenti. Registra la traccia e individua i long task nel main thread che si attivano immediatamente dopo l'evento di input.
3. Applica la correzione specifica per il tipo e verifica: Per i problemi di keydown, aggiungi il debouncing e riesegui la profilazione. Per i problemi di click, aggiungi chiamate a scheduler.yield() nei punti logici di interruzione dell'handler. Distribuisci in un ambiente di test, usa WebPageTest con script di interazione o il pannello Performance di Chrome DevTools, e conferma che la durata del task diminuisca prima del rilascio.

Regole pratiche di sviluppo

• Se keydown domina il tuo INP scarso: Aggiungi il debouncing a tutti gli handler di ricerca e autocomplete. Un ritardo di 200 ms è il punto di partenza standard. Se il calcolo è costoso anche con questo ritardo, spostalo fuori dal main thread con un Web Worker.
• Se click o pointerdown dominano: I tuoi handler eseguono troppo lavoro sincrono prima che il browser possa eseguire il paint. Analizza ogni handler di click sull'URL problematico. Rimuovi le chiamate di analytics sincrone. Spezza la logica multi-step con scheduler.yield() tra i passaggi.
• Se pointerup domina: Verifica se il tuo framework associa la logica di interazione a pointerup invece che a click. La correzione è solitamente la stessa degli handler di click, ma l'entry point nel codebase è diverso.
• Distribuzione mista senza un chiaro vincitore: Il problema non è legato a un singolo tipo di interazione. Profila le tre interazioni più lente tra tutti i tipi e risolvile in ordine di impatto. Non ottimizzare in astratto.

Il tipo di input è un segnale di routing. Non ti dice cosa sia lento; ti dice dove guardare. Una volta che sai se i tuoi utenti stanno cliccando, digitando o toccando lo schermo quando l'INP peggiora, ogni fase successiva dell'analisi diventa più veloce e mirata.