INP nos Core Web Vitals: o guia de responsividade

INP, sigla para Interaction to Next Paint, é a métrica que mede o tempo entre o momento em que um usuário interage com uma página — um clique, um toque, uma tecla — e o momento em que a interface responde visualmente a essa ação. Não é sobre quão rápido a página carrega, e sim sobre quão rápido ela reage depois de carregada: se um usuário clica em um botão de filtro e a tela trava por meio segundo antes de qualquer coisa mudar, isso é exatamente o que o INP captura.

Desde março de 2024, o INP é um dos três Core Web Vitals oficiais do Google, ao lado do LCP (velocidade de carregamento) e do CLS (estabilidade visual). Ele substituiu o First Input Delay (FID), que ocupava essa vaga desde 2020. Entender por que essa troca aconteceu ajuda a entender o que o INP realmente está tentando capturar — e por que corrigi-lo costuma exigir um olhar diferente do que corrigir LCP ou CLS.

Como o INP é Calculado

O INP não mede uma interação isolada. Ao longo de toda a visita de um usuário — do primeiro clique até ele sair da página — o navegador registra a latência de cada interação relevante: cliques, toques e pressionamentos de tecla que geram alguma resposta visual. No final da visita, o valor reportado como INP corresponde essencialmente à pior interação sentida por aquele usuário, com um ajuste técnico: em vez de considerar o pior valor bruto, o cálculo usa um percentil alto dentro do próprio conjunto de interações daquela sessão, descartando o outlier mais extremo. Isso evita que uma única interação anômala — um clique que coincidiu com o carregamento de um script pesado, por exemplo — infle artificialmente o resultado, mas também garante que dezenas de cliques rápidos e responsivos não escondam aquela vez em que o site travou por 600 milissegundos.

Isso é diferente de uma média. Uma página pode responder instantaneamente em 95% das interações e ainda assim ter um INP ruim, porque basta que uma parcela relevante das interações trave para que o usuário sinta que o site é lento — e é exatamente esse sentimento que a métrica tenta capturar. Quando o Google agrega esse dado em nível de origem no Chrome UX Report (a base que alimenta o PageSpeed Insights e o relatório de Core Web Vitals no Search Console), ele usa o percentil 75 entre todos os usuários reais daquela URL ou domínio nos últimos 28 dias. Ou seja: 75% das visitas precisam ter um INP dentro da faixa considerada boa para a página passar na avaliação.

Por Que o INP Substituiu o FID

O FID (First Input Delay) tinha duas limitações estruturais que o tornavam um indicador enganoso de responsividade. A primeira: ele media apenas a primeira interação do usuário na página, ignorando tudo que acontecia depois. Um site podia responder bem ao primeiro clique — geralmente o mais fácil de otimizar, porque acontece antes que a página tenha acumulado muito JavaScript em execução — e ser péssimo em todas as interações seguintes, sem que o FID captasse isso.

A segunda limitação era mais sutil: o FID media apenas o atraso de entrada, ou seja, o tempo entre o clique do usuário e o momento em que o navegador começa a processar esse clique. Ele não incluía o tempo que o navegador levava para de fato processar a ação nem o tempo até a tela atualizar visualmente. Uma interação podia ter um atraso de entrada baixíssimo e mesmo assim demorar meio segundo até o usuário ver qualquer mudança na tela — e o FID reportaria isso como rápido.

Na prática, essas duas lacunas faziam o FID parecer bom na esmagadora maioria dos sites, mesmo em páginas que os próprios usuários descreveriam como travadas. O INP fecha as duas lacunas: mede todas as interações relevantes da visita, não só a primeira, e mede o ciclo completo, da ação do usuário até a resposta visual na tela, não apenas o atraso inicial antes de o navegador começar a trabalhar.

As Três Partes de uma Interação

Cada interação medida pelo INP se decompõe em três fases sequenciais. Saber qual delas está causando o problema muda completamente a solução a aplicar.

Um diagnóstico de INP que não separa essas três fases tende a atirar no escuro: reduzir o tamanho de um bundle raramente ajuda muito se o problema real é uma atualização de DOM gigante disparada por um único clique.

• Atraso de entrada (input delay): o intervalo entre o clique do usuário e o momento em que o navegador consegue começar a processar o evento. Cresce quando a main thread já está ocupada com outra tarefa — um script de terceiro carregando, uma renderização em andamento — porque o JavaScript roda em uma única thread e a interação precisa esperar a vez.
• Tempo de processamento (processing time): o tempo que o próprio código do event handler leva para rodar — a função que trata o clique, atualiza estado, dispara chamadas, manipula o DOM. É aqui que entram os handlers pesados, os cálculos desnecessários e as bibliotecas que fazem mais trabalho do que a interação exige.
• Atraso de apresentação (presentation delay): o tempo entre o fim do processamento e o momento em que o navegador efetivamente pinta a próxima tela — o "next paint" do nome da métrica. Inclui recálculo de layout, repintura de elementos grandes e, em frameworks modernos, o tempo de reconciliação e re-render de componentes.

Os Principais Vilões: JavaScript Demais

Na prática, quase todo problema sério de INP tem a mesma raiz: JavaScript demais competindo pela mesma thread do navegador. Os padrões mais comuns são:

• Tarefas longas bloqueando a main thread: qualquer trecho de JavaScript que rode por muito tempo sem devolver o controle ao navegador impede que interações sejam processadas nesse intervalo. Scripts de inicialização pesados, parsing de dados grandes e cálculos síncronos costumam ser os culpados.
• Scripts de terceiros e gerenciadores de tags: pixels de anúncios, chat widgets, ferramentas de analytics e, principalmente, gerenciadores de tags que disparam dezenas de outros scripts em cascata. Cada um compete pela main thread de forma independente, e o site que os hospeda raramente controla o quão bem otimizado cada um deles é.
• Event handlers pesados: funções de clique ou de digitação que fazem trabalho desnecessário de forma síncrona — validação complexa, formatação, chamadas de API bloqueantes ou lógica que poderia perfeitamente ser adiada para depois da resposta visual.
• Atualizações grandes de DOM: re-renderizar uma lista inteira quando só um item mudou, recalcular estilos em centenas de elementos, ou trocar um componente inteiro de árvore quando bastava atualizar um único nó. Frameworks baseados em virtual DOM tornam esse erro fácil de cometer sem perceber.

Como Diagnosticar: Dados de Campo Primeiro, Laboratório Depois

O ponto de partida correto para investigar INP são dados de campo — medições reais, coletadas de usuários de verdade, em dispositivos e condições de rede reais. O relatório de Core Web Vitals do Search Console, a seção de dados do Chrome UX Report dentro do PageSpeed Insights, e uma implementação da biblioteca web-vitals enviando dados para uma ferramenta de RUM (monitoramento de usuário real) são os pontos de partida naturais. Só dados de campo mostram o comportamento real da distribuição de dispositivos e conexões da audiência, algo que nenhum teste isolado reproduz fielmente.

Ferramentas de laboratório — o Lighthouse, o painel Performance do Chrome DevTools, testes automatizados em pipelines de CI — entram depois, para investigar a causa depois que o campo já mostrou que existe um problema. Isso importa porque o laboratório pode simplesmente não enxergar o problema: o Lighthouse roda em condições controladas e mede um conjunto limitado de interações simuladas, o que não replica um usuário real clicando repetidamente em um filtro de e-commerce enquanto um gerenciador de tags ainda está terminando de carregar em segundo plano. Uma página pode passar limpa numa auditoria de Lighthouse e ainda assim ter um INP ruim no campo, simplesmente porque o teste de laboratório nunca gerou a interação exata que expõe o gargalo.

Depois de confirmar o problema com dados de campo, o painel Performance do DevTools permite gravar uma interação real, identificar tarefas longas na main thread e ver exatamente qual função está consumindo tempo em cada uma das três fases da interação — entrada, processamento e apresentação.

Como Corrigir: Reduzindo o Custo de Cada Interação

Não existe uma correção única para INP. Existem várias táticas, e cada uma ataca uma fase diferente do problema:

• Quebrar tarefas longas: dividir funções que fazem muito trabalho síncrono em pedaços menores, devolvendo o controle à main thread entre eles. Isso não reduz o trabalho total, mas permite que interações do usuário sejam processadas entre os pedaços em vez de esperar tudo terminar de uma vez.
• Adiar trabalho não crítico: JavaScript que não é necessário para a interação imediata do usuário — rastreamento secundário, widgets abaixo da dobra, funcionalidades que só importam depois de um primeiro engajamento — pode carregar depois, fora do caminho crítico de resposta.
• Reduzir a carga de terceiros: auditar cada script de terceiro, remover o que não se paga em valor real, carregar o restante de forma assíncrona ou sob demanda, e ser especialmente rigoroso com gerenciadores de tags, que tendem a crescer sem controle se ninguém os revisa.
• Cuidado com o custo de renderização do framework escolhido: em React, Vue e ferramentas semelhantes, evitar re-renderizar componentes que não mudaram, não atualizar estado de forma que force o re-render de árvores inteiras, e usar virtualização de listas para não renderizar centenas de itens fora da área visível.

Nenhuma dessas táticas exige reescrever o site inteiro. Na maioria dos casos, o trabalho é encontrar o handler específico, ou o script específico, que está monopolizando a thread no momento exato em que o usuário mais interage — geralmente são dois ou três pontos concentrando a maior parte do problema, não o código inteiro do site.

Metas Realistas e Como Priorizar

O Google classifica um INP de até 200 milissegundos como bom, entre 200 e 500 milissegundos como precisa melhorar, e acima de 500 milissegundos como ruim, sempre medido no percentil 75 dos usuários reais da origem. Vale notar que esse limite é mais rigoroso do que parece à primeira vista: 200 milissegundos é um intervalo curto o suficiente para que a maioria das interações do site precise ser tratada quase instantaneamente para que a origem inteira passe no percentil 75.

Em termos de priorização entre os três Core Web Vitals, faz sentido olhar primeiro para qual métrica está de fato reprovando no relatório de campo da própria origem — otimizar INP às cegas quando o problema real da página é o LCP desperdiça esforço em algo que o usuário nem percebe da mesma forma. Dito isso, INP costuma ser subestimado porque, ao contrário de LCP e CLS, seus problemas só aparecem quando alguém interage: páginas com pouca interatividade real, como um blog simples, raramente têm o INP como o vital mais crítico, enquanto aplicações com filtros, formulários, carrinhos e painéis interativos tendem a sofrer justamente aí, mesmo com LCP e CLS impecáveis. Nesses casos, o INP tende a ser o vital que mais se conecta com a percepção direta de qualidade do usuário, porque é o único dos três que mede a resposta a uma ação que a pessoa de fato tomou.