O que não mudou
Começando pelo desmentido, porque a desinformação aqui gerou trabalho desnecessário em vários times.
Os limites oficiais de 2026 continuam os mesmos: LCP abaixo de 2,5 segundos, INP abaixo de 200 milissegundos, CLS abaixo de 0,1. A medição continua sendo feita com dados de campo, no percentil 75, em janela móvel de 28 dias. O conjunto de métricas segue sendo LCP, INP e CLS, com o INP tendo substituído o FID em 2024.
Se alguém apresentou para você um novo limite de INP, era rumor. Ignore e siga.
O que mudou de fato
A mudança foi na metodologia de medição, não no alvo. O Google refinou a forma como o INP captura latência sustentada em páginas com muita interação.
Antes, uma página com dezenas ou centenas de interações se beneficiava de um efeito estatístico: como o INP considera aproximadamente a pior interação descontando outliers, muita interação rápida diluía as lentas. Um app com 200 cliques por sessão, sendo 190 instantâneos e 10 travados, podia mostrar um INP razoável.
A mudança faz a latência sustentada pesar mais na amostragem. Traduzindo: site que dispara bastante JavaScript a cada clique não se beneficia mais da média generosa. A métrica ficou mais próxima do que uma pessoa irritada realmente sente ao usar a página.
Como isso aparece no seu painel: INP piorando no CrUX sem que ninguém tenha mexido no código. Não é regressão do seu site, é a métrica medindo melhor o que já estava acontecendo.
Quem sente mais
Pelo perfil da mudança, os tipos de página mais afetados são bem previsíveis:
- E-commerce com filtro e faceta. Cada clique em filtro dispara requisição, re-render de lista e atualização de contadores. Interação repetida com trabalho pesado é exatamente o caso alvo.
- Dashboards e ferramentas web. Muita interação, muito estado, muito recálculo.
- SPAs com estado global grande. Onde um clique aciona re-render de árvore inteira.
- Páginas com muita tag de terceiro. Cada script disputa a thread principal, e o custo aparece na interação.
Quem quase não sente: site de conteúdo estático, institucional simples, blog. Poucas interações, pouco JavaScript por clique.
Como corrigir
As técnicas não são novas, mas a prioridade entre elas mudou. O que dá mais resultado, na ordem:
Quebrar long tasks
Tarefa de JavaScript acima de 50 ms bloqueia a thread e atrasa a resposta visual. Divida em pedaços menores para o navegador conseguir processar interação no meio. O scheduler.yield() é a forma moderna de fazer isso, com setTimeout como alternativa em navegador sem suporte.
Adiar o que não é urgente
Nem tudo que acontece após um clique precisa acontecer antes da resposta visual. Analytics, log, pré-carregamento e sincronização podem esperar. Atualize a interface primeiro, faça o resto depois. Isso costuma ser a mudança de maior impacto e a mais barata.
Reduzir trabalho de renderização
Em framework com estado, verifique o escopo de re-render. Um clique em checkbox que redesenha 400 componentes é um problema de arquitetura, não de otimização.
Domar os scripts de terceiro
Cada tag de marketing compete pela thread. Carregue com defer ou async, adie o que não é essencial para depois da interação, e revise periodicamente o que ainda está lá. Sempre encontro tag de campanha encerrada há dois anos ainda rodando.
Dar feedback imediato
Se o processamento é inevitavelmente longo, mude o estado visual do elemento imediatamente e processe depois. O INP mede até a próxima renderização, então uma mudança visual rápida melhora a métrica e melhora de verdade a percepção.
Como medir direito
Duas fontes, com papéis diferentes, e confundir os dois é o erro mais comum:
Dados de campo, do CrUX e do relatório de Core Web Vitals no Search Console, são os que valem para avaliação do Google. São usuários reais, dispositivos reais, redes reais.
Dados de laboratório, do Lighthouse e do PageSpeed Insights, servem para diagnosticar. O Lighthouse nem calcula INP, porque não existe interação real numa auditoria automatizada. Se alguém apresenta INP do Lighthouse, é outra métrica.
Para diagnosticar INP de verdade, o caminho é o painel Performance do Chrome DevTools, gravando a interação que você suspeita, e olhando o desdobramento entre delay de entrada, tempo de processamento e tempo de apresentação. Cada um pede uma correção diferente.
Se quiser acompanhar sem olhar manualmente todo mês, dá para montar coleta e alerta automatizados. Descrevo a abordagem em monitorar visibilidade em IA com n8n, e a mesma lógica serve para CWV.
Diagnóstico no DevTools
Como o Lighthouse não calcula INP, o diagnóstico real acontece no painel Performance do Chrome. O procedimento que uso:
Prepare o ambiente. Aba anônima, extensões desativadas, e limitação de CPU em 4x ou 6x para simular celular intermediário. Sem limitação, você não reproduz o problema que os usuários têm.
Grave a interação suspeita. Inicie a gravação, execute a interação, pare. Repita algumas vezes na mesma gravação, porque a mudança de 2026 pesa justamente a latência sustentada em interação repetida.
Leia o desdobramento. O INP tem três partes, e cada uma pede correção diferente:
- Input delay: tempo até o handler começar a rodar. Alto significa thread ocupada com outra coisa. A correção é reduzir trabalho de fundo e quebrar tarefas longas.
- Processing time: tempo do handler. Alto significa que o seu código faz coisa demais no clique. A correção é adiar o que não é urgente.
- Presentation delay: tempo até pintar. Alto costuma ser recálculo de layout ou re-render grande. A correção é reduzir escopo de renderização.
Sem esse desdobramento, otimização de INP vira tentativa e erro. Já vi time investir semanas reduzindo bundle quando o problema estava inteiramente em presentation delay.
Confirme no campo. Laboratório aponta a causa, campo confirma o resultado. Use a biblioteca web-vitals para coletar INP real dos seus usuários e enviar ao analytics, porque assim você mede a distribuição em vez de um caso.
Padrões de código que quebram INP
Os que mais encontro, na ordem em que costumam aparecer:
Tudo no mesmo handler. O clique valida, atualiza estado, dispara analytics, salva no localStorage, faz requisição e re-renderiza. Tudo antes da próxima pintura. A correção é atualizar a interface primeiro e mover o resto para depois, com setTimeout de zero ou requestIdleCallback.
Layout thrashing. Ler propriedade geométrica e escrever no DOM alternadamente, em loop, força recálculo a cada iteração. Agrupe leituras e depois escritas.
Re-render de escopo grande. Um clique que redesenha uma árvore inteira porque o estado está no topo. É problema de arquitetura, e a correção é memoização ou estado mais próximo de quem usa.
Listener sem passivo em scroll e touch. Bloqueia a rolagem enquanto o navegador espera saber se haverá preventDefault. Marque como passivo quando não for necessário.
Observador caro. Um MutationObserver ou ResizeObserver com callback pesado que dispara em cascata.
Script de terceiro que sequestra a thread. Chat, mapa de calor, teste A/B. Costumam ser a maior fatia de trabalho na thread principal e são os mais fáceis de adiar, porque quase nenhum precisa rodar antes da primeira interação.
A correção com melhor retorno: na maioria dos casos que diagnostiquei, adiar analytics e scripts de marketing para depois da atualização visual resolveu mais que qualquer refatoração de código próprio.
Orçamento de performance
Otimização pontual regride. Em três meses alguém adiciona uma tag e volta tudo. O que sustenta é orçamento definido e verificado no pipeline.
Defina limites explícitos. Peso de JavaScript por rota, número de requisições de terceiro, tempo total de bloqueio da thread. Números, não intenções.
Verifique no CI. Uma checagem automática que falha o build quando o orçamento estoura. É a única forma que conheço de manter isso ao longo do tempo, porque tira a decisão da negociação caso a caso.
Crie um processo para tag nova. Toda tag de marketing passa por medição antes de entrar em produção, e tem responsável e data de revisão. Sem isso, o acúmulo é inevitável.
Monitore o campo continuamente. CrUX tem atraso de 28 dias. Coleta própria com a biblioteca web-vitals dá visibilidade quase em tempo real, e permite alertar quando o percentil 75 piora. O desenho de alerta está em monitorar visibilidade em IA com n8n.
Revise o inventário de terceiros a cada trimestre. Em toda auditoria que faço encontro pelo menos uma tag de campanha encerrada ainda rodando. Custa performance e não entrega nada.
Conclusão
Gosto dessa mudança porque ela corrige uma injustiça da métrica anterior. Um site que trava em dez de cada duzentas interações trava de verdade para quem está usando, e passava por bom por causa da matemática.
Se o seu INP piorou sem explicação nos últimos meses, provavelmente é isso. E a correção não passa por microotimização: passa por fazer menos trabalho a cada clique, que é uma decisão de arquitetura de front-end mais do que de performance.
O aprofundamento das três métricas está em Core Web Vitals em 2026, e o trabalho prático em SEO técnico.