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 uma 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 com a página central do INP para uma visão geral completa.
De acordo com o 2025 Web Almanac, 23% das origens móveis 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 interage com a página durante o estágio de inicialização 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 que 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, os problemas de INP surgem primeiro no mobile, então comece pelo mobile).
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 existe 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. Portanto, na maioria das vezes os desenvolvedores apenas entram às cegas. Eles começam a remover JavaScript não utilizado (sempre uma ótima ideia) e a fragmentar 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, ao interagir com eles, causam uma pontuação ruim de INP?
Normalmente, uma pontuação ruim de INP não é causada por um único elemento, mas por uma combinação de problemas. Precisamos
lidar com eles um por um, começando pelos piores e subindo.
Quando essas interações acontecem? Elas acontecem
durante a fase de inicialização 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 a essa altura que é
difícil replicar problemas de INP. É por isso que precisamos nos preparar para o sucesso,
imitando as características dos dispositivos com uma pontuação ruim de INP.
Configure o rastreamento de RUM
Para responder a todas essas perguntas, precisamos começar a rastrear usuários reais e registrar quaisquer problemas que
possam acontecer com o Interaction to Next Paint. Existem várias maneiras de ativar o rastreamento de 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 é barato e flexível. A desvantagem é que pode ser muito
trabalho extra.
Uma boa alternativa para enviar seus dados do Core Web Vitals para o seu próprio backend é usar uma das muitas ferramentas de RUM disponíveis no mercado. Nós desenvolvemos o CoreDash apenas para esses casos de uso. O CoreDash é uma ferramenta de RUM de baixo custo, rápida e eficaz que faz o trabalho. Claro, existem muitas soluções de RUM disponíveis e elas também farão o trabalho (por um preço mais alto, no entanto).
Encontre interações lentas por elemento que causam um alto INP
Comece encontrando as interações mais lentas que causam as piores pontuações de INP. Liste suas páginas por "INP metric by Elements" 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. Nesse caso, o INP alto ocorre quando o conteúdo do DOM foi carregado. Isso significa que os scripts foram analisados, mas scripts assíncronos 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 filtrarmos os elementos com a interação mais lenta e o estado de carregamento correto, vamos dar uma olhada nas URLs em que o INP está no seu pior. Neste caso, isso claramente acontece em um conjunto específico de páginas.
Encontre características do dispositivo
Quando identificarmos 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 prosseguir para 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 observador coleta entradas de LoAF para quadros com mais de 50ms, capturando a atribuição do script, a duração e o 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 e o nome da função exatos, enquanto renderStart e styleAndLayoutStart ajudam a separar o tempo de processamento do atraso de apresentação. A LoAF é atualmente exclusiva do Chromium (Chrome 123+), então, para depuração no Firefox e Safari, dependa do rastreamento do painel de Performance e dos dados de RUM. Para mais informações sobre como o carregamento async vs defer de JavaScript afeta esses tempos, veja 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 imitando as circunstâncias em que o INP pode estar falhando.
Use o Chrome Performance Panel: Abra as ferramentas de desenvolvedor do Chrome (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 móvel normal), o Network Throttle (selecione a predefinição 3G rápida para imitar o seu
dispositivo móvel médio) e defina a simultaneidade de hardware para 4 ou 8 para imitar o seu dispositivo móvel médio.
Para carregar o Chrome com menos memória disponível (embora diminuir a configuração 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 do Core Web Vitals
Agora simule as condições e confirme que 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 Developer Console (Ctrl+Shift+I), navegue até o painel Performance e desta vez clique no ícone de Seta Circular para recarregar a página e iniciar a gravação (ou use o atalho Ctrl+Shift+E). Enquanto a gravação estiver em execução, interaja com o elemento que causa o INP ruim. Após alguns segundos, pare a gravação e examine a linha do tempo. Procure pelo evento de interação na trilha "Interactions", depois 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 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 manipulador de eventos (event handler): estas contribuem para o input delay
- O manipulador de eventos (event handler) em si: este é o processing time
- Trabalho de renderização após a conclusão do manipulador: este é o presentation delay
Compare essas descobertas com seus dados de LoAF para confirmar que 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 em JavaScript contribuindo para o problema.
Passo 4: Corrija os problemas de INP
Você sabe qual interação é lenta e por quê. Hora de consertar. O Interaction to Next Paint pode ser dividido em 3 fases: input delay, processing time e presentation delay.
Cada fase precisa de uma abordagem diferente. Aqui está um resumo. Siga os links para guias completos de otimização.
Minimize o Input Delay:
O Input delay é o tempo entre a interação com a página e quando o callback do evento começa a ser executado. Embora algum input delay seja inevitável (os navegadores precisam de tempo para agendar os callbacks), você pode minimizá-lo:
- Evite tarefas longas (long tasks). Sempre que uma tarefa é executada, ela bloqueia a thread principal e deixa os callbacks de eventos esperando. Isso é especialmente importante ao otimizar cliques iniciais (já que a maioria dos scripts estará em execução nesse momento). Para estratégias de como reduzir o bloqueio do 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 INP, como callbacks no eventomouseover. - Meça e avalie a interação precoce. Quando um elemento interativo é apresentado precocemente (por exemplo, um elemento de pesquisa no site ) e é controlado por JavaScript que carrega depois, qualquer interação com o elemento não acionará uma atualização imediata do layout. Priorize a funcionalidade ou oculte/desabilite o elemento antes que ele esteja funcionando corretamente.
- 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 impedirá o bloqueio da thread principal, o que causa problemas de input delay no INP.
- Carregue scripts de terceiros não essenciais (nice-to-have) 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 Processing Time
- Remova o código desnecessário. O código desnecessário é um código mais antigo que ainda é executado ou um código novo que não é necessário nesta página específica, mas que ainda consome tempo de CPU. Esta é, de longe, a maneira mais fácil de melhorar imediatamente o INP.
- Adie (defer) 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, o envio de analytics) e agende-o para depois do 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 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 Presentation Delay
- Mantenha o DOM pequeno e simples. Será muito mais fácil para um navegador renderizar uma página com poucos e simples elementos DOM (nós HTML) não aninhados 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 renderizar tardiamente (lazy-render) o conteúdo fora da tela. A propriedade content-visibility acelerará a renderização de partes visíveis da página ao atrasar a renderização do conteúdo fora da tela e renderizando esse conteúdo fora da tela no momento exato (just in time).
Correção rápida: faça o yield para a thread principal com scheduler.yield()
Fazer o yield para a thread principal entre o trabalho crítico e o não crítico melhora 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 possui suas próprias estratégias de otimização:
- Input Delay: Aprenda a minimizar o tempo entre a interação do usuário e o início do processamento do evento. O input delay geralmente é a menor das três fases, mas atinge picos durante a inicialização da página quando a thread principal está ocupada com a execução de scripts.
- </b>Processing Time: Otimize o código do manipulador de eventos (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.
- Presentation Delay: Reduza o trabalho de renderização e pintura que se segue ao processamento de eventos. Em páginas complexas com DOMs grandes, esta é frequentemente a maior fase.
Para estratégias adicionais que abrangem as três fases, veja nossos guias sobre como melhorar o INP abandonando a rolagem em JavaScript e como escolher async vs defer para o seu JavaScript.
Dados em tempo real. Nada de média de 28 dias.
CoreDash segmenta cada métrica por rota, aparelho, browser e tipo de conexão.
Dá uma olhada no CoreDash
