Otimização de interaction to next paint (INP): O novo rei do SEO em 2026

Em 2026, a definição de um site rápido já não se limita à velocidade com que surge a primeira imagem. Hoje, a velocidade também se mede pela capacidade de resposta.

Quando um utilizador clica num botão do seu site WordPress, a reação é imediata ou há um pequeno soluço percetível? Esse intervalo, o tempo entre a ação do utilizador e a resposta visual do browser, é o que o Interaction to Next Paint (INP) mede. O INP é uma das três Core Web Vitals, e a documentação do Google Search afirma que as Core Web Vitals são utilizadas pelos seus sistemas de classificação. A mesma documentação acrescenta que não existe um sinal único de experiência de página e que a relevância vem primeiro, pelo que o INP funciona como critério de desempate entre páginas úteis e não como atalho para as ultrapassar. A razão mais forte para o corrigir é o visitante: um menu lento ou um botão Adicionar ao carrinho que congela sente-se em cada visualização de página.

Este guia, complementar ao nosso guia de Core Web Vitals 2026, explica como o INP é calculado, o que atrasa cada fase de uma interação num site WordPress típico, como encontrar o script responsável com os Long Animation Frames e que APIs do WordPress ajudam.

#O que é o INP e quando substituiu o FID

O INP passou a ser uma Core Web Vital estável a 12 de março de 2024, substituindo o First Input Delay (FID). O artigo de lançamento no web.dev deu aos programadores até 9 de setembro de 2024 para migrarem qualquer código que lesse o FID das APIs do CrUX ou do PageSpeed Insights; depois dessa data, a disponibilidade do FID deixou de estar garantida. O PageSpeed Insights avalia agora o INP em vez do FID na sua análise de Core Web Vitals.

A diferença entre as duas métricas está no âmbito. O FID media apenas o atraso de entrada da primeira interação numa página. O INP observa a latência completa (atraso de entrada, processamento e apresentação) de cada clique, toque e tecla premida durante toda a visita, por isso uma página que carrega bem mas engasga na terceira interação já não passa.

#Como se calcula o INP

A definição de INP no web.dev estabelece três intervalos, avaliados no percentil 75 dos carregamentos de página e separados entre dispositivos móveis e desktop:

Em cada visualização de página, o browser regista a latência de todas as interações observadas. O INP reportado é a mais longa, com uma regra para páginas muito movimentadas: por cada 50 interações, ignora-se a mais alta. A maioria das visualizações tem menos de 50 interações, pelo que, na prática, a pior interação costuma tornar-se o INP dessa visita. Se recolher o INP por conta própria em JavaScript, o web.dev sugere usar o percentil 98 das interações no momento em que a página é descarregada, o que aproxima a mesma regra.

Só contam cliques de rato, toques no ecrã tátil e teclas premidas. Passar o cursor por cima, fazer scroll e fazer zoom não são observados, embora um clique ou uma tecla premida dentro desses gestos possa ser. Isto tem uma consequência prática: uma página pode não ter qualquer valor de INP. Acontece quando o visitante nunca clica, toca ou escreve, quando apenas faz scroll, ou quando a visita vem de um bot, como um crawler de pesquisa que não foi programado para interagir. Um artigo de blog em que a maioria dos leitores apenas faz scroll terá muitas vezes menos dados de INP do que uma página de produto com seletor de variantes.

#Quais são as três fases do INP

Cada interação medida pelo INP é a soma de três partes, conforme descrito no guia do web.dev sobre otimização do INP:

1. Atraso de entrada (input delay): desde o momento em que o utilizador inicia a interação até começar a correr o primeiro callback de um event handler. Aumenta quando a main thread está ocupada com outra coisa, como um script a ser analisado, um temporizador a disparar ou uma interação anterior ainda a ser tratada.
2. Duração do processamento (processing duration): o tempo que demoram a correr todos os callbacks dos event handlers dessa interação.
3. Atraso de apresentação (presentation delay): desde o fim dos callbacks até o browser pintar o frame seguinte, o que inclui o recálculo de estilos, o layout e a pintura.

