Dimensão do Core/Dash: Input Type (INP)

Identifique qual ação do usuário causou seu pior INP e corrija o handler de interação correto primeiro.

Teste grátis

Trusted by market leaders · Client results

erasmusmcsaturnperiondpg mediacompareharvardmy work featured on web.devhappyhorizonkpnmonarchwhowhatwearebaynestlealeteiavpnworkivanina caremarktplaatssnvadevintafotocasaloopearplugs

Dimensão: Input Type INP (inpit)

A dimensão Input Type (INP) registra o tipo de evento DOM que disparou a pior interação individual 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 caso. Ele não faz a média das interações. Ele encontra a interação que levou mais tempo do input até a próxima pintura e reporta essa duração. A dimensão do tipo de input diz o que o usuário estava fazendo naquele exato momento. Essa é a diferença entre saber que o "INP é de 450ms" e saber que o "INP é de 450ms porque o usuário digitou no seu campo de busca".

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 handler de evento mais longo dentro desse grupo determina a latência da interação. O CoreDash registra o tipo de evento do handler mais longo, que foi o que tornou a interação lenta.

Por que o tipo de input importa para o INP

Cada tipo de input é mapeado para uma parte diferente da sua base de código JavaScript. Se você vê o keydown como o tipo de input dominante em uma página com INP ruim, sabe imediatamente que o problema está nos seus handlers de digitação: autocomplete, busca ao digitar, validação de formulário executada a cada tecla pressionada. Se você vê click, o problema está nos seus handlers de botões e links: lógica de navegação, atualizações de estado, abertura de modais e chamadas de analytics 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 suposições sobre qual interação o usuário no percentil 75 estava tentando realizar. Com a dimensão do tipo de input, você vai direto para o handler relevante. A economia de tempo é real.

O tipo de input também revela diferenças de plataforma. Um site com forte navegação por teclado por usuários avançados mostrará uma alta proporção de eventos keydown gerando um INP ruim. Um produto usado principalmente em dispositivos móveis mostrará o pointerdown dominando. A mesma página, a mesma pontuação de INP, a mesma correção aplicada a handlers diferentes, dependendo de quem realmente são seus usuários.

Os tipos de input

click e pointerdown

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

Os handlers de click são o local principal de trabalho síncrono pesado de JavaScript. Um único clique em um item de navegação pode disparar atualizações de gerenciamento de estado, mutações do DOM, eventos de analytics e uma re-renderização, tudo na mesma tarefa. Cada milissegundo de trabalho síncrono em um handler de click é um milissegundo adicionado ao INP.

A solução para handlers de click lentos é a decomposição de tarefas. Use <code>scheduler.yield()</code> para dividir o handler 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 atraso zero ou adie-as totalmente para o 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 de teclado representa cerca de 15% dos piores eventos de INP nos dados do CoreDash, mas produz algumas das pontuações mais graves. O motivo é a frequência: um usuário digitando em um campo de busca dispara o keydown a cada tecla pressionada. Se o seu handler demorar 200ms, o usuário experimentará 200ms de atraso após cada caractere digitado. Uma busca de 10 caracteres se transforma em 2 segundos de tempo de bloqueio acumulado.

Os culpados comuns são as implementações de busca ao digitar que disparam requisições síncronas de API ou executam diffing de DOM custoso a cada tecla pressionada, além de validações de formulário que revalidam todo o formulário a cada tecla pressionada. Esses padrões funcionam bem em pequena escala, mas entram em colapso sob condições reais de uso.

As correções padrão são o debouncing e o offloading. Aplique debouncing no seu handler de busca para que ele dispare apenas quando o usuário pausar a digitação, geralmente após 200 a 300 milissegundos. Para processamentos mais complexos, como busca fuzzy em um grande conjunto de dados local, mova a computação para um Web Worker, mantendo a main thread livre para renderizar o próximo frame 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 principal de "clique" ao pointerup em vez do click, o que move o handler para uma etapa anterior no ciclo de vida da interação.

Quando o pointerup aparece como o tipo de input dominante, a investigação é a mesma que para handlers de click: descubra qual JavaScript roda no handler e separe o trabalho que precisa bloquear a próxima pintura daquele que pode ser adiado. A distinção em relação ao click costuma ser uma decisão a nível de framework, e não de aplicação, de modo que a correção pode envolver ajustar a forma como a biblioteca de componentes lida com a vinculação de interações.

Fluxo de depuração

  1. Filtre por tipo de input no CoreDash: Abra o detalhamento do INP de uma URL com problemas e verifique qual tipo de input domina as piores interações. Se um único tipo for responsável por mais da metade dos seus eventos ruins de INP, comece por aí. A distribuição diz a você onde gastar seu tempo de profiling.
  2. Reproduza com a interação correta: Abra o Chrome DevTools, ative o profiling de Performance e realize o tipo exato de interação exibido no CoreDash. Uma página dominada por keydown deve ser testada por meio de digitação. 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 long tasks na main thread que são disparadas imediatamente após o evento de input.
  3. Aplique a correção específica do tipo e verifique: Para problemas de keydown, adicione debouncing e faça um novo profiling. Para problemas de click, adicione chamadas de scheduler.yield() em breakpoints lógicos no handler. Faça o deploy em um ambiente de testes, use o WebPageTest com scripting de interação ou o painel de Performance do Chrome DevTools e confirme se a duração da tarefa diminuiu antes de colocar em produção.

Regra geral de engenharia

  • keydown domina seu INP ruim: Adicione debouncing a todos os handlers de busca e autocomplete. Um delay de 200ms é o ponto de partida padrão. Se o processamento for pesado mesmo com esse delay, mova-o para fora da main thread com um Web Worker.
  • click ou pointerdown dominam: Seus handlers estão fazendo muito trabalho síncrono antes que o navegador consiga pintar. Audite cada handler de click na URL com problemas. Remova chamadas de analytics síncronas. Divida lógicas de múltiplas etapas com scheduler.yield() entre os passos.
  • pointerup domina: Verifique se o seu framework está associando a lógica de interação ao pointerup em vez do click. A solução costuma ser a mesma dos handlers de click, mas o ponto de entrada na base de código é diferente.
  • Distribuição mista sem vencedor claro: O problema não é um único tipo de interação. Faça o profiling das três interações individuais mais lentas de todos os tipos e trate-as em ordem de impacto. Não otimize no abstrato.

O Input Type é um sinal de roteamento. Ele não diz o que está lento. Ele diz para onde olhar. Uma vez que você sabe se seus usuários estão clicando, digitando ou tocando na tela quando o INP quebra, cada etapa subsequente de investigação se torna mais rápida e direcionada.