INP alto no WordPress: como corrigir o Core Web Vital

Tipo Performance & Velocidade

Nome do erro INP alto (Interaction to Next Paint) EN: High INP (Interaction to Next Paint)

Severidade Grave

Descrição INP alto no WordPress é quando o Interaction to Next Paint, a métrica que mede o tempo entre o usuário interagir (clicar, tocar, digitar) e a página atualizar visualmente, passa de 200ms. Costuma vir de JavaScript pesado na thread principal, handlers de evento lentos e scripts de terceiros que travam a resposta às interações.

O que é o INP alto no WordPress?

O INP alto no WordPress é uma falha de Core Web Vitals que mede a responsividade da página a interações reais. O Interaction to Next Paint observa todos os cliques, toques e digitações durante a visita e reporta o pior tempo de resposta significativo, do momento da interação até o próximo quadro pintado na tela. A meta do Google é INP abaixo de 200 milissegundos; entre 200ms e 500ms é “precisa melhorar” e acima de 500ms é “ruim”. Diferente do LCP, que é sobre carregamento, o INP é sobre toda a vida da página, e quase sempre piora quando há JavaScript demais ocupando a thread principal e impedindo o navegador de responder rápido.

Como identificar

O relatório de Core Web Vitals do PageSpeed Insights marca o INP acima de 200ms nos dados de campo.
O Search Console acusa URLs com “INP maior que 200 ms” no relatório de Core Web Vitals.
Cliques em menus, botões e abas demoram visivelmente a responder, com sensação de travamento.
Campos de formulário e filtros reagem com atraso ao digitar ou selecionar, parecendo “presos”.

Como prevenir

Mantenha o JavaScript na thread principal enxuto e adie ou carregue sob demanda scripts de terceiros
Escreva handlers de evento leves, adiando trabalho não urgente para depois da pintura da resposta
Monitore o INP no Search Console com regularidade para pegar regressões após mudanças de tema ou plugins

Causa

JavaScript pesado executando na thread principal e gerando tarefas longas que atrasam a resposta a cada interação.
Handlers de evento (clique, input) lentos, que rodam muito código de forma síncrona antes de a tela atualizar.
Scripts de terceiros (chats, anúncios, tag managers) competindo pela thread principal durante a navegação.
Re-renderizações grandes e manipulações de DOM custosas disparadas a cada interação do usuário.
Bibliotecas e plugins que reexecutam trabalho pesado sem necessidade a cada evento, sem dividir as tarefas.

Como resolver

Encontre as interações lentas: no PageSpeed Insights e no painel Performance do navegador, identifique quais interações registram o pior INP e quais scripts as tornam lentas.
Reduza o JavaScript da thread principal: adie e remova scripts não essenciais para diminuir as tarefas longas; menos JavaScript competindo pela thread libera o navegador para responder às interações.
Quebre as tarefas longas: divida o trabalho pesado em pedaços menores, devolvendo o controle ao navegador entre eles, para que ele consiga pintar a resposta da interação sem esperar a tarefa inteira.
Otimize os handlers de evento: deixe os manipuladores de clique e input leves: adie o trabalho não urgente para depois da pintura e evite rodar lógica custosa de forma síncrona dentro do handler.
Controle os scripts de terceiros: carregue chats, anúncios e tag managers sob demanda ou mova-os para um web worker, tirando-os da disputa pela thread principal durante a navegação.
Meça nos dados de campo: depois das mudanças, acompanhe o INP no PageSpeed e no Search Console; por ser métrica de campo, ele só reflete a melhora após semanas de coleta de usuários reais.

JavaScript

// Handler de clique que responde JA e adia o trabalho pesado para depois da pintura
botao.addEventListener('click', function () {
  // 1) Feedback visual imediato -> melhora o INP percebido
  botao.classList.add('is-loading');

  // 2) Cede a thread para o navegador pintar, depois roda o trabalho custoso
  requestAnimationFrame(function () {
    setTimeout(function () {
      trabalhoPesado();              // calculo/rede/DOM grande
      botao.classList.remove('is-loading');
    }, 0);
  });
});

// Quebra uma tarefa longa em pedacos, devolvendo o controle ao navegador entre eles
async function processaEmLotes(itens) {
  for (let i = 0; i < itens.length; i++) {
    processaItem(itens[i]);
    if (i % 50 === 0) {
      await new Promise(function (r) { setTimeout(r, 0); }); // yield
    }
  }
}

Perguntas frequentes

Qual é o valor ideal de INP no WordPress?

A meta do Google é INP abaixo de 200 milissegundos com dados de campo. Entre 200ms e 500ms o status é "precisa melhorar" e acima de 500ms é considerado ruim, indicando que a página demora a responder às interações do usuário.