Para obter a classificação Bom, cada interação, desde um clique num menu de navegação até uma tecla premida num campo de pesquisa, tem de ficar visualmente concluída em 200 ms ou menos. Corrigir uma interação lenta muitas vezes expõe a seguinte, por isso encare a otimização do INP como um ciclo iterativo e não como uma tarefa única.

#Como reduzir o input delay no WordPress

O atraso de entrada é normalmente causado por a main thread estar ocupada quando o utilizador tenta clicar. Em sites WordPress, as fontes mais comuns são a avaliação de scripts durante o carregamento (análise, compilação e execução do JavaScript de plugins e do tema) e scripts de terceiros que executam trabalho periódico sem ter em conta a interação do utilizador.

#Como ceder a main thread com scheduler.yield()

O artigo do web.dev sobre tarefas longas define uma tarefa longa como qualquer tarefa acima de 50 ms. A solução é dividir o trabalho longo de JavaScript em tarefas mais pequenas, para que o browser possa tratar uma interação entre elas. scheduler.yield() devolve uma promise que se resolve numa nova tarefa, e a sua continuação tem prioridade: o resto do seu trabalho é retomado antes de outras tarefas do mesmo tipo em fila, pelo que um script de terceiros não consegue intrometer-se entre os seus blocos.

O suporte conta aqui. scheduler.yield() está disponível no Chrome 129, no Edge 129 e no Firefox 142, e o Safari não o suporta. O web.dev recomenda um fallback para setTimeout(), que continua a ceder a thread, só que sem a continuação prioritária:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function processLargeList(items) {
  for (const item of items) {
    expensiveOperation(item);
    await yieldToMain();
  }
}

Tutoriais mais antigos condicionam a cedência a navigator.scheduling.isInputPending(). O web.dev já não recomenda essa API: pode devolver false logo a seguir a uma interação do utilizador, e a entrada não é a única razão para ceder, já que as animações e outras atualizações de renderização também precisam da main thread. Ceda independentemente de haver entrada pendente.

#Como remover JavaScript não utilizado no WordPress

Só deve carregar o JavaScript necessário para a vista atual. Se um utilizador está num artigo de blog, não há motivo para ter na página uma biblioteca de checkout. O carregamento condicional de recursos, por template ou por bloco, é a primeira coisa que verificamos numa auditoria de INP em WordPress, porque código que nunca carrega nunca pode bloquear uma interação. Mais detalhes no nosso guia de otimização da velocidade do WordPress.

#Como adiar scripts com a estratégia de carregamento do WordPress 6.3

O WordPress 6.3 acrescentou uma estratégia de carregamento a wp_register_script() e wp_enqueue_script(), documentada na nota do Make WordPress Core sobre async e defer. O quinto parâmetro aceita agora um array com duas chaves, strategy (defer ou async) e in_footer:

wp_enqueue_script(
  'wppoland-filters',
  get_theme_file_uri( 'assets/filters.js' ),
  array(),
  '1.4.2',
  array(
    'strategy'  => 'defer',
    'in_footer' => true,
  )
);

A estratégia é um pedido, não uma garantia. O WordPress verifica a árvore de dependências: um script adiado de que depende um script bloqueante passa também a ser bloqueante, para manter a ordem de execução. Um script inline adicionado na posição after também força o script pai a voltar a ser bloqueante, e essa alteração pode propagar-se pela árvore. Por isso, depois de mudar um tema ou plugin para defer, veja o código-fonte da página e confirme que o atributo está mesmo lá. A mesma nota recomenda substituir os antigos truques com o filtro script_loader_tag por esta API.

#Como reduzir o tempo de processamento do INP

É aqui que se testa a eficiência do seu próprio código. O conselho geral do web.dev é fazer o mínimo de trabalho possível nos callbacks de eventos.

#Como manter os event handlers leves

Evite lógica complexa dentro dos handlers de clique. Atualize a parte da interface de que o utilizador está à espera, depois ceda a thread e execute tudo o resto numa tarefa posterior. O exemplo do web.dev usa uma caixa de texto: o carácter escrito aparece de imediato, enquanto a contagem de palavras, a verificação ortográfica e a gravação são adiadas com requestAnimationFrame() e um setTimeout() lá dentro, de modo a correrem depois de o frame seguinte ser pintado.

