Encontre e Corrija Problemas de Interaction to Next Paint (INP): Um Guia Passo a Passo
Aprenda como identificar e corrigir problemas de Interaction to Next Paint usando dados de RUM, Chrome DevTools e a API LoAF
Encontre e Corrija Problemas de Interaction to Next Paint (INP)
Esta página faz parte da nossa série sobre Interaction to Next Paint (INP). O INP mede a responsividade do seu site rastreando o atraso entre a interação do usuário e a próxima atualização visual. Uma boa pontuação de INP é inferior a 200 milissegundos, enquanto pontuações acima de 500 milissegundos são classificadas como ruins. Se você é novo no INP, comece pela página central do INP para uma visão geral completa.
De acordo com o Web Almanac de 2025, 23% das origens mobile ainda falham no INP. Se o seu site é um deles, aqui está o processo: confirme o problema no Search Console, diagnostique as causas raízes com dados de Real User Monitoring (RUM), replique localmente e aplique correções direcionadas a cada fase do INP.
DICA DE INP: na maioria das vezes, o INP será muito pior
quando um usuário interagir com a página durante a fase inicial do
carregamento da página. É por isso que, ao depurar o INP,
faz sentido registrar todas as interações, bem como o estado de carregamento da página!
Table of Contents!
Passo 1: Verifique o INP no Search Console
O primeiro passo é confirmar se você realmente tem um problema de INP. Antes de fazer qualquer alteração no código, verifique o problema no Google Search Console para garantir que você está trabalhando com dados de campo reais em vez de suposições.
Faça login no seu Google Search Console. No menu esquerdo, clique em Core Web Vitals e selecione Mobile ou Desktop (dica: na maioria das vezes, problemas de INP surgem primeiro no mobile, então comece por ele).
Aqui você verá uma visão geral de todos os problemas relacionados ao Core Web Vitals que estão atualmente no seu site. Se um desses problemas estiver relacionado ao INP, você confirmou que há um problema.
Passo 2: Identifique problemas de Interaction to Next Paint
O Google Search Console não fornece nenhuma informação além de grupos de URLs para descobrir o que está causando os problemas com o Interaction to Next Paint. Por isso, na maioria das vezes, os desenvolvedores agem às cegas. Eles começam removendo JavaScript não utilizado (sempre uma ótima ideia) e dividindo a thread principal (também uma ótima ideia), mas isso quase nunca corrige o INP completamente.
É por isso que, ao melhorar o INP, precisamos saber exatamente o que está acontecendo. Precisamos de respostas para quatro perguntas críticas:
Quais elementos, quando interagidos, causam uma pontuação ruim de INP?
Geralmente, uma pontuação ruim de INP não é causada por um único elemento, mas por uma combinação de problemas. Precisamos
enfrentá-los um a um, começando pelos piores e avançando progressivamente.
Quando essas interações acontecem? Elas acontecem
durante a fase inicial do
carregamento da página, ou acontecem mesmo quando a página principal já carregou totalmente?
Onde essas
interações acontecem? Elas acontecem em todas as páginas, ou acontecem
apenas em algumas páginas selecionadas?
Como podemos replicar
essas interações? Você já deve ter percebido que
é difícil replicar problemas de INP. É por isso que precisamos nos preparar para o sucesso
simulando as características do dispositivo com uma pontuação ruim de INP.
Configure o rastreamento RUM
Para responder a todas essas perguntas, precisamos começar a rastrear usuários reais e registrar quaisquer problemas que
possam ocorrer com o Interaction to Next Paint. Existem várias maneiras de ativar o rastreamento RUM. A
primeira é usando a biblioteca Web Vitals e enviando os resultados para o seu próprio backend de analytics.
A vantagem desse método é que ele é barato e flexível. A desvantagem é que pode dar muito
trabalho extra.
Uma boa alternativa ao envio dos seus dados de Core Web Vitals para o seu próprio backend é usar uma das muitas ferramentas de RUM disponíveis no mercado. Desenvolvemos o CoreDash justamente para esses casos de uso. O CoreDash é uma ferramenta de RUM de baixo custo, rápida e eficaz que resolve o problema. É claro que existem muitas soluções de RUM disponíveis e elas também farão o trabalho (embora por um preço mais alto).
Encontre interações lentas por elemento que causam um INP alto
Comece encontrando as interações mais lentas que causam as piores pontuações de INP. Liste suas páginas por "Métrica de INP por Elementos" no CoreDash e você obterá suas interações mais lentas. Clique na primeira linha para filtrar suas métricas por essas interações.
Descubra quando ocorrem interações de INP ruins
Em seguida, classifique os URLs filtrados por estado de carregamento. Isso fornecerá mais informações sobre a causa raiz do INP. Neste caso, o INP alto ocorre quando o conteúdo do DOM foi carregado. Isso significa que os scripts foram analisados, mas os scripts async e os sub-recursos da página ainda não foram carregados. Neste caso, o INP é causado por cliques precoces quando o carregamento da página não foi totalmente concluído.
Continue clicando no estado de carregamento com o maior impacto para criar outro filtro.
Encontre URLs responsáveis por altas pontuações de INP
Por fim, quando tivermos filtrado os elementos com a interação mais lenta e o estado de carregamento correto, vamos dar uma olhada nos URLs onde o INP é pior. Neste caso, isso claramente acontece em um conjunto específico de páginas.
Descubra as características do dispositivo
Quando tivermos identificado interações lentas, estado de carregamento e URLs que causam um alto Interaction to Next Paint, vamos dar uma olhada em quais tipos de visitantes causam as piores pontuações de INP. Nós verificaríamos a Memória do Dispositivo, Largura de Banda, Tamanho da tela e outras características de hardware. Depois de identificarmos essas características, podemos passar a replicar e registrar o problema.
Usando a API Long Animation Frames (LoAF) para diagnósticos de INP
A API Long Animation Frames (LoAF) informa exatamente quais scripts e funções causam interações lentas. Ao contrário da antiga API Long Tasks, a LoAF fornece URLs de scripts, nomes de funções e detalhamentos de tempo por quadro. Ela é especialmente útil quando combinada com dados de RUM de uma ferramenta como o CoreDash.
Este observer coleta entradas LoAF para quadros com duração superior a 50ms, capturando a atribuição do script, duração e tempo de bloqueio:
// Observe Long Animation Frames for INP attribution
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Only log frames longer than 50ms
if (entry.duration > 50) {
console.log('Long Animation Frame:', {
duration: entry.duration,
blockingDuration: entry.blockingDuration,
renderStart: entry.renderStart,
styleAndLayoutStart: entry.styleAndLayoutStart,
scripts: entry.scripts.map(script => ({
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
invokerType: script.invokerType,
invoker: script.invoker,
duration: script.duration
}))
});
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
A API LoAF revela quais scripts contribuem para cada fase do INP. O array scripts informa o arquivo de origem exato e o nome da função, enquanto renderStart e styleAndLayoutStart ajudam a separar o tempo de processamento do atraso de apresentação. Atualmente, a LoAF é exclusiva do Chromium (Chrome 123+), portanto, para depuração no Firefox e Safari, dependa do rastreamento do painel de Performance e dos dados de RUM. Para saber mais sobre como o carregamento async vs defer de JavaScript afeta esses tempos, consulte nosso guia dedicado.
Passo 3: Replique e depure interações que causam uma pontuação alta de INP
Com esses dados em mãos, podemos começar a corrigir as causas raízes.
Prepare-se para o sucesso: replique as circunstâncias de falha do INP
A próxima coisa que devemos fazer é tentar recriar a falha do INP. Fazemos isso simulando as circunstâncias em que o INP pode estar falhando.
Use o painel de Performance do Chrome: Abra o Chrome DevTools (Ctrl+Shift+I) e selecione o
painel de performance. Na barra superior, você pode selecionar o CPU Throttle (reduza a velocidade em 4x para
emular um dispositivo mobile normal), o Network Throttle (selecione a predefinição fast 3G para simular o seu
dispositivo mobile médio), e defina a simultaneidade de hardware (hardware concurrency) para 4 ou 8 para simular o seu dispositivo mobile médio.
Para carregar o Chrome com menos memória disponível (embora diminuir as configurações de rede e CPU muitas vezes resolva o problema), inicie o Chrome em um contêiner Docker e aloque menos memória.
Recarregue a página, interaja e verifique o INP com o visualizador de Core Web Vitals
Agora simule as condições e confirme se as pontuações de INP correspondem ao que seus dados de RUM relataram.
Recarregue a página e clique no elemento certo no momento certo
Depure o INP com um rastreamento de performance
Este é o momento para o qual você esteve se preparando nos passos anteriores. É hora de descobrir por que uma determinada interação está causando a pontuação ruim de Interaction to Next Paint.
Abra o Chrome DevTools (Ctrl+Shift+I), navegue até o painel de Performance e desta vez clique no ícone de Seta Circular para recarregar a página e começar a gravar (ou use o atalho Ctrl+Shift+E). Enquanto a gravação estiver em andamento, interaja com o elemento que causa o INP ruim. Após alguns segundos, pare a gravação e examine a linha do tempo. Procure o evento de interação na trilha "Interactions", e então inspecione as tarefas correspondentes na trilha "Main" para ver exatamente qual código está sendo executado durante cada fase.
Lendo o rastreamento de performance
No painel de Performance do Chrome, a interação aparecerá como uma barra colorida na trilha "Interactions". Clique nela para ver a duração total do INP e o seu detalhamento. Abaixo, na trilha "Main", você pode ver as tarefas individuais que foram executadas durante a interação. Preste atenção a:
- Tarefas antes do event handler: estas contribuem para o input delay
- O event handler em si: este é o tempo de processamento
- Trabalho de renderização após a conclusão do handler: este é o atraso de apresentação
Compare essas descobertas com os seus dados LoAF para confirmar se os scripts identificados no rastreamento correspondem aos dados de atribuição da sua ferramenta de RUM. Este também é um bom momento para verificar se há manipuladores de rolagem (scroll handlers) em JavaScript contribuindo para o problema.
Passo 4: Corrija problemas de INP
Você sabe qual interação está lenta e o porquê. É hora de consertar. O Interaction to Next Paint pode ser dividido em 3 fases: atraso de entrada, tempo de processamento, e atraso de apresentação.
Cada fase precisa de uma abordagem diferente. Aqui está um resumo. Siga os links para guias completos de otimização.
Minimize o Atraso de Entrada (Input Delay):
O atraso de entrada é o tempo entre a interação com a página e o momento em que o callback do evento começa a ser executado. Embora algum atraso de entrada seja inevitável (os navegadores precisam de tempo para agendar os callbacks), você pode minimizá-lo:
- Evite tarefas longas. Sempre que uma tarefa é executada, ela bloqueia a thread principal e deixa os callbacks de eventos em espera. Isso é especialmente importante ao otimizar cliques precoces (já que a maioria dos scripts estará em execução nesse momento). Para estratégias de redução do bloqueio por JavaScript, consulte nosso guia sobre async vs defer JavaScript.
- Tenha cuidado ao criar novas tarefas. Por exemplo, tarefas recorrentes via
setTimeout()ou tarefas que provavelmente ocorrerão antes do evento de INP, como callbacks no eventomouseover. - Meça e avalie as interações precoces. Quando um elemento interativo é apresentado cedo (por exemplo, um elemento de busca no site) e é controlado por JavaScript que carrega mais tarde, qualquer interação com o elemento não acionará uma atualização de layout imediata. Você deve priorizar a funcionalidade ou ocultar/desabilitar o elemento antes que ele esteja funcionando adequadamente.
- Use web workers para executar o JavaScript fora da thread principal do navegador. Web workers permitem que os scripts sejam executados fora da thread principal. Isso evitará o bloqueio da thread principal e os problemas de atraso de entrada do INP.
- Carregue scripts de terceiros não essenciais durante o tempo ocioso do navegador. Alguns scripts são mais críticos do que outros. Faz sentido priorizar esses scripts e carregar scripts menos importantes durante o tempo ocioso do navegador. Por exemplo, um script de chat. Consulte nosso guia sobre 14 métodos para adiar o JavaScript para técnicas práticas.
Minimize o Tempo de Processamento
- Remova códigos desnecessários. Código desnecessário é código antigo que ainda é executado ou código novo que não é necessário nesta página específica, mas ainda consome tempo de CPU. Esta é, de longe, a maneira mais fácil de melhorar imediatamente o INP.
- Adie o código que não precisa ser executado antes da próxima pintura. Divida o código em código crítico que deve ser executado antes do INP e código não crítico (por exemplo, envio de analytics) e agende-o após o evento de pintura com o método
requestIdleCallback(). - Otimize o código que deve ser executado antes da pintura. Verifique seu código e reescreva as partes lentas ou ineficazes.
- Forneça feedback imediato. Em tarefas complicadas ou possivelmente lentas, forneça feedback imediato antes de executar o código principal.
Minimize o Atraso de Apresentação
- Mantenha o DOM pequeno e simples. Será muito mais fácil para um navegador renderizar uma página com poucos elementos do DOM simples e não aninhados (nós HTML) do que renderizar uma página com muitos nós DOM aninhados. Leia mais sobre como corrigir o tamanho excessivo do DOM.
- Use content-visibility para a renderização tardia (lazy-render) do conteúdo fora da tela. A propriedade content-visibility acelerará a renderização das partes visíveis da página, atrasando a renderização do conteúdo fora da tela e renderizando esse conteúdo apenas no momento necessário.
Correção rápida: faça o yield para a thread principal com scheduler.yield()
Fazer o yielding para a thread principal entre trabalhos críticos e não críticos melhora todas as três fases do INP de uma só vez. A API scheduler.yield() fornece uma maneira limpa de fazer isso. Aqui está uma função auxiliar reutilizável com um fallback para navegadores que ainda não suportam a API:
async function yieldToMain() {
if ('scheduler' in window && 'yield' in window.scheduler) {
return await window.scheduler.yield();
}
return new Promise((resolve) => {
setTimeout(resolve, 0);
});
}
// Usage in an event handler
async function handleButtonClick() {
// Critical work: update the UI
updateVisualFeedback();
// Yield to let the browser paint
await yieldToMain();
// Non-critical work: analytics, logging
sendAnalyticsEvent('button_click');
logInteraction();
}
Cada fase do INP em detalhes
Cada fase tem suas próprias estratégias de otimização:
- Atraso de Entrada: Aprenda como minimizar o tempo entre a interação do usuário e o início do processamento do evento. O atraso de entrada é tipicamente a menor das três fases, mas sofre picos durante a inicialização da página quando a thread principal está ocupada com a execução de scripts.
- </b>Tempo de Processamento: Otimize o código do event handler que é executado durante a interação. Na maioria das páginas, é aqui que a maior parte do seu esforço de otimização compensa.
- Atraso de Apresentação: Reduza o trabalho de renderização e pintura que se segue ao processamento do evento. Em páginas complexas com DOMs grandes, esta é frequentemente a fase mais longa.
Para estratégias adicionais que abrangem todas as três fases, consulte nossos guias sobre como melhorar o INP abandonando a rolagem por JavaScript e como escolher entre async vs defer para o seu JavaScript.
Find out what is actually slow.
I map your critical rendering path using real field data. You get a clear answer on what blocks LCP, what causes INP spikes, and where layout shifts originate.
Book a Deep Dive
