O INP substituiu o FID: por que sites que passavam agora reprovam

Em março de 2024 o Google trocou uma das métricas que usa no ranqueamento. Saiu o FID, entrou o INP. Muita gente descobriu a mudança do jeito ruim: um relatório verde que virou vermelho sem que ninguém tivesse mexido no site.

Não é erro de medição. A régua antiga era fácil de passar, e a nova cobra o que o visitante de fato sente quando clica em um filtro e a tela demora a reagir. Sites com muito JavaScript foram os primeiros a aparecer no relatório.

Este artigo explica o que mudou exatamente, por que o INP é mais difícil de passar, onde a causa costuma estar e como medir os dois lados — campo e laboratório — sem confundir um com o outro.

O que a métrica antiga media, e por que era fácil

O First Input Delay cronometrava apenas o atraso da primeira interação da visita. E apenas o atraso: o intervalo entre o clique e o momento em que o navegador conseguiu começar a executar o código correspondente.

Repare no que ficava de fora. O tempo de executar o handler não contava. O tempo de recalcular o layout e desenhar a tela nova não contava. E, como era só a primeira interação, bastava a página estar tranquila no primeiro segundo para o resto da sessão nunca ser avaliado.

Na prática, era um exame que quase todo mundo passava. Um site podia travar três segundos a cada filtro aplicado e ainda assim exibir um número excelente, porque o primeiro clique tinha caído numa janela calma.

O que o INP mede

O Interaction to Next Paint mede o ciclo inteiro: do momento em que o usuário toca até o momento em que a tela mostra o resultado visual daquela ação. Clique, toque e digitação entram na conta. Rolagem e passagem do mouse, não.

O INP é composto por três partes. O atraso de entrada, que é a espera até a thread principal ficar livre. O tempo de processamento, que é a execução dos handlers de evento. E o atraso de apresentação, que é o tempo até o navegador desenhar o quadro seguinte.

Segundo a documentação do Google, abaixo de 200 milissegundos é bom, entre 200 e 500 precisa de melhoria e acima de 500 é ruim.

Não é a média das interações

O INP observa praticamente todas as interações da visita e reporta um valor próximo do pior caso — em visitas longas, o Google descarta um punhado de valores extremos e usa o mais alto do que sobra. Vinte cliques rápidos não compensam um que travou.

Isso muda a estratégia de correção. Não adianta deixar a maioria das interações mais rápidas; é preciso encontrar e eliminar as piores. Normalmente são poucas telas e poucos componentes: um filtro de catálogo, um autocomplete, a abertura de um menu pesado.

Por que sites que passavam no FID falham no INP?

Três motivos empilhados. O primeiro é escopo: sair de uma interação para todas elas expõe justamente o que acontece depois que a página carregou e o JavaScript inteiro está ativo.

O segundo é o que passou a ser cronometrado. Um handler que roda 250 milissegundos era invisível na régua antiga e agora entra inteiro no INP.

O terceiro é o desenho. O tempo de pintar o quadro seguinte agora conta, e é aí que aparece o custo de re-renderizar uma árvore de componentes grande a cada tecla digitada.

Vale notar uma assimetria útil: um site pode ter carregamento excelente e resposta ruim. São problemas diferentes, com causas diferentes. Otimizar imagem não melhora clique — é outro conjunto de ajustes, ligado ao tempo até o conteúdo aparecer, e confundir os dois faz o time trabalhar na frente errada por semanas.

Onde a causa costuma estar

Quase todo INP ruim tem a mesma origem: JavaScript. A thread principal do navegador é única: enquanto ela executa código, não desenha nada. Toda interação lenta é, no fundo, uma fila de espera por essa thread.

Tarefas longas

Qualquer bloco de execução acima de 50 milissegundos é uma tarefa longa. Se o usuário clica no meio de uma delas, o clique espera. O padrão típico é um script de inicialização que roda tudo de uma vez logo após o carregamento — justamente quando o visitante começa a interagir.

