Un INP alt no vol dir simplement “hi ha massa JavaScript”: representa una interacció concreta que respon tard per a usuaris reals. El camí útil és identificar quin clic, toc o tecla és lenta i separar retard d’entrada, temps de processament i retard fins a pintar el resultat.
Comença per la interacció, no pel número
Usa dades de camp o una traça reproduïble per identificar la interacció i l’estat de pàgina afectats. Un menú, un cercador i un botó de checkout poden fallar per causes diferents.
Separa input delay de la feina del handler
Les long tasks que ja s’executaven creen retard abans de l’esdeveniment; un handler car crea temps de processament. Ajuntar-ho tot com “main thread” amaga el responsable.
Inspecciona la long task que coincideix amb l’esdeveniment
A la traça, localitza quin script o funció ocupa el fil principal al voltant de la interacció. Tags de tercers, hydration, sliders o listeners personalitzats són candidats, no conclusions.
Redueix feina a la ruta crítica
Divideix tasques síncrones llargues, ajorna allò no essencial, redueix canvis de DOM i evita posar analítica o render no relacionat dins del mateix handler. La resposta visible a l’usuari va primer.
Revisa també presentation delay
Un handler ràpid pot donar INP dolent si després hi ha layout/render costós. Busca forced layout, DOM gran o estils que obliguin a recalcular massa.
Repeteix exactament la mateixa interacció
Valida en dispositius i estats realistes i després observa INP de camp. Una traça de laboratori millor ajuda, però l’objectiu és la resposta real al visitant.
Usa la guia sobre velocitat per a visitants reals per no provar només com a administrador i compara amb la variació entre proves PageSpeed.