button.addEventListener('click', () => {
  const price = calculatePrice(product, variant);
  priceElement.textContent = formatPrice(price);

  requestAnimationFrame(() => {
    setTimeout(() => {
      sendAnalytics('price_calculated', price);
      saveCartDraft(product, price);
    }, 0);
  });
});

A alteração visível acontece no handler, e a analítica e o armazenamento esperam até o frame com o novo preço ter sido pintado.

#Como evitar o layout thrashing

O layout thrashing, também chamado layout síncrono forçado, acontece quando o código altera estilos e depois lê uma propriedade de layout como offsetWidth na mesma tarefa. O browser tem de executar o layout de imediato em vez de o fazer uma vez no fim do frame, e num ciclo isso acontece em cada iteração. Leia primeiro todos os valores e só depois escreva:

// Força o layout em cada iteração: evitar
elements.forEach((el) => {
  const width = el.offsetWidth;
  el.style.width = width + 10 + 'px';
});

// Primeiro lê, depois escreve
const widths = elements.map((el) => el.offsetWidth);
elements.forEach((el, i) => {
  el.style.width = widths[i] + 10 + 'px';
});

#Como tirar os scripts de terceiros da main thread

Os scripts de terceiros não essenciais, como widgets de chat e tags de analítica, podem ser movidos para um Web Worker com uma biblioteca como o Partytown, deixando de competir com os event handlers na main thread. Não serve para todos os scripts, porque algumas tags precisam de acesso síncrono ao DOM. Analisamos os compromissos, incluindo as tags que deixam de funcionar num worker, no nosso guia sobre como reduzir o impacto de scripts de terceiros no WordPress.

#Como lidar com listas longas

Em páginas com listas longas, como arquivos de blog, páginas de categoria do WooCommerce ou tabelas de dados, renderizar centenas de itens logo de início faz com que cada interação posterior pague o preço de um DOM grande. A virtualização renderiza apenas os itens próximos da área visível e cria e remove elementos à medida que o utilizador faz scroll. A paginação ou os botões Carregar mais atingem o mesmo objetivo com menos JavaScript.

#Como corrigir o presentation delay

Mesmo que o seu código termine depressa, o browser pode ainda ter dificuldade em pintar o resultado quando o DOM é grande ou os estilos são caros de recalcular.

#Como o tamanho do DOM afeta o INP

O web.dev observa que o trabalho de renderização cresce com o tamanho do DOM, embora não de forma linear, e que um DOM grande torna mais lenta tanto a primeira renderização como a renderização após cada interação. Há duas opções: achatar o DOM, o que no WordPress significa normalmente menos elementos de envolvimento gerados pelo tema ou pelo page builder, e adicionar nós apenas quando uma interação precisa deles, em vez de renderizar logo de início todos os separadores, modais e mega menus.

#Como usar content-visibility e contain

content-visibility: auto permite ao browser saltar o layout e a pintura de um elemento até este se aproximar da área visível. Segundo o artigo do web.dev sobre content-visibility, a demo de um blog de viagens reduziu o tempo de renderização inicial de 232 ms para 30 ms, e a propriedade tem o estatuto Baseline newly available desde 15 de setembro de 2025 (Chrome 85, Firefox 125, Safari 18). Combine-a com contain-intrinsic-size para que as secções saltadas mantenham uma altura de reserva; a palavra-chave auto faz o browser memorizar o último tamanho renderizado:

.comments-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 2000px;
}

.sidebar {
  contain: layout style paint;
}

A propriedade contain em secções independentes, como uma barra lateral ou um bloco de comentários, indica ao browser que uma alteração no seu interior não afeta o resto da página, o que limita a parte da página que tem de ser recalculada antes da pintura seguinte.

#Porque é que a renderização de HTML no cliente agrava o presentation delay

Quando o HTML chega do servidor em streaming, o browser analisa-o em blocos e cede a thread entre eles. Quando um script constrói grandes quantidades de HTML no cliente, o browser não cede até esse HTML estar analisado e renderizado, o que pode atrasar o frame seguinte. No WordPress, isto aparece em filtros AJAX e em botões Carregar mais que injetam de uma só vez uma string de HTML enorme. Inserir lotes mais pequenos, com uma cedência entre eles, mantém curto o frame que se segue ao clique.