A correção é quebrar o trabalho em pedaços e devolver o controle ao navegador entre eles, para que ele possa processar entradas pendentes. Também vale adiar o que não é necessário na primeira tela.

Handlers de evento pesados

O clique dispara uma função que valida, formata, salva no armazenamento local, dispara três eventos de analytics e depois atualiza a tela. O usuário paga por tudo isso antes de ver qualquer reação.

O princípio é simples: no handler, faça só o que muda a tela. Todo o resto — registro, sincronização, envio de dados — vai para depois da pintura. O visitante vê a resposta imediatamente e o trabalho secundário acontece em seguida.

Re-render desnecessário

Em frameworks de componente, uma mudança de estado no topo pode reconstruir uma árvore inteira. Uma lista de 500 linhas que se recalcula a cada letra digitada em um campo de busca é a receita clássica de um INP ruim.

Soluções conhecidas: virtualizar listas longas, isolar o estado no componente que realmente o usa, e agrupar atualizações em vez de disparar uma por evento.

Scripts de terceiros

Chat de atendimento, mapa de calor, teste A/B, gerenciador de tags. Cada um traz o próprio JavaScript e disputa a mesma thread. É comum encontrar sites em que os terceiros somam mais código que a aplicação inteira.

Antes de remover, meça. Uma planilha com o custo em milissegundos de cada script e o retorno que ele traz resolve a discussão mais rápido que qualquer opinião. Costumamos fazer esse inventário no diagnóstico dos nossos projetos de sites com SEO técnico, porque é o item em que a decisão é de negócio, não de engenharia.

Como medir o INP em campo e em laboratório

O número que o Google usa vem de usuários reais, coletado no Chrome. Ele aparece no relatório de experiência do Search Console e no topo do PageSpeed Insights, sempre com janela móvel de 28 dias. É o dado que decide, e ele demora a reagir.

No laboratório não existe INP, porque não há ninguém clicando. O Lighthouse mostra o Total Blocking Time como aproximação: quanto tempo a thread principal ficou ocupada além do limite de tarefa longa. Serve para comparar antes e depois de uma mudança, no mesmo ambiente.

Reproduzir o problema na sua máquina

O caminho mais direto é abrir a página no Chrome, limitar a CPU no painel de performance para simular um celular intermediário e repetir as interações reais do usuário. As tarefas longas aparecem marcadas na linha do tempo, com o arquivo e a função responsáveis.

Também dá para instrumentar o próprio site com a biblioteca oficial de métricas do Google, que reporta o valor de cada visita junto com o seletor do elemento interagido. É o que transforma "o site trava às vezes" em "o botão de filtro da listagem custa 480 milissegundos".

Vale a pena priorizar essa métrica?

Depende de como o site é usado. Em uma página institucional de cinco seções, com pouca interação, o esforço rende pouco. Em catálogo com filtros, painel de cliente, formulário longo ou qualquer coisa com carrinho, é onde o dinheiro se perde de verdade.

Existe também um efeito de percepção. Atraso de carregamento o visitante atribui à internet dele; travamento depois do clique ele atribui ao seu site. Um formulário que congela meio segundo a cada campo produz abandono que nenhum relatório de tráfego explica.

Uma ordem de trabalho que funciona: encontre as duas ou três interações mais lentas nas telas de maior tráfego, meça cada uma com a CPU limitada, corte o trabalho do handler ao mínimo visual, adie o resto e só então discuta scripts de terceiros. Depois disso, confira se as correções não introduziram deslocamento de conteúdo já visível na tela, porque adiar renderização e reservar espaço são decisões que se cruzam.

Por fim, trate o resultado como rotina, não como projeto. Cada funcionalidade nova adiciona código à mesma thread, e a métrica regride sozinha. O panorama de como as três métricas se relacionam e qual dado o Google usa ajuda a decidir o que revisar antes de cada publicação grande.