Uma pontuação INP vermelha não representa um problema de desempenho até que você identifique qual das três fases está consumindo o tempo. A maioria das equipes ignora essa etapa, compra um plugin de cache ou adia a execução de um script e observa o 75º percentil se recusar a avançar. Este guia é a árvore de decisão que utilizamos: sete ramificações que levam você de um número problemático no Relatório de UX do Chrome ao manipulador, script ou tag de terceiros específico responsável, com um limite definido em cada ramificação. Ele foi escrito para líderes de front-end e equipes de crescimento que são responsáveis tanto pela taxa de conversão quanto pela pontuação do Lighthouse.
A lacuna é real. No Almanaque da Web de 2025, 77% das origens móveis apresentaram um bom INP (Indicador de Entrada de Dados). contra 97% em desktops, e apenas 48% das origens móveis atenderam aos três critérios essenciais da Web. (Arquivo HTTPO que ainda apresenta problemas em dispositivos móveis é principalmente a latência de interação, e a maioria deles é facilmente diagnosticável.
O que o INP mede e o que ele ignora silenciosamente.
O relatório "Interaction to Next Paint" indica uma latência de interação por visita de página, no Percentil 75 em sua origem. Bom é 200 ms ou menos, precisa de melhoria se estiver acima de 200 ms e até 500 ms, ruim se estiver acima de 500 ms (web.devTrês aspectos dessa definição alteram a forma como você a depura:
- Apenas cliques, toques e pressionamentos de teclas contam. Passar o cursor, ampliar e A rolagem não é medida.Assim, uma rolagem instável pode dar a impressão de que a página está quebrada, enquanto o indicador de entrada (INP) permanece verde.
- Em páginas com muitas interações, INP ignora uma interação mais alta a cada 50Assim, uma interação catastrófica rara pode ficar oculta em uma página com alto engajamento e surgir em uma com baixo engajamento.
- Cada interação se divide em atraso de entrada (antes que seus tratadores corram), duração do processamento (seus treinadores correndo) e atraso na apresentação (após os seus manipuladores, antes da pintura da estrutura). Estes três não têm praticamente nada em comum como problemas de engenharia (web.dev).
Esse último ponto engloba todo o método. Você não está depurando "INP". Você está depurando uma das três fases, e cada uma tem uma correção diferente.
Ramal 0: confirme se o número é real antes de tocar no código.
Abra o PageSpeed Insights e leia a seção de campos, não a pontuação de laboratório. As ferramentas de laboratório não conseguem medir a entrada de dados (INP), porque a INP exige que um usuário real clique em algo. Se a origem não tiver dados de campo, você tem um problema de tráfego, não de desempenho, e nada do que foi descrito abaixo se aplica ainda. Em seguida, extraia os dados de dispositivos móveis e desktops separadamente — globalmente, a diferença entre eles foi de 20 pontos percentuais em 2025. Se o resultado em dispositivos móveis for vermelho e o em desktops for verde, pare de testar no seu laptop.
Ramo 1: a interação lenta ocorre durante o carregamento ou depois dele?
Instrumente o campo com o web-vitals Atribuição construtiva. Quatro linhas fornecem os dados:
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});
Leia attribution.loadState primeiro. Se a maioria das interações ruins carrega um estado de carga de carregamento or dom-interativoOs usuários estão interagindo enquanto seus scripts ainda estão sendo avaliados: um problema de entrega, corrigido no pacote e no gerenciador de tags, não no manipulador. Se as interações problemáticas estiverem espalhadas por páginas totalmente carregadas, vá para a Branch 2.
Ramo 2: qual subparte detém o tempo?
Folhas para inputDelay, processingDuration e presentationDelay para cada amostra. Nossa regra prática: uma subparte detém a interação quando é responsável por mais de 50% do total de INPSe nenhum deles ultrapassar 50%, trate-o primeiro como um caso de atraso de entrada — a congestão difusa da thread principal geralmente é o que agrava os outros dois casos.
| Subparte dominante | Investigue primeiro | Causa típica | Primeira correção |
|---|---|---|---|
| Atraso de entrada > 50% | longAnimationFrameEntries tipo de invocador | Avaliação de script durante o carregamento; temporizadores; uma interação anterior ainda em execução. | Adiar ou remover scripts de terceiros; dividir pacotes; mover tarefas periódicas para fora da thread. |
| Tempo de processamento > 50% | longestScript e totalScriptDuration | Um manipulador de eventos dispendioso; uma atualização de estado que aciona uma renderização completa. | Ceda a produção dentro do manipulador; mova o trabalho não visual para depois da próxima pintura. |
| Atraso na apresentação > 50% | totalStyleAndLayoutDuration | DOM grande; layout instável; pesado requestAnimationFrame trabalho | Reduzir o tamanho do DOM; aplicar content-visibility; leituras e gravações em lote |
| Nenhuma subparte > 50% | Todas as alternativas anteriores | Congestionamento geral da thread principal | Trate como atraso de entrada, meça novamente e, em seguida, redirecione. |
Ramo 3: dê um nome ao script
A versão de atribuição inclui entradas de quadros de animação longos junto com cada amostra de INP. attribution.longestScript Fornece o invocador, a função e o arquivo fonte do script mais problemático na interação; totalScriptDuration Agrega tudo em 5 ms. É aqui que a vaga afirmação "React é lento" se torna um caminho de arquivo. Verifique o tipo de invocador: classic-script or module-script pontos na avaliação do tempo de carregamento, enquanto user-callback or event-listener aponta para algo que está sendo executado após o carregamento — um observador, um temporizador, um ouvinte de análise (web.dev).
Ramo 4: é seu ou de terceiros?
Organize a atribuição do seu script por origem. Gerenciadores de tags, plataformas de consentimento, ferramentas de gravação de sessão e widgets de chat instalam listeners globais que são executados antes do seu a cada clique. Se uma origem de terceiros aparecer em mais de um quarto das suas piores amostras, a solução é comercial antes de técnica: reduza o escopo da tag, carregue-a na interação ou mova-a para o lado do servidor. Não refatore seu manipulador para recuperar 40 ms que um widget de chat gasta de qualquer forma.
Ramo 5: reproduza o problema no laboratório e, em seguida, corrija o enquadramento.
Retire o seletor de attribution.interactionTargetAbra o Chrome DevTools com a limitação de CPU ajustada de acordo com a sua configuração de dispositivos de campo e grave a interação. Procure por uma tarefa acima de 50 ms, o limiar de tarefa longa (web.dev), e dividi-lo por meio de rendimento.
Navio scheduler.yield() com uma alternativa. O Chrome e o Edge oferecem suporte a partir da versão 129 e o Firefox a partir da 142, mas O Safari não faz isso, nem no computador nem no iOS., e o MDN indica disponibilidade limitada em vez de Baseline (DND, eu posso usarPara um público turco ou do Golfo com grande participação no iOS, um setTimeout O recurso de contingência não é opcional.
Ramo 6: meça o mercado para o qual você realmente vende.
As médias globais do CrUX ocultam o mercado que lhe paga. O conjunto de dados CrUX BigQuery publica tabelas por país — chrome-ux-report.country_tr.YYYYMM Para a Turquia, o mesmo padrão para qualquer código de país de duas letras — atualizado mensalmente, com o formato do dispositivo e o tipo de conexão efetiva como dimensões (Chrome para desenvolvedoresA API pública do CrUX não expõe o país, portanto, essa informação está disponível apenas no BigQuery.
Compare sua origem com a tabela de países para cada mercado em que você vende. Um varejista que atende a Turquia, a Alemanha e o Golfo Pérsico encontra rotineiramente três distribuições INP diferentes a partir de uma mesma base de código, porque a combinação de dispositivos e as condições de rede variam. Corrija o mercado com base na receita, não naquele onde está seu escritório.
Ramo 7: prove que moveu alguma coisa
Considere a correção como um experimento, não como uma implementação definitiva. Trendyol, um mercado turco, rastreou uma entrada de usuário móvel de 963 ms até uma tarefa de 700 a 900 ms causada por um retorno de chamada do IntersectionObserver dentro de um componente React, adiando a atualização do estado com scheduler.yield()e reduziu o INP do 75º percentil de aproximadamente 1,400 ms para aproximadamente 650 ms ao longo de seis meses. Seu teste A/B mostrou uma Aumento de 1% na taxa de cliques de anúncios para detalhes do produto por sessão. (web.dev). ônibus vermelho reduziu o tempo de carregamento lento das interações de 870–900 ms para 350–370 ms, melhorou a interação de entrada de texto em 72% e relatou um Aumento de 7% nas vendas totais (web.dev).
Observe a escala honesta: 1%, não 40%. O que nos leva a um número que vale a pena corrigir.
A cifra de 8.4% merece uma ressalva.
O número mais citado nesta área é que uma melhoria de 0.1 s na velocidade em dispositivos móveis aumenta a conversão no varejo em 8.4% e em viagens em 10.1%. Isso vem de um estudo real — realizado pela 55nd & Deloitte, encomendado pelo Google, com 37 marcas e mais de 30 milhões de sessões (web.devMas ele media métricas de carga, como tempo de carregamento da página e latência do servidor. não INPOs dados abrangem 30 dias no final de 2019; e não havia grupo de controle, portanto, trata-se de uma correlação observada, não de uma relação causal. Use-os para iniciar uma discussão sobre orçamento, não para prever o retorno de uma correção na latência de interação.
[DADOS INTERNOS NECESSÁRIOS: Switas antes/depois do INP p75 e delta de conversão de um engajamento com um cliente, para substituir os estudos de caso públicos por evidências de primeira mão.]
Onde essa árvore de decisão falha
- Origens com pouco tráfego. Com dados de campo fino, o percentil 75 representa ruído. Abaixo de aproximadamente 1,000 interações por modelo por semana, realize o perfilamento em laboratório e aceite que não é possível verificar a vitória no CrUX.
- Usuários do Safari e do Firefox ficam invisíveis. O CrUX é exclusivo do Chrome. Se uma parcela significativa da sua receita vem do Safari no iOS, seus dados INP descrevem uma população que você não está mensurando completamente.
- Problemas com a rolagem estão fora do escopo deste texto. O INP ignora a rolagem, portanto, esta árvore nunca encontrará o problema em uma listagem de rolagem infinita que parece terrível, mas passa nos testes.
- Ele detecta latência, não dívida técnica. Uma interação de 180 ms em um painel de filtros confuso é um problema de UX que esta árvore não consegue enxergar.
Perguntas frequentes
INP é a mesma coisa que First Input Delay (Atraso de Primeira Entrada)?
Não. O FID media apenas o atraso antes da execução dos manipuladores da primeira interação. O INP abrange a latência completa de uma interação representativa ao longo da visita, incluindo a execução dos manipuladores e a pintura subsequente.
Por que minha pontuação no Lighthouse parece normal enquanto o INP está vermelho?
O Lighthouse é uma ferramenta de laboratório e não consegue medir a entrada de dados (INP): não há nenhum usuário real interagindo com nada. Indicadores como o Tempo Total de Bloqueio (Total Blocking Time) têm uma correlação aproximada. Leia a seção de campos do PageSpeed Insights.
Quanto tempo levará para que a correção apareça no CrUX?
O CrUX gera relatórios em uma janela móvel de 28 dias, e as tabelas do BigQuery são publicadas mensalmente. Espere um sinal parcial após cerca de quatro semanas e uma leitura completa após duas publicações mensais.
Posso corrigir o INP sem alterar o framework?
Muitas vezes sim. A solução da Trendyol foi usar um `yield` dentro de um callback no React 16.9, sem necessidade de atualização. Adiar o carregamento de tags de terceiros também é independente do framework.
Um aviso de consentimento afeta o INP?
Isso pode ocorrer de duas maneiras: o próprio script do banner compete pela thread principal durante o carregamento, e a decisão de consentimento geralmente desencadeia um aumento repentino no carregamento de tags imediatamente depois. Meça a primeira interação após o consentimento separadamente.
Preciso de um fornecedor de RUM ou a biblioteca web-vitals é suficiente?
A configuração de atribuição, juntamente com um endpoint de beacon, é suficiente para executar essa árvore. Um fornecedor compra retenção, segmentação e painéis de controle, não dados de atribuição melhores.
Devo otimizar o INP para SEO ou para conversão?
Priorize a conversão. As Core Web Vitals são um fator de ranqueamento, mas os casos de sucesso comprovados — 1% na Trendyol, 7% na redBus — são efeitos na qualidade da interação que, por si só, justificam o trabalho.
Execute este código na sua própria página de anúncios.
Pegue seu modelo de maior tráfego, implemente-o com a atribuição e percorra os ramos de 0 a 7 em ordem. Se preferir executar a árvore com seus próprios dados de campo, incluindo a segmentação por país e o desenho do experimento, nosso equipe de desempenho da web faz exatamente isso.
Fontes
- Interação para a Próxima Pintura (INP) — web.dev
- Otimizar a interação com a próxima renderização — web.dev
- Encontre interações lentas no campo — web.dev
- Otimize tarefas longas — web.dev
- Desempenho — Almanaque da Web 2025, Arquivo HTTP
- Como a Trendyol reduziu o INP em 50% — web.dev
- Como a redBus melhorou a entrada de clientes e aumentou as vendas em 7% — web.dev
- Milissegundos fazem milhões — web.dev / 55 / Deloitte
- CrUX no BigQuery — Chrome para desenvolvedores
- Agendador: yield() — MDN
- API do agendador: rendimento — caniuse
- Biblioteca JavaScript web-vitals — GoogleChrome/web-vitals