Qual a diferença entre INP e o antigo FID?

O INP substituiu o FID como Core Web Vital de responsividade. O FID media só o atraso da primeira interação; o INP avalia todas as interações da visita e reporta o pior tempo significativo, sendo uma medida bem mais completa da responsividade real.

O que mais causa INP alto no WordPress?

JavaScript demais na thread principal é a causa central. Tarefas longas, handlers de evento pesados e scripts de terceiros como chats e tag managers ocupam a thread e impedem o navegador de responder rápido a cliques, toques e digitação.

Qual a relação entre TBT e INP?

O TBT é uma métrica de laboratório do carregamento e o INP é de campo, ao longo de toda a visita. Reduzir o TBT (menos JavaScript bloqueando a thread) costuma ajudar o INP, mas o INP também sofre com handlers lentos durante a navegação, que o TBT não captura por completo.

Plugins de cache melhoram o INP?

Indiretamente. Cache acelera o carregamento, não a resposta às interações. O que ajuda o INP é a otimização de JavaScript (adiar, dividir tarefas, atrasar terceiros) que alguns plugins de performance oferecem, e não o cache de página em si.

Otimizei o site mas o INP no Search Console continua alto. Por quê?

Porque o INP é uma métrica de campo baseada em 28 dias de usuários reais e demora semanas para refletir as correções. Confira primeiro no laboratório e no painel Performance do navegador se as interações já respondem rápido, e aguarde os dados de campo atualizarem.

Grave

Como corrigir o conflito de otimização entre Perfmatters e WP Rocket

O conflito entre Perfmatters e WP Rocket ocorre quando a mesma otimização (Remove Unused CSS, Delay JavaScript ou combinar arquivos) fica ligada nos dois plugins ao mesmo tempo, processando o asset em duplicidade e quebrando layout ou scripts. A regra e: cada otimização mora em um plugin so.

Grave

Como corrigir o Delay JavaScript do WP Rocket que quebra funções do site

O WP Rocket Delay JavaScript adia a execução de scripts até a primeira interação do usuário. Quando atrasa um script essencial (slider, menu, formulário ou botão), esses elementos param de funcionar até alguém mexer na página. A correção é excluir o script específico do delay, sem desligar a otimização toda.

Grave

Como otimizar o wp_options para reduzir queries lentas no WordPress

O wp_options lento no WordPress acontece quando a tabela de opções carrega dados demais em autoload a cada requisição, pesando em todas as páginas. Costuma vir de autoload inchado, transients órfãos acumulados e lixo deixado por plugins desinstalados.

Atenção

Como corrigir o WP Rocket que não melhora o PageSpeed

Instalar o WP Rocket liga apenas o cache de página; as otimizacoes que mais pesam na nota do PageSpeed (Remove Unused CSS, Delay JavaScript Execution e LazyLoad) vem desligadas e precisam ser ativadas a mao. Parte das recomendacoes ainda depende da hospedagem ou de scripts de terceiros, fora do alcance do plugin.

Crítico

Como corrigir scripts essenciais do WooCommerce removidos pelo Perfmatters

Scripts do WooCommerce removidos pelo Perfmatters acontecem quando o Script Manager desativa assets como wc-cart-fragments, woocommerce e wc-checkout marcados como Everywhere, em vez de Current URL. Sem esses arquivos, o carrinho Ajax para de atualizar e o checkout fica sem o JavaScript que processa o pedido.

Atenção

Como corrigir a lentidão do Astra Pro com muitas fontes personalizadas no WordPress

A queda de performance do Astra Pro com muitas fontes personalizadas ocorre quando o tema carrega várias famílias e pesos de Google Fonts de servidores externos, somando requisições que bloqueiam a renderização e atrasam o LCP da página.

Setores

Extensões

Integrações

Como corrigir INP alto (Interaction to Next Paint) no WordPress

O que é o INP alto no WordPress?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como corrigir o conflito de otimização entre Perfmatters e WP Rocket

Como corrigir o Delay JavaScript do WP Rocket que quebra funções do site

Como otimizar o wp_options para reduzir queries lentas no WordPress

Como corrigir o WP Rocket que não melhora o PageSpeed

Como corrigir scripts essenciais do WooCommerce removidos pelo Perfmatters

Como corrigir a lentidão do Astra Pro com muitas fontes personalizadas no WordPress

Setores

Extensões

Integrações

Extensões

Hero Sections

Seções de CTA

Login

Blog

Cabeçalhos

Seções de FAQ

Cadastro

Blog individual

Rodapés

Seções de contato

Seções de preços

Faixas

Portfólio

Seções de equipe

Números

Logotipos