Dimensão Core/Dash: Tipo de Entrada (INP)

Dimensão: Tipo de Entrada INP (inpit)

A dimensão Tipo de Entrada (INP) registra o tipo de evento DOM que acionou a única pior interação durante a visita de um usuário à página. O valor é o nome bruto do evento da Event Timing API do navegador: click, keydown, pointerdown, pointerup, keypress e alguns outros.

O INP é uma métrica de pior cenário. Ele não faz média de interações. Ele encontra a única interação que levou mais tempo desde a entrada até a próxima pintura e relata essa duração. A dimensão de tipo de entrada informa o que o usuário estava fazendo naquele exato momento. Essa é a diferença entre saber "O INP é 450ms" e saber "O INP é 450ms porque o usuário digitou no seu campo de pesquisa".

A Event Timing API agrupa eventos relacionados em uma única interação lógica. Um toque em uma tela sensível ao toque dispara pointerdown, pointerup e click como um único grupo. O manipulador de eventos mais longo dentro desse grupo determina a latência da interação. O CoreDash registra o tipo de evento do manipulador mais longo, que é o que tornou a interação lenta.

Por Que o Tipo de Entrada Importa para o INP

Cada tipo de entrada mapeia para uma parte diferente da sua base de código JavaScript. Se você vê keydown como o tipo de entrada dominante em uma página com INP ruim, você sabe imediatamente que o problema está nos seus manipuladores de pressionamento de tecla: preenchimento automático, pesquisa ao digitar, validação de formulário sendo executada a cada tecla pressionada. Se você vê click, o problema está nos seus manipuladores de botão e link: lógica de navegação, atualizações de estado, aberturas de modal, chamadas de analytics sendo disparadas de forma síncrona.

Sem essa dimensão, uma investigação de INP começa com sessões de profiling, etapas de reprodução e adivinhação de qual interação o usuário do 75º percentil estava tentando realizar. Com a dimensão de tipo de entrada, você pula direto para o manipulador relevante. A economia de tempo é real.

O tipo de entrada também revela diferenças de plataforma. Um site com navegação intensa por teclado de power users mostrará uma alta proporção de eventos keydown impulsionando um INP ruim. Um produto usado principalmente em dispositivos móveis mostrará pointerdown dominando. A mesma página, a mesma pontuação de INP, a mesma correção aplicada a manipuladores diferentes dependendo de quem são os seus usuários na realidade.

Os Tipos de Entrada

click e pointerdown

Esses são os tipos de entrada mais comuns nos dados do CoreDash, representando aproximadamente 75% dos piores eventos de INP. No desktop, click representa a liberação de um botão do mouse. No mobile, um toque dispara a cadeia completa: pointerdown dispara primeiro quando o dedo toca a tela, depois pointerup quando ele é levantado, e então click no final. O CoreDash registra qual evento dessa cadeia teve o manipulador mais longo.

Manipuladores de clique são o local principal de trabalho síncrono pesado em JavaScript. Um único clique em um item de navegação pode acionar atualizações de gerenciamento de estado, mutações de DOM, eventos de analytics e uma nova renderização tudo na mesma tarefa. Cada milissegundo de trabalho síncrono em um manipulador de clique é um milissegundo adicionado ao INP.

A correção para manipuladores de clique lentos é a decomposição de tarefas. Use <code>scheduler.yield()</code> para dividir o manipulador em tarefas menores e permitir que o navegador renderize entre elas. Mova o trabalho não crítico como chamadas de analytics para um setTimeout com zero atraso, ou adie-os inteiramente para requestIdleCallback. O navegador só precisa concluir o trabalho que afeta a resposta visual antes da próxima pintura. Todo o resto pode esperar.

keydown

A entrada por teclado representa aproximadamente 15% dos piores eventos de INP nos dados do CoreDash, mas produz algumas das pontuações mais flagrantes. O motivo é a frequência: um usuário digitando em um campo de pesquisa dispara keydown a cada pressionamento de tecla. Se o seu manipulador leva 200ms, o usuário experimenta 200ms de lag após cada caractere digitado. Uma consulta de pesquisa de 10 caracteres se torna 2 segundos de tempo de bloqueio acumulado.