#O que causa um INP fraco no WordPress

Estes são os culpados que encontramos com mais frequência quando um site WordPress chumba no INP. Nenhum é exclusivo do WordPress, mas os plugins tornam fácil instalá-los sem dar por isso.

#Page builders pesados

O Divi e o Elementor acrescentam muitas vezes um aninhamento profundo do DOM, com vários elementos de envolvimento à volta de cada widget, o que torna mais lento o recálculo do layout após uma interação. Verifique a profundidade no painel Elements do DevTools antes e depois de substituir uma secção por blocos nativos.

#Widgets de chat

A maioria dos scripts de chat ao vivo consome muito da main thread, carrega e começa a trabalhar em todas as páginas. Um padrão de carregamento ao clique, em que um botão leve só carrega o widget real quando o utilizador pede ajuda, elimina esse trabalho nas páginas onde ninguém conversa.

#Sliders com rotação automática

As transições que disparam a cada poucos segundos podem coincidir com cliques do utilizador. Se o browser estiver a meio de uma transição do slider quando o utilizador toca num link do menu, a interação tem de esperar por esse trabalho, o que aparece como atraso de entrada.

#Scripts do WooCommerce fora da loja

Os cart fragments e outros scripts da loja podem acabar carregados em páginas sem qualquer funcionalidade de loja, como artigos de blog. Verifique que scripts do WooCommerce cada template coloca em fila e consulte o nosso guia de performance do WooCommerce para correções específicas de lojas.

#Google Maps incorporado

Um mapa do Google Maps incorporado carrega uma quantidade significativa de JavaScript e mantém event listeners ativos. Uma imagem estática que carrega o mapa interativo ao clique evita esse custo aos visitantes que nunca usam o mapa.

#Melhores ferramentas para medir o INP em 2026

Para corrigir o INP, precisa de dados de utilizadores reais e de uma forma de reproduzir a interação lenta em laboratório.

#API do CrUX e PageSpeed Insights

A documentação da API do CrUX descreve os dados como uma média móvel de 28 dias, atualizada diariamente por volta das 04:00 UTC e com cerca de dois dias de atraso face à data atual. Cada métrica vem com um histograma e um valor p75, e é possível filtrar por PHONE, DESKTOP ou TABLET. Só contribuem utilizadores do Chrome em desktop e Android que deram consentimento, por isso o Chrome em iOS e outros browsers Chromium, como o Edge, não estão nos dados. Páginas com pouco tráfego muitas vezes não têm registo próprio e recorrem aos dados da origem. O PageSpeed Insights e o relatório de Core Web Vitals da Search Console mostram os mesmos dados de campo.

#Como encontrar o script lento com os Long Animation Frames (LoAF)

A API Long Animation Frames chegou no Chrome 123. Reporta qualquer frame cuja atualização de renderização se atrasa para lá de 50 ms e, ao contrário da API Long Tasks, agrupa o trabalho por frame, o que corresponde à forma como o INP é sentido. A Long Tasks não vai desaparecer: a equipa do Chrome diz que não há planos para a descontinuar, mas o LoAF oferece uma atribuição muito melhor. Cada entrada traz duration, blockingDuration, renderStart, styleAndLayoutStart e um array scripts. Os scripts com mais de 5 ms recebem atribuição com sourceURL, sourceFunctionName, invokerType e forcedStyleAndLayoutDuration, o que muitas vezes basta para identificar o plugin responsável.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('LoAF', entry.duration, entry.blockingDuration,
      entry.scripts.map((s) => ({
        sourceURL: s.sourceURL,
        sourceFunctionName: s.sourceFunctionName,
        duration: s.duration,
        forcedLayout: s.forcedStyleAndLayoutDuration,
      })));
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

O LoAF é suportado no Chrome e no Edge. O Firefox e o Safari não o expõem, por isso os dados de atribuição da monitorização de campo virão apenas de browsers Chromium.

#Dados de campo com a versão de atribuição do web-vitals

A biblioteca web-vitals tem uma versão de atribuição que indica porque é que uma interação foi lenta. O guia do web.dev para encontrar interações lentas no terreno enumera os campos: interactionTarget (um seletor CSS do elemento), interactionType, inputDelay, processingDuration, presentationDelay e, desde a versão 4, longAnimationFrameEntries. Envie-os para o seu endpoint de analítica com sendBeacon:

