Interaction to Next Paint (INP) para SEO

TL;DR — O INP mede a rapidez com que sua página responde quando alguém clica, toca ou digita. O navegador cronometra o intervalo entre a interação e a próxima atualização visual, ao longo de toda a visita, e relata aproximadamente a pior delas. Abaixo de 200 ms é bom; acima de 500 ms é ruim. É uma das três Core Web Vitals e substituiu uma métrica mais antiga chamada First Input Delay em 2024.

O que o INP realmente mede

Quando você clica em um botão, toca em um menu ou digita em uma caixa, espera que a página reaja — um menu abre, uma caixa de seleção é marcada, o texto aparece. Interaction to Next Paint (INP) mede quanto tempo isso leva: o tempo desde a sua interação até o navegador pintar o próximo quadro mostrando algo que mudou.

Aqui está a parte que importa. O INP não analisa apenas uma interação. Ele observa cada clique, toque e pressionamento de tecla durante toda a sua visita e relata (aproximadamente) a mais lenta. Portanto, uma única interação instável — uma caixa de busca que congela por meio segundo toda vez que você digita — pode derrubar toda a pontuação.

Rolar, passar o mouse e dar zoom não contam. Apenas cliques, toques e interações de teclado são medidos.

Os limites

O INP é relatado em milissegundos, e o Google o classifica em três categorias:

• Bom — 200 ms ou menos
• Precisa de melhorias — mais de 200 ms, até 500 ms
• Ruim — mais de 500 ms

Para contexto: 200 ms é rápido, mas não é muita margem. Tudo o que seu código faz em resposta a um clique — além do navegador desenhar o resultado — precisa caber dentro disso.

Por que substituiu o FID

A métrica de responsividade antiga era a First Input Delay (FID). A FID apenas media o atraso antes de a primeira interação em uma página começar a ser processada — e parava de cronometrar no momento em que o trabalho começava. Ela não contava quanto tempo esse trabalho realmente levava, nem quanto tempo a tela levava para atualizar.

O INP corrigiu tudo isso. Ele mede o tempo total (do início à atualização visual) para todas as interações, não apenas a primeira. O Google tornou a mudança oficial em 12 de março de 2024, e a FID desapareceu das ferramentas completamente em setembro de 2024.

O que torna o INP ruim — em termos simples

Quase sempre, é o JavaScript monopolizando a thread principal. O navegador só pode fazer uma coisa por vez nessa thread, então, se um trecho de script estiver ocupado executando, seu clique terá que esperar na fila. Culpados comuns:

• Trabalho pesado executado dentro do próprio manipulador de clique/toque.
• Grandes “tarefas longas” de JavaScript bloqueando tudo.
• Scripts de terceiros — analytics, banners de consentimento de cookies, widgets de chat, gerenciadores de tags. Esses são alguns dos piores infratores, mesmo em sites de conteúdo simples.

A correção, de modo geral, é fazer menos trabalho quando alguém interage e dividir grandes tarefas em pequenas partes para que o navegador possa encaixar sua interação entre elas.

Quer a mecânica real — a decomposição da latência em três partes, a matemática do 75º percentil, exatamente como corrigir cada causa e o ângulo de SEO? Mude para a aba Avançado.

TL;DR — O INP é a Core Web Vital para responsividade. Ele observa a latência de todas as interações de clique, toque e teclado durante uma visita e relata o valor no 75º percentil (um outlier descartado a cada 50 interações) — não apenas a primeira entrada como a FID fazia. A latência de uma interação = atraso de entrada + duração do processamento + atraso de apresentação. Bom ≤ 200 ms, ruim > 500 ms, avaliado com dados de campo no p75. Ele substituiu a FID em 12 de março de 2024 (FID totalmente removida das ferramentas em setembro de 2024). Corrija-o dividindo tarefas longas, cedendo à thread principal com scheduler.yield(), fazendo menos nos manipuladores de eventos, reduzindo o DOM e adiando scripts de terceiros. É uma métrica de campo — Total Blocking Time é o proxy de laboratório, e os dois nem sempre concordam.

O que o INP mede — e como difere da FID

A definição do Google é precisa: INP “avalia a responsividade geral de uma página às interações do usuário, observando a latência de todos os cliques, toques e interações de teclado que ocorrem ao longo da vida útil da visita de um usuário a uma página.”