Os culpados comuns são implementações de pesquisa ao digitar que disparam requisições de API síncronas ou executam um diffing de DOM custoso a cada pressionamento de tecla, e validação de formulário que verifica novamente o formulário inteiro a cada tecla pressionada. Esses padrões funcionam bem em pequena escala e colapsam sob condições de usuários reais.

As correções padrão são debouncing e offloading. Aplique debounce no seu manipulador de pesquisa para que ele dispare apenas depois que o usuário pausar a digitação, tipicamente de 200 a 300 milissegundos. Para processamentos mais complexos como fuzzy search em um grande conjunto de dados local, mova a computação para um Web Worker para que a thread principal permaneça livre para renderizar o próximo quadro após cada evento keydown.

pointerup

Eventos pointer up representam aproximadamente 8% dos piores casos de INP nos dados do CoreDash. O pointerup dispara no final de uma sequência de toque ou clique, após o pointerdown. Alguns frameworks e bibliotecas de UI vinculam seu comportamento primário de "clique" ao pointerup em vez do click, o que move o manipulador para mais cedo no ciclo de vida da interação.

Quando pointerup aparece como o tipo de entrada dominante, a investigação é a mesma que a dos manipuladores de clique: descubra qual JavaScript roda no manipulador e separe o trabalho que deve bloquear a próxima pintura do trabalho que pode ser adiado. A distinção de click geralmente é uma decisão a nível de framework, não a nível de aplicação, então a correção pode envolver ajustar como a biblioteca de componentes lida com a vinculação de interação.

Fluxo de Trabalho de Depuração

1. Filtre por tipo de entrada no CoreDash: Abra o detalhamento de INP para uma URL que está falhando e verifique qual tipo de entrada domina as piores interações. Se um tipo representa mais da metade dos seus eventos de INP ruins, comece por aí. A distribuição diz onde gastar seu tempo de profiling.
2. Reproduza com a interação correta: Abra o Chrome DevTools, ative o profiling de Performance e execute o tipo de interação exato mostrado no CoreDash. Uma página dominada por keydown deve ser testada digitando. Uma página dominada por click deve ser testada com cliques do mouse nos elementos com os quais seus usuários interagem. Grave o trace e identifique as tarefas longas na thread principal que disparam imediatamente após o evento de entrada.
3. Aplique a correção específica do tipo e verifique: Para problemas de keydown, adicione debouncing e faça um novo profile. Para problemas de click, adicione chamadas scheduler.yield() em pontos de interrupção lógicos no manipulador. Faça o deploy para um ambiente de teste, use o WebPageTest com scripting de interação ou o painel de Performance do Chrome DevTools, e confirme que a duração da tarefa cai antes de enviar para produção.

Regra Prática de Engenharia

• keydown domina o seu INP ruim: Adicione debouncing a todos os manipuladores de pesquisa e preenchimento automático. Um atraso de 200ms é o ponto de partida padrão. Se a computação for custosa mesmo com esse atraso, mova-a para fora da thread principal com um Web Worker.
• click ou pointerdown domina: Seus manipuladores estão fazendo trabalho síncrono demais antes que o navegador possa pintar. Audite cada manipulador de clique na URL falha. Remova chamadas de analytics síncronas. Divida a lógica de várias etapas com scheduler.yield() entre as etapas.
• pointerup domina: Verifique se o seu framework está vinculando a lógica de interação ao pointerup em vez do click. A correção geralmente é a mesma que para manipuladores de clique, mas o ponto de entrada na base de código é diferente.
• Distribuição mista sem um vencedor claro: O problema não é um tipo de interação. Faça o profile das três interações individuais mais lentas em todos os tipos e trate-as em ordem de impacto. Não otimize de forma abstrata.

O Tipo de Entrada é um sinal de roteamento. Ele não diz a você o que está lento. Ele diz onde olhar. Uma vez que você saiba se seus usuários estão clicando, digitando ou tocando quando o INP quebra, cada passo subsequente da investigação se torna mais rápido e mais direcionado.