import { onINP } from 'web-vitals/attribution';

onINP(({ value, rating, attribution }) => {
  navigator.sendBeacon('/analytics', JSON.stringify({
    value,
    rating,
    target: attribution.interactionTarget,
    inputDelay: attribution.inputDelay,
    processingDuration: attribution.processingDuration,
    presentationDelay: attribution.presentationDelay,
  }));
});

A divisão por fases indica onde procurar: um atraso de entrada grande aponta para trabalho que corre antes do clique, uma duração de processamento grande aponta para os seus handlers, e um atraso de apresentação grande aponta para o tamanho do DOM e a renderização.

#Extensão Web Vitals e DevTools

A extensão Web Vitals e o painel Performance do Chrome DevTools mostram o INP de cada interação à medida que a executa. Clique em cada botão, link e campo de formulário dos seus templates principais e observe os valores. Os testes de laboratório num portátil rápido subestimam a latência em dispositivos móveis, por isso use o throttling de CPU do DevTools quando reproduzir uma interação lenta reportada no terreno. As limitações específicas dos dispositivos móveis são tratadas no nosso guia de estratégias de performance mobile-first.

#Como melhorar o INP no WordPress passo a passo

#Passo 1: auditoria de base

Obtenha os dados do CrUX para a sua origem e para os templates principais (página inicial, artigo de blog, produto, categoria) e registe o INP separadamente para telemóveis e desktops. Comece pelos templates com o pior valor p75 e tráfego suficiente para fazer diferença.

#Passo 2: encontrar as interações lentas

Adicione ao site a versão de atribuição do web-vitals, ou use o observer de LoAF acima, e recolha o interactionTarget e a divisão por fases das interações lentas. Assim, a queixa de que o site parece lento transforma-se numa lista de elementos concretos.

#Passo 3: inventário de scripts

Liste todos os scripts carregados em cada template. Para cada um, anote se é necessário nesse template, se pode usar a estratégia defer, se pode carregar apenas na interação e se pode passar para um worker ou ser removido.

#Passo 4: dividir as tarefas longas

Nos scripts a que o LoAF atribui frames lentos, divida as tarefas longas com scheduler.yield() e o fallback setTimeout(), começando pelo trabalho que corre durante uma interação ou logo a seguir.

#Passo 5: reduzir o custo do DOM e da renderização

Achate as secções mais profundas, adicione content-visibility: auto às áreas longas abaixo da dobra e pondere substituir secções do page builder por blocos nativos do Gutenberg onde o DOM é mais profundo.

#Passo 6: monitorização contínua

Mantenha a monitorização de campo ativa depois das correções. O CrUX precisa de 28 dias para refletir totalmente uma alteração, por isso compare os seus próprios dados de campo semana a semana e configure um alerta para quando o INP p75 ultrapassar os 200 ms.

#Serviços de otimização de INP da WPPoland

Na WPPoland, especializamo-nos na métrica de performance centrada nas pessoas.

1. Refatorização de JavaScript: reescrevemos código de plugins inchado em alternativas leves que mantêm a funcionalidade sem o peso.
2. Diagnóstico LoAF: usamos telemetria de campo com atribuição LoAF para identificar com precisão o script e a função que causam o atraso.
3. Design de interatividade: garantimos que a resposta visível a um clique acontece primeiro e que tudo o resto espera até depois da pintura.

#Conclusão sobre a otimização do INP

As Core Web Vitals dizem respeito ao que o utilizador sente ao interagir com a sua marca. O Interaction to Next Paint é a métrica da confiança. Quando o seu site responde de imediato, os utilizadores sentem que têm o controlo. Quando atrasa, parece avariado, e num telemóvel um menu que não reage é muitas vezes tratado como avariado. Nenhum estudo publicado associa um intervalo de INP a uma percentagem fixa de rejeição ou de conversão, por isso meça os seus próprios valores antes e depois.

O seu site WordPress parece lento? Contacte a WPPoland para diagnosticar o seu INP e corrigir as interações que o estão a prejudicar.