Essa frase “todas as interações… ao longo da vida útil” é a história completa. INP é uma métrica de nível de visita, não de tempo de carregamento — e o raciocínio do Google é que a grande maioria do tempo do usuário em uma página acontece depois que ela carrega, então a responsividade durante o uso importa mais do que a primeira impressão sozinha.

O contraste com o First Input Delay é a maneira mais clara de entender isso: “O FID media apenas o atraso de entrada da primeira interação em uma página. O INP melhora o FID observando todas as interações em uma página, desde o atraso de entrada até o tempo necessário para executar os manipuladores de eventos.” O FID cronometrava uma coisa sobre uma interação — a espera antes do início do manipulador — e ignorava tanto o tempo de execução do manipulador quanto o tempo que a tela levava para atualizar. O INP mede a latência total de cada interação.

Uma nuance que vale a pena acertar, porque é um mito comum: o INP não é literalmente a pior interação. Para evitar punir uma página por um único pico aleatório, o navegador descarta um outlier para cada 50 interações e, em seguida, relata o valor no 75º percentil das visualizações de página. Em uma visita com poucas interações, isso recai na interação mais lenta; em uma visita intensa, alguns outliers são excluídos primeiro.

O que conta como interação também é mais restrito do que as pessoas assumem. Apenas cliques, toques e pressionamentos de teclado são medidos. Rolagem, passar o mouse e zoom são explicitamente excluídos. E um único gesto pode disparar vários eventos — um toque produz pointerdown, pointerup e click — que o INP agrupa como uma interação, não três. Dentro desse grupo, o INP considera a duração mais longa de evento individual, não a soma de todos eles — então um pointerdown rápido ao lado de um click lento ainda é relatado como uma interação dimensionada pelo evento lento. Se uma página não tiver interações qualificadas durante uma visita, o INP simplesmente não é relatado para ela.

As três partes da latência de uma interação

A latência de cada interação se divide em três partes sequenciais. Este é o modelo para manter em mente, porque cada parte aponta para uma correção diferente:

Latência da interação = Atraso de entrada + Duração do processamento + Atraso de apresentação

1. Atraso de entrada — o tempo antes que seus manipuladores de eventos possam até começar a executar, geralmente porque a thread principal está ocupada terminando uma tarefa longa.
2. Duração do processamento — o tempo que leva para todos os seus callbacks de manipuladores de eventos executarem.
3. Atraso de apresentação — o tempo desde quando seus manipuladores terminam até o navegador pintar o próximo frame na tela.

A compilação de atribuição do web-vitals expõe todos os três (inputDelay, processingDuration, presentationDelay) para que você possa ver qual parte domina em uma interação real. De acordo com os dados do Web Almanac de 2024, o atraso de apresentação é frequentemente a maior parte individual na mediana — mas a duração do processamento é onde a alavancagem de otimização geralmente reside, porque é a parte que aumenta em páginas mal construídas.

Os limites — e a ressalva do campo p75

O Google Search Central afirma o alvo claramente — “um INP de menos de 200 milissegundos” — e enquadra todo o programa como: “Recomendamos fortemente que os proprietários de sites alcancem bons Core Web Vitals para o sucesso na Pesquisa.” O orçamento de 200 ms é genuinamente apertado quando você lembra que o navegador quer um frame a cada ~16,7 ms a 60 fps; todo o trabalho do seu manipulador mais a renderização tem que caber.

Por que o INP é uma métrica de campo (e os dados de laboratório não são suficientes)

Esta é a armadilha que pega muitos profissionais de SEO: uma pontuação verde no Lighthouse não significa um bom INP. Mas “o Lighthouse não consegue medir o INP” precisa de três casos separados, não um, ou você vai interpretar mal sua própria ferramenta:

1. Uma execução padrão e não interativa do Lighthouse não relata INP algum. Ela apenas observa o carregamento da página — nunca clica, toca ou digita nada — então não há interação para cronometrar. O Lighthouse usa como fallback o Tempo Total de Bloqueio (TBT) como proxy do tempo de carregamento. O próprio enquadramento do Google: “Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” (tradução) «Como o TBT se correlaciona bem com o INP, uma página com TBT alto é um indicador razoável de que pode haver valores altos de INP durante o carregamento.» As palavras-chave são “during load.” (tradução) «durante o carregamento.» O TBT não diz nada sobre uma interação que dá errado dez segundos depois, quando um widget carregado de forma preguiçosa é executado — é um proxy, nunca um substituto ou uma fórmula de conversão.
2. Uma interação exercitada manualmente ou sinteticamente — clicar em um botão real no DevTools, ou scriptar um clique em uma ferramenta de laboratório — produz um número real de latência no estilo INP para aquela interação específica. Isso é útil para reproduzir um bug específico. Mas ainda é um único caminho scriptado em um único dispositivo: não pode representar a mistura de dispositivos reais, usuários reais, alvos de interação reais e a vida útil completa de uma visita no campo. Como o Google coloca, o valor resultante “will be dependent on what interactions are performed during the measurement period,” (tradução) «dependerá de quais interações são realizadas durante o período de medição», e o comportamento real do usuário é variável demais para uma única execução de laboratório representá-lo.
3. A distribuição de campo é a única coisa que o INP realmente é. É por isso que a fonte autoritativa são os dados de campo: o Chrome User Experience Report (CrUX), apresentado por meio do PageSpeed Insights e do relatório Core Web Vitals do Search Console. “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (tradução) «Os dados de campo são a melhor fonte de informação que você pode usar para entender quais interações são problemáticas para usuários reais.»

Use o laboratório (casos 1 e 2) para encontrar e reproduzir uma interação lenta; use o campo (caso 3) para confirmar se ela está realmente prejudicando as pontuações dos visitantes reais.

Por que sua pontuação de INP é ruim

Quase todo problema de INP remonta ao thread principal estar bloqueado quando um usuário interage. Os suspeitos usuais:

• Tarefas longas. Qualquer tarefa no thread principal acima de 50 ms é uma tarefa longa; a quantidade acima de 50 ms é seu “período de bloqueio”. Enquanto uma está em execução, sua interação não pode ser tratada. Esta é a maior causa isolada.
• Manipuladores de eventos pesados. Fazer demais de forma síncrona dentro de um manipulador de clique/entrada infla diretamente a duração do processamento.
• Tamanho grande do DOM. DOMs maiores custam mais para renderizar, o que infla tanto o atraso de entrada quanto o de apresentação.
• Scripts de terceiros. De acordo com o Web Almanac, provedores de consentimento, gerenciadores de tags, análises e widgets de chat são os principais infratores — e eles afetam até sites de conteúdo simples. Eles são o primeiro lugar onde eu olho em uma página que não construí.
• JavaScript pós-carregamento. Só porque uma página renderizou não significa que terminou de carregar — scripts que são avaliados após a primeira pintura podem bloquear interações iniciais.

Como corrigir

As estratégias, aproximadamente em ordem de impacto:

1. Divida tarefas longas. O conselho central do Google sobre manipuladores é “do as little work as possible in them.” (tradução) «faça o mínimo de trabalho possível neles.» Divida um trabalho grande em tarefas menores para que o navegador possa intercalar uma interação do usuário. Quando as tarefas são divididas, “the browser can respond to higher-priority work much sooner — including user interactions.” (tradução) «o navegador pode responder a trabalhos de prioridade mais alta muito mais cedo — incluindo interações do usuário.»

2. Ceda a thread principal. A forma moderna e recomendada é scheduler.yield() (Chrome 129+, Firefox 142+): await scheduler.yield() pausa seu código, permite que o navegador lide com o trabalho pendente e retoma com prioridade — para que outras tarefas não furem a fila à frente da sua continuação. O fallback clássico é setTimeout(..., 0), que ainda funciona, mas envia seu código para o final da fila de tarefas (e os navegadores impõem um piso de 5 ms após várias chamadas aninhadas). Uma coisa para parar de fazer: isInputPending() — o Google agora diz “we no longer recommend using this API.” Veja a aba Scripts para o padrão.

3. Faça menos nos manipuladores de eventos — adie o trabalho não crítico. Execute apenas a atualização visual que o próximo frame precisa de forma síncrona; empurre todo o resto (salvar, verificação ortográfica, análises, contagens de palavras) para trás de requestAnimationFrame + setTimeout ou um yield. O usuário vê a resposta imediatamente; a contabilidade acontece depois.

4. Evite layout thrashing. Ler propriedades de layout logo após escrever estilos na mesma tarefa força o navegador a um layout síncrono que ele poderia ter agrupado. Agrupe leituras e depois escritas.

5. Reduza o tamanho do DOM. Árvores menores renderizam mais rápido. content-visibility pode renderizar lazy elementos fora da tela para que não custem durante o carregamento ou interação.

6. Audite e adie scripts de terceiros. Esta é a correção de SEO de maior alavancagem em sites reais. Carregue scripts de consentimento/tag/análises de forma lazy, condicione-os à interação ou mova-os para fora do caminho crítico. Uma página de conteúdo “leve” pode falhar no INP puramente por causa de um widget incorporado pesado.

O INP afeta o ranqueamento?

Sim — o INP é um dos três Core Web Vitals, e os Core Web Vitals fazem parte dos sinais de experiência de página do Google. Mas é um sinal leve: um desempate entre resultados comparavelmente relevantes, não um fator de ranqueamento primário. Não persiga uma pontuação INP perfeita às custas de conteúdo e relevância.

Dois pontos práticos de SEO. Primeiro, mobile é o número difícil. No Web Almanac de 2024, ~74% dos sites mobile passaram no INP versus ~97% no desktop — e como o Google indexa mobile-first, o número mobile é o que conta. Segundo, sites complexos vão pior: apenas ~53% dos 1 000 principais sites passaram, porque páginas ricas em recursos enviam mais JavaScript para bloquear a thread principal. O desenvolvimento pesado de recursos é um risco para o INP, e páginas de alta interação — páginas de produto, checkout, resultados de busca, formulários — estão muito mais expostas do que conteúdo estático.

INP vs FID — o quadro completo

O FID se foi — removido do Search Console no dia em que o INP foi lançado e do CrUX BigQuery/API até setembro de 2024. Se uma ferramenta ou auditoria ainda referencia o FID, está desatualizada.

Casos extremos que fazem os dados do INP discordarem

Um punhado de peculiaridades do ciclo de vida explica a maioria das perguntas “por que meu RUM não corresponde ao CrUX”:

• Sem interações, sem INP. Se uma visita nunca recebe um clique, toque ou pressionamento de tecla — ou recebe apenas gestos excluídos, como rolagem e passar o mouse — não há valor de INP para essa visualização de página. Isso é normal em páginas de conteúdo somente leitura e não é um bug no seu monitoramento.
• Iframes contam para a métrica, mas seu próprio JavaScript não consegue ver dentro deles. Uma interação dentro de um iframe incorporado (um anúncio, um widget, um formulário incorporado) contribui para o INP da página. Mas um script RUM de primeira parte não consegue ler eventos de um iframe de origem cruzada da mesma forma que a métrica do próprio navegador consegue — então o CrUX e uma configuração RUM de mesma origem podem legitimamente discordar em páginas com incorporações de terceiros. Documente essa lacuna em vez de tratar uma discrepância entre RUM/campo como um bug.
• Restaurações do cache de ida e volta redefinem o INP para zero. Uma página recuperada do bfcache (o botão voltar, por exemplo) inicia uma contagem de INP do zero — as interações anteriores à navegação de saída não são transferidas.
• Abas de longa duração e em segundo plano ainda precisam reportar. Como uma aba pode ficar aberta por horas sem nunca ser formalmente descarregada — especialmente no celular, onde o sistema operacional pode simplesmente matá-la — o INP deve ser capturado quando a página fica oculta, não apenas no descarregamento. Configurações de RUM que só enviam dados no unload perderão silenciosamente dados dessas visitas.

Onde isso se encaixa

O INP é uma peça do quadro dos Core Web Vitals, junto com o Largest Contentful Paint (carregamento) e o Cumulative Layout Shift (estabilidade visual). Verifique-o no PageSpeed Insights e no relatório do Search Console (campo), e depure-o no Lighthouse / Chrome DevTools (laboratório, via proxy TBT). Os dados por trás de tudo isso vêm do CrUX.

Resumo de IA

Uma visão condensada da versão Avançada:

• INP = o Core Web Vital para responsividade. Ele observa a latência de todas as interações de clique, toque e teclado ao longo de uma visita inteira e reporta o valor no 75º percentil (um outlier descartado a cada 50 interações) — não apenas a primeira entrada como o FID fazia.
• Latência = atraso de entrada + duração do processamento + atraso de apresentação. Cada parte aponta para uma correção diferente; a duração do processamento geralmente é onde está a alavancagem.
• Limiares (campo, p75): bom ≤ 200 ms, precisa de melhorias ≤ 500 ms, ruim

  500 ms.

• Apenas cliques, toques e teclado contam — rolagem, passar o mouse e zoom são excluídos; os múltiplos eventos de um único gesto são agrupados como uma interação.
• Ele substituiu o FID em 12 de março de 2024 (FID totalmente removido das ferramentas em setembro de 2024). O FID apenas cronometrava o atraso de entrada da primeira interação.
• É uma métrica de campo, e “o Lighthouse não consegue medi-la” tem três casos: uma execução padrão não interativa do Lighthouse não reporta INP e recorre ao Total Blocking Time como proxy de tempo de carregamento; uma interação de laboratório exercitada manualmente produz uma latência real de interação única, mas não pode substituir a população de campo; apenas dados de campo do CrUX / PageSpeed Insights / Search Console são autoritativos.
• Causas: tarefas longas (>50 ms), manipuladores de eventos pesados, DOM grande e especialmente scripts de terceiros (consentimento, gerenciadores de tags, analytics, chat).
• Correções: divida tarefas longas, ceda com scheduler.yield() (fallback de setTimeout; isInputPending() não é mais recomendado), faça menos nos manipuladores, evite thrashing de layout, reduza o DOM, adie scripts de terceiros.
• Casos de borda: nenhuma interação qualificada significa nenhum valor de INP; interações em iframe contam para a métrica, mas um script RUM de mesma origem não consegue ver dentro deles; restaurações de bfcache redefinem o INP; abas de longa duração/em segundo plano devem reportar em hidden, não apenas no unload.
• SEO: um sinal de ranqueamento leve. Mobile (~74% de aprovação vs ~97% no desktop) é o número que importa sob indexação mobile-first; páginas com alta interação são as mais expostas.

Documentação oficial

Documentação de fonte primária do Google / equipe do Chrome.

web.dev — as referências de INP

• Interaction to Next Paint (INP) — a definição definitiva: o que mede, a decomposição da latência em três partes, os tipos de interação e os limites.
• Optimize Interaction to Next Paint — o guia de otimização: fazer menos nos manipuladores, adiar trabalho não crítico, thrashing de layout, tamanho do DOM, content-visibility.
• Interaction to Next Paint officially becomes a Core Web Vital — o post de lançamento de 12 de março de 2024 (Jeremy Wagner & Rick Viscomi); a linha do tempo da descontinuação do FID.
• First Input Delay (FID) — a métrica descontinuada; o que media e por que foi substituída.
• A new responsive metric: seeking your feedback — as limitações de design do FID e as melhorias do INP.
• Optimize long tasks — a definição de tarefa longa de 50 ms, scheduler.yield(), o fallback setTimeout e por que isInputPending() não é mais recomendado.
• Script evaluation and long tasks — o TBT como proxy do INP e orientações sobre tamanho de script.
• Find slow interactions in the field — o build de atribuição do web-vitals e a API Long Animation Frames (LoAF).

Chrome / Google Search

• Performance features reference (Chrome DevTools) — a trilha Interactions, Live Metrics e o aviso de 200 ms.
• CrUX release notes — confirma a remoção do FID do BigQuery/API em setembro de 2024.
• Core Web Vitals & Google Search results — o INP como parte do sinal de experiência de página; o alvo de ≤ 200 ms.

Citações da fonte

Declarações oficiais do Google / da equipe do Chrome. Cada link é um deep link que salta para a passagem citada na página de origem.

O que o INP mede e como difere do FID

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (tradução) «O INP é uma métrica de Core Web Vitals que avalia a responsividade geral de uma página às interações do usuário, observando a latência de todas as interações de clique, toque e teclado que ocorrem durante a vida útil da visita de um usuário a uma página.» — web.dev, Interaction to Next Paint (INP). Ir para a citação
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (tradução) «O FID media apenas o atraso de entrada da primeira interação em uma página. O INP melhora o FID ao observar todas as interações em uma página, desde o atraso de entrada até o tempo necessário para executar os manipuladores de eventos.» Ir para a citação
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (tradução) «O First Input Delay (FID) não é mais um Core Web Vital e foi substituído pela métrica Interaction to Next Paint (INP).» — web.dev, First Input Delay (FID). Ir para a citação

A troca de FID → INP

• “FID will be deprecated.” (tradução) «O FID será descontinuado.» — Jeremy Wagner & Rick Viscomi, blog do web.dev, Interaction to Next Paint officially becomes a Core Web Vital. Ir para a citação
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (tradução) «O FID será removido do Google Search Console assim que o INP se tornar um Core Web Vital em 12 de março.» Ir para a citação

Tarefas longas — a causa principal

• “Any task that takes longer than 50 milliseconds is a long task.” (tradução) «Qualquer tarefa que leve mais de 50 milissegundos é uma tarefa longa.» — web.dev, Optimize long tasks. Ir para a citação

Os dados de campo são primários

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (tradução) «Os dados de campo são a melhor fonte de informação que você pode usar para entender quais interações são problemáticas para usuários reais.» — web.dev, Find slow interactions in the field. Ir para a citação

Google Search

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (tradução) «Recomendamos fortemente que os proprietários de sites atinjam bons Core Web Vitals para obter sucesso na Pesquisa.» — Google Search Central, Core Web Vitals & Google Search results. Fonte

Lista de verificação para corrigir o INP

Trabalhe de cima para baixo — os itens próximos ao topo tendem a mover mais o número:

• Obtenha o INP de campo (PageSpeed Insights / relatório de CWV do Search Console), não apenas uma pontuação de laboratório — e verifique o celular separadamente.
• Identifique a(s) interação(ões) lenta(s) com a compilação de atribuição do web-vitals ou a trilha de Interações do Chrome DevTools (ela sinaliza qualquer coisa acima de 200 ms).
• Encontre e divida tarefas longas (qualquer coisa acima de 50 ms na thread principal).
• Ceda à thread principal dentro de loops de longa duração — scheduler.yield(), com um fallback de setTimeout(..., 0). (Pare de usar isInputPending().)
• Dentro de cada manipulador, execute apenas a atualização crítica para renderização de forma síncrona; adie salvar, validação, verificação ortográfica e analytics para depois de rAF + setTimeout.
• Verifique se há thrashing de layout — ler o layout logo após escrever estilos na mesma tarefa. Agrupe leituras e depois escritas.
• Audite scripts de terceiros (consentimento, gerenciador de tags, analytics, chat). Adie, carregue preguiçosamente ou condicione-os à interação — geralmente a maior vitória individual.
• Reduza o tamanho do DOM; aplique content-visibility a seções fora da tela.
• Adie / divida o código de JS não crítico para que scripts pós-carregamento não bloqueiem interações iniciais.
• Meça novamente em campo após a implantação — o CrUX é uma janela contínua de 28 dias, então a pontuação se move lentamente.

INP vs FID — folha de referência

Fatos rápidos

• Limites (campo, p75): Bom ≤ 200 ms · Precisa de melhorias ≤ 500 ms · Ruim > 500 ms.
• Contagens: cliques, toques, teclado. Exclui: rolagem, passar o mouse, zoom.
• Latência = atraso de entrada + duração do processamento + atraso de apresentação.
• Tarefa longa = qualquer tarefa na thread principal > 50 ms.
• Proxy de laboratório: Tempo de Bloqueio Total — correlaciona, mas reflete apenas o bloqueio durante o carregamento. A fonte autoritativa são os dados de campo (CrUX).
• A taxa de aprovação no celular (~74%) é muito inferior à do desktop (~97%) — e o celular é o que importa.

Ceda à thread principal

Quando você tem um loop de longa duração (renderizando uma lista grande, processando dados em um clique), periodicamente devolva o controle ao navegador para que ele possa atender a uma interação pendente do usuário. A API moderna é scheduler.yield(); use setTimeout como fallback onde ela não for suportada.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Algumas observações:

• scheduler.yield() retorna uma promise que resolve em uma futura tarefa, e sua continuação é priorizada — outras tarefas na fila não passarão à frente do seu código retomado.
• setTimeout(..., 0) funciona em todos os lugares, mas coloca sua continuação no final da fila (e os navegadores impõem um limite mínimo de ~5 ms após várias chamadas aninhadas).
• Não use isInputPending() — o Google “no longer recommend[s] using this API.” (tradução) «não recomenda mais o uso dessa API.»

Adie trabalho não crítico em um manipulador

Execute apenas o que o próximo frame precisa; empurre o resto para depois de uma pintura.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

Ferramentas para medir e corrigir o INP

Campo (autoritativo — é isso que o Google pontua)

• PageSpeed Insights — INP de campo do CrUX para a URL/origem, dividido por mobile e desktop, além de uma passagem de diagnóstico em laboratório.
• Search Console — Relatório de Core Web Vitals — status do INP em suas URLs, agrupado por problema, com dados de campo.
• CrUX — o conjunto de dados subjacente do Chrome User Experience Report (também consultável via API do CrUX / BigQuery).

Laboratório / depuração

• Chrome DevTools — Painel Performance — a trilha Interactions cronometra o atraso de entrada, o processamento e a apresentação de cada interação, e sinaliza qualquer coisa acima de 200 ms; Live Metrics é atualizado conforme você clica.
• Lighthouse — não consegue medir o INP diretamente; relata Total Blocking Time como proxy de laboratório.

Monitoramento de usuário real (RUM)

• Biblioteca JS web-vitals — onINP() para o valor; a versão de atribuição (web-vitals/attribution) expõe inputDelay / processingDuration / presentationDelay, o seletor interactionTarget e entradas LoAF para que você possa ver exatamente qual script e elemento causaram a interação lenta. Qualquer configuração de RUM que você use, documente sua taxa de amostragem e cobertura de atribuição — um número de RUM citado sem esse contexto não é comparável ao p75 de campo do CrUX, e ele não consegue ver dentro de iframes de origem cruzada da mesma forma que a métrica agregada consegue (veja Casos extremos, na aba Avançado).

Como as próprias ferramentas pontuam

Um exemplo ao vivo da métrica que esta página descreve — serviços conhecidos de velocidade de página e monitoramento ranqueados pelo próprio INP móvel de usuário real (dados de campo do Chrome UX Report):

Correções de INP que geralmente não resolvem o problema

Otimizando apenas a primeira interação

O INP avalia interações ao longo da visita, não apenas a primeira entrada. Exercite menus, busca, filtros, formulários e outros controles repetidos antes de decidir que a página é responsiva.

Tratando o Total Blocking Time como o resultado

O TBT é um proxy de laboratório útil porque expõe tarefas longas na thread principal, mas não é o INP de campo. Use-o para encontrar candidatos e depois verifique interações reais com dados de campo ou um trace de interação.

Movendo todo o trabalho para um único callback atrasado

Adiar um bloco grande pode simplesmente mover o congelamento. Divida o trabalho em tarefas menores e ceda o controle para que o navegador possa pintar entre elas.

Removendo feedback visual para encurtar o manipulador

Um controle que executa trabalho sem mostrar uma resposta ainda parece quebrado. Renderize a mudança de estado imediata primeiro e depois adie o trabalho de acompanhamento não crítico.

Diagnostique o INP com o modelo de latência de três partes

Toda interação lenta tem três lugares para investigar:

1. Atraso de entrada: o evento esperou porque o trabalho anterior na thread principal ainda estava em execução. Audite tarefas longas e JavaScript de terceiros antes do manipulador começar.
2. Duração do processamento: o próprio manipulador de evento fez demais. Reduza o trabalho síncrono, divida loops e adie qualquer coisa que o próximo frame não precise.
3. Atraso de apresentação: estilo, layout ou pintura levaram muito tempo após o manipulador. Reduza a complexidade do DOM e evite forçar cálculos de layout repetidos.

Comece pela maior fase no trace. Regrave a mesma interação após cada mudança para que um handler mais rápido não esconda um novo gargalo de apresentação.

Prove que uma mudança de INP melhorou a interação

Teste de liberação do handler

Teste a executar: registre a interação alvo no painel Performance antes e depois de dividir ou liberar trabalho longo. Resultado esperado: o tempo de processamento da interação diminui ou é dividido por uma pintura. Interpretação de falha: o trabalho caro está em outro lugar ou ainda é executado de forma síncrona. Janela de monitoramento: imediata em traces repetidos. Gatilho de reversão: o controle atualiza fora de ordem, perde estado ou gera novos erros de entrada.

Teste de apresentação

Teste a executar: inspecione o trabalho de estilo, layout e pintura do mesmo trace após o handler de evento. Resultado esperado: a próxima pintura chega mais cedo sem uma tarefa de layout maior. Interpretação de falha: o tamanho do DOM ou o layout forçado continua sendo o gargalo. Janela de monitoramento: imediata em traces de laboratório. Gatilho de reversão: a resposta visual fica incompleta ou instável.

Confirmação em campo

Teste a executar: compare a atribuição onINP() pós-lançamento para a interação e o template alterados com sua linha de base. Resultado esperado: o INP p75 melhora e o elemento alvo não domina mais os eventos lentos. Interpretação de falha: o caso de laboratório não representou dispositivos ou jornadas reais. Janela de monitoramento: RUM conforme as visitas chegam; CrUX em sua janela móvel de 28 dias. Gatilho de reversão: a responsividade ou a conclusão da interação piora consistentemente após a implantação.

Métricas de INP que valem a pena acompanhar

INP de usuários reais no p75

Métrica: o INP do 75º percentil por template e classe de dispositivo. O que indica: se visitas reais típicas são responsivas ao longo de toda a jornada. Como obter: CrUX, PageSpeed Insights ou RUM com web-vitals. Referência / faixa realista: 200 ms ou menos é bom; acima de 500 ms é ruim. Cadência: monitore após lançamentos de JavaScript e revise a tendência de campo móvel mensalmente.

Taxa de interações lentas

Métrica: a parcela de interações medidas acima de 200 ms, agrupadas por alvo. O que indica: quais controles criam o maior atraso visível ao usuário, mesmo quando o p75 da página passa. Como obter: a build de atribuição do web-vitals ou dados de Event Timing no RUM. Referência / faixa realista: estabeleça uma linha de base por jornada e reduza os maiores causadores de volume. Cadência: semanal para templates com comportamento de aplicativo.

Parcela das fases de latência

Métrica: atraso de entrada, duração do processamento e atraso de apresentação para interações lentas. O que indica: se o agendamento, o código do handler ou a renderização é a principal restrição. Como obter: traces do DevTools e atribuição de INP. Referência / faixa realista: não há divisão universal saudável; compare cada fase com sua própria linha de base e com o limite bom de 200 ms no total. Cadência: durante toda investigação de desempenho focada.

Recursos que valem seu tempo

Google / Chrome (o cânone)

• Interaction to Next Paint (INP) — comece aqui.
• Optimize Interaction to Next Paint — as correções.
• Optimize long tasks — liberação, scheduler.yield().
• Find slow interactions in the field — depuração com LoAF + atribuição.
• INP becomes a Core Web Vital — o lançamento de 12 de março de 2024.

Dados

• Web Almanac 2024 — Performance — os números reais de taxa de aprovação de INP e as medianas de subpartes.

Do setor

• INP — MDN Web Docs — entrada de referência da MDN; útil para verificar o suporte dos navegadores e a definição da métrica fora da documentação do Google.
• Scheduler API: scheduler.yield() — MDN — tabela de suporte dos navegadores e detalhes da especificação para a principal primitiva de yield.
• PerformanceEventTiming — MDN — a API de navegador subjacente que o INP lê; útil ao investigar dados brutos de tempo de eventos.
• Long Animation Frames API — Chrome Platform Status — acompanhamento do suporte do LoAF nos navegadores, a API que alimenta a atribuição de INP na biblioteca web-vitals.
• Tópico INP — Search Engine Land — cobertura de notícias do setor sobre atualizações do INP, resultados de testes e a transição de FID para INP por profissionais.

Estatísticas que valem citar

• ~74% mobile vs ~97% desktop passam no INP (2024). O mobile é dramaticamente mais difícil — e, como o Google indexa com prioridade para mobile, é esse o número que importa para SEO. Web Almanac 2024
• Apenas ~53% dos 1 000 maiores sites passam no INP — sites ricos em recursos enviam mais JavaScript que bloqueia a thread principal, então os maiores sites geralmente vão pior. Web Almanac 2024
• Tarefa longa = > 50 ms. Qualquer coisa acima de 50 ms na thread principal bloqueia o navegador de responder a interações — o mecanismo direto por trás de um INP ruim. web.dev — Otimize tarefas longas
• Medianas de subpartes (2024): o atraso de apresentação de ~36 ms costuma ser o maior contribuinte individual na mediana, com atraso de entrada e tempo de processamento logo atrás no p75 — útil para saber qual terço atacar. Web Almanac 2024

Vídeos

• Google Chrome Developers (YouTube) — os explicadores de Core Web Vitals e INP da equipe do Chrome, incluindo tutoriais de diagnóstico de interações lentas no DevTools. Canal

Teste-se: Interaction to Next Paint

Cinco perguntas rápidas sobre responsividade e diagnóstico de INP. Escolha uma resposta para cada uma e depois confira.

Registro de alterações