Core Web Vitals 2026: Guia técnico de otimização INP para WordPress

#Compreender Core Web Vitals em 2026

#As três métricas que importam

#Porque INP é o mais difícil de corrigir

O LCP é essencialmente um problema de velocidade do servidor e otimização de imagens - questões bem conhecidas com soluções claras. O CLS trata-se de reservar espaço para conteúdo dinâmico - uma disciplina de CSS e HTML. O INP, por outro lado, diz respeito à eficiência de execução do JavaScript - um problema fundamentalmente mais complexo porque exige compreender a thread principal do navegador, o agendamento de tarefas é o tratamento de eventos.

Sites WordPress são particularmente vulneráveis a INP fraco pelas seguintes razões:

1. Excesso de plugins - cada plugin pode adicionar JavaScript que bloqueia a thread principal
2. Page builders - Elementor, Divi e WPBakery acrescentam frameworks pesados no frontend
3. Scripts de terceiros - analítica, publicidade, widgets de chat e embeds de redes sociais competem pelo tempo da thread principal
4. Dependência de jQuery - muitos temas e plugins WordPress ainda dependem de jQuery, acrescentando mais de 85KB de JavaScript bloqueante
5. Ausência de code splitting - os temas WordPress tradicionais carregam todo o JavaScript em todas as páginas

#Como INP funciona

#O ciclo de vida de uma interação

Quando um utilizador clica num botão, toca num link ou pressiona uma tecla, o navegador processa a interação em três fases:

1. Atraso de entrada (input delay) - tempo entre a interação física é o momento em que o navegador começa a executar o event handler. Este atraso é causado pela thread principal estar ocupada com outras tarefas
2. Tempo de processamento (processing time) - tempo necessário para executar todos os event handlers associados a essa interação
3. Atraso de apresentação (presentation delay) - tempo para renderizar a atualização visual no ecrã após a conclusão dos event handlers

A fórmula é simples:

INP = Atraso de entrada + Tempo de processamento + Atraso de apresentação

A métrica captura a pior interação (no percentil 98) durante toda a visita à página. Isto significa que uma única interação lenta pode destruir a pontuação INP, mesmo que todas as outras interações sejam rápidas. Num site WordPress típico com formulários, menus, filtros e carrosséis, há dezenas de interações possíveis - e basta uma correr mal.

#O que conta como interação

Nem todas as ações do utilizador são consideradas interações para efeitos de INP:

• Cliques em botões, links, toggles e menus - contam
• Toques em dispositivos móveis (eventos touch) - contam
• Pressionar teclas em campos de texto, caixas de pesquisa é atalhos de teclado - contam
• Scroll - não conta (o scroll é medido separadamente pelo navegador)
• Hover - não conta (passar o cursor por cima de um elemento não aciona INP)

Está distinção é importante: se o site tem problemas de scroll lento, isso não se reflete no INP. Mas se o utilizador clica num botão de filtro é o ecrã demora 400ms a atualizar, isso é um problema grave de INP.

#Medir INP em sites WordPress

#Google Search Console (dados de campo)

A fonte de dados mais importante para INP. Aceda a Core Web Vitals → Dispositivos Móveis/Computadores. O Search Consolé apresenta dados reais de utilizadores, agregados ao longo de 28 dias. As páginas são agrupadas por padrão de URL e classificadas como Bom, Precisa de melhorias ou Mau.

Comece sempre por aqui. Os dados de campo refletem a experiência real dos utilizadores, incluindo dispositivos lentos, ligações fracas e interações que os testes laboratoriais nunca simulam. Se o Search Console reporta INP fraco, o Google está efetivamente a ver esse problema - e pode afetar os rankings.

#PageSpeed Insights (laboratório + campo)

Introduza qualquer URL é obtenha dois tipos de dados:

• Dados de campo - medições reais de utilizadores provenientes do Chrome UX Report (CrUX). Estes são os dados que o Google utiliza para classificações
• Dados de laboratório - medições simuladas do Lighthouse, executadas num ambiente controlado

Para o INP, os dados de campo são significativamente mais relevantes. Os testes laboratoriais podem não acionar as mesmas interações que os utilizadores reais executam. Um site pode ter excelente INP em laboratório mas péssimo INP no campo, porque os utilizadores interagem com menus complexos, filtros de pesquisa e formulários que o Lighthouse não testa.

#Chrome DevTools (depuração)

Para diagnosticar problemas específicos de INP, o Chrome DevTools é indispensável. O processo é o seguinte:

1. Abra DevTools → separador Performance → clique em Record
2. Interaja com a página: clique em botões, abra menus, preencha formulários
3. Paré a gravação é análise o resultado

Procure especificamente:

• Tarefas longas (Long Tasks) - barras amarelas ou vermelhas que indicam tarefas com mais de 50ms. Qualquer tarefa acima deste limiar bloqueia a thread principal
• Event handlers - quanto tempo cada clique ou toque demora a ser processado. Se um clique desencadeia múltiplos handlers, o tempo acumula
• Layout thrashing - layouts síncronos forçados durante as interações. Isto acontece quando o JavaScript lê e escreve propriedades de layout alternadamente, obrigando o navegador a recalcular repetidamente

#Correções INP específicas para WordPress

#1. Adiar JavaScript não-crítico

A correção com maior impacto. A maioria dos plugins WordPress carrega JavaScript no <head>, bloqueando a thread principal antes mesmo de a página ser renderizada:

<!-- Antes: bloqueante -->
<script src="plugin-slider.js"></script>

<!-- Depois: adiado -->
<script src="plugin-slider.js" defer></script>

O atributo defer diz ao navegador para descarregar o ficheiro em paralelo mas executá-lo apenas depois de o HTML estar completamente analisado. Isto liberta a thread principal durante o carregamento inicial, reduzindo drasticamente o atraso de entrada.

Plugins que mais beneficiam de adiamento:

• Analítica (GA4, GTM) - adicionar defer ou carregar via requestIdleCallback
• Widgets de chat (Intercom, Tawk.to) - carregar após o utilizador fazer scroll ou após 5 segundos
• Embeds sociais (Facebook, Twitter/X) - carregar apenas quando visíveis (Intersection Observer)
• Sliders e carrosséis - adiar a inicialização até ficarem visíveis no viewport

#2. Remover JavaScript de plugins não utilizado

Muitos plugins carregam os seus scripts em todas as páginas do site, independentemente de serem necessários. É fundamental auditar quais plugins realmente precisam de JavaScript no frontend:

# Listar todos os scripts enfileirados numa página
wp eval 'global $wp_scripts; foreach($wp_scripts->queué as $s) echo $s . "\n";'

Este comando revela todos os scripts que o WordPress carrega. A partir dessa lista, identifique os que são desnecessários na página em questão.

Casos mais comuns:

• Contact Form 7 - carrega CSS e JavaScript em todas as páginas, mas os formulários existem apenas numa ou duas. Solução: carregar condicionalmente apenas nas páginas com formulário
• WooCommerce cart fragments - o AJAX de fragmentos do carrinho corre em todas as páginas, mesmo fora da loja. Solução: desativar em páginas que não sejam de loja
• Estilos de blocos Gutenberg - o WordPress carrega CSS e JavaScript para todos os blocos registados, mesmo os que não são utilizados na página. Solução: remover estilos de blocos não utilizados

O carregamento condicional pode ser feito no ficheiro functions.php do tema ou através de um plugin de gestão de assets como Asset CleanUp ou Perfmatters.

#3. Quebrar tarefas longas

Qualquer tarefa JavaScript com mais de 50ms bloqueia a thread principal. Durante esse período, o navegador não pode responder a interações do utilizador, o que aumenta diretamente o atraso de entrada (input delay) do INP. A solução é dividir tarefas longas em partes mais pequenas, cedendo o controlo ao navegador entre cada execução.

A API moderna scheduler.yield() é a abordagem recomendada, com setTimeout como alternativa para navegadores mais antigos:

// Dividir um ciclo longo em partes mais pequenas
async function processItems(items) {
  for (const item of items) {
    processItem(item);
    // Ceder controlo ao navegador entre itens
    if (navigator.scheduling?.isInputPending?.()) {
      await scheduler.yield();
    }
  }
}

O método isInputPending() verifica se há interações do utilizador à espera de ser processadas. Se houver, scheduler.yield() interrompé a execução da tarefa para que o navegador possa tratar a interação primeiro. Isto garante que o utilizador nunca fica à espera de uma tarefa de fundo terminar antes de ver uma resposta ao seu clique.

#4. Usar passive event listeners

Listeners de eventos de scroll e touch bloqueiam o navegador porque este precisa de saber se o handler vai chamar preventDefault() para cancelar o scroll. Ao marcar o listener como passivo, informamos o navegador de que o scroll não será cancelado, permitindo-lhe processar o scroll imediatamente:

// Antes: bloqueante
element.addEventListener('touchstart', handler);

// Depois: passivo (informa o navegador que o scroll não será cancelado)
element.addEventListener('touchstart', handler, { passive: true });

// Também aplicar a eventos de scroll
window.addEventListener('scroll', onScroll, { passive: true });

Está alteração é particularmente importante em dispositivos móveis, onde os eventos touch são frequentes. Muitos plugins WordPress adicionam listeners de scroll sem a opção passive, causando jank (interrupções visuais) é atrasos nas interações.

#5. Otimizar tamanho do DOM

Árvores DOM grandes (acima de 1500 elementos) tornam cada interação mais lenta porque o navegador precisa de recalcular estilos e layout para mais elementos. Num site WordPress com page builders, é comum encontrar DOMs com 3000 a 5000 elementos - o que torna praticamente impossível ter bom INP.

Estratégias para reduzir o DOM:

• Remover divs wrapper desnecessários - page builders como Elementor adicionam múltiplos wrappers por cada secção e coluna
• Lazy-load de conteúdo abaixo do fold - carregar elementos apenas quando ficam visíveis no viewport
• Virtual scrolling para listas longas - em vez de renderizar centenas de elementos, renderizar apenas os visíveis
• Simplificar layouts de page builders - reduzir o número de secções, colunas e widgets aninhados

#6. Eliminar jQuery quando possível

jQuery acrescenta 85KB de JavaScript e bloqueia a thread principal durante a inicialização. Muitos temas e plugins dependem dele apenas para operações simples que podem ser substituídas por JavaScript moderno:

// jQuery: document.ready
$(function() { /* ... */ });

// Moderno: DOMContentLoaded
document.addEventListener('DOMContentLoaded', () => { /* ... */ });

// jQuery: seletor
$('.my-class');

// Moderno: querySelectorAll
document.querySelectorAll('.my-class');

// jQuery: adicionar classe
$('.element').addClass('active');

// Moderno: classList
document.querySelector('.element').classList.add('active');

// jQuery: AJAX
$.ajax({ url: '/api/data', success: callback });

// Moderno: fetch
fetch('/api/data').then(res => res.json()).then(callback);

A remoção completa de jQuery nem sempre é possível, especialmente se plugins essenciais dependem dele. Nesse caso, a prioridade é garantir que o jQuery é carregado com defer e que o código personalizado do tema utiliza alternativas modernas.

#Otimização INP avançada

#Web Workers para cálculos pesados

Operações intensivas de CPU - como processamento de dados, manipulação de imagens ou cálculos complexos - devem ser retiradas da thread principal e executadas num Web Worker. Isto mantém a thread principal livre para responder a interações do utilizador:

// main.js - transferir processamento para um worker
const worker = new Worker('heavy-task.js');
worker.postMessage(data);
worker.onmessage = (event) => updateUI(event.data);

// heavy-task.js - executa numa thread separada
self.onmessage = (event) => {
  const result = heavyComputation(event.data);
  self.postMessage(result);
};

O Web Worker executa numa thread separada, completamente isolada da thread principal. Enquanto o cálculo decorre, o utilizador pode continuar a interagir com a página sem qualquer atraso. Esta técnica e especialmente útil para sites WooCommerce com filtros de produtos complexos ou pesquisas em tempo real.

#Content-visibility para conteúdo fora do ecrã

A propriedade CSS content-visibility instrui o navegador a não renderizar secções que não estão visíveis no viewport. Isto reduz significativamente o trabalho de renderização durante interações, porque o navegador não precisa de recalcular estilos e layout para conteúdo que o utilizador ainda não vê:

/* Ignorar renderização para secções abaixo do fold */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px;
}

A propriedade contain-intrinsic-size define um tamanho estimado para a secção, evitando saltos no scroll. Esta técnica é particularmente eficaz em páginas longas com muitas secções - como landing pages construídas com page builders.

#requestIdleCallback para trabalho não urgente

Tarefas que não precisam de ser executadas imediatamente - como carregar analítica, pré-carregar recursos ou enviar dados de telemetria - podem ser adiadas para períodos em que o navegador está inativo:

// Carregar analítica durante tempo inativo
requestIdleCallback(() => {
  loadGoogleAnalytics();
}, { timeout: 3000 }); // fallback: carregar dentro de 3 segundos

// Pré-carregar recursos durante tempo inativo
requestIdleCallback(() => {
  const link = document.createElement('link');
  link.rel = 'prefetch';
  link.href = '/next-page/';
  document.head.appendChild(link);
});

O parâmetro timeout garante que a tarefa é executada dentro de um período máximo, mesmo que o navegador nunca fique completamente inativo. Isto é um equilíbrio entre responsividade (não bloquear interações) e funcionalidade (garantir que a analítica é carregada).

#A vantagem Headless para INP

Para sites onde o INP é crítico é a otimização do WordPress tradicional não é suficiente, a arquitetura Headless oferece uma alternativa radical.

#Astro: INP essencialmente zero

O Astro envia zero JavaScript por defeito. Em páginas sem ilhas interativas, o INP simplesmente não se aplica porque não há nada a bloquear a thread principal. O navegador recebe HTML e CSS puros - a página responde instantaneamente a qualquer interação nativa.

Mesmo em páginas com componentes interativos, o Astro utiliza o padrão de “ilhas”: apenas os componentes específicos que necessitam de interatividade carregam JavaScript. Um botão de adicionar ao carrinho carrega o seu próprio JavaScript, mas o resto da página - cabeçalho, texto, imagens, rodapé - permanece estático.

#Next.js: React Server Components

O Next.js com React Server Components (RSC) renderiza a interface no servidor e envia ao cliente apenas o JavaScript estritamente necessário. Combinado com o code splitting automático, cada página carrega exclusivamente o JavaScript que precisa - não todo o bundle da aplicação.

Com o App Router do Next.js, os componentes são Server Components por defeito. Apenas os componentes marcados explicitamente com 'use client' enviam JavaScript para o navegador. Está inversão do modelo tradicional resulta em bundles de JavaScript dramaticamente mais pequenos.

#Comparação de desempenho

A diferença é clara: quanto menos JavaScript chega ao navegador, melhor o INP. A arquitetura Headless não é apenas uma melhoria incremental - é uma mudança de ordem de grandeza na responsividade.

#Lista de verificação para otimização INP

• Verificar o relatório Core Web Vitals no Search Console para pontuações INP atuais
• Identificar as páginas com pior INP utilizando PageSpeed Insights
• Adiar todo o JavaScript não-crítico (defer ou async)
• Carregar scripts de plugins condicionalmente apenas nas páginas que os necessitam
• Remover ou substituir código dependente de jQuery quando possível
• Adicionar { passive: true } a event listeners de scroll e touch
• Quebrar tarefas longas com scheduler.yield() ou setTimeout
• Lazy-load de conteúdo abaixo do fold e embeds de terceiros
• Reduzir o tamanho do DOM para menos de 1500 elementos
• Considerar migração para Astro ou Next.js para a melhoria mais drástica
• Monitorizar INP de campo no Search Console durante 28 dias após as alterações

#Conclusão

O INP é o Core Web Vital que separa os sites que parecem rápidos dos que parecem lentos. Enquanto o LCP mede o carregamento é o CLS mede a estabilidade visual, o INP mede como o site se comporta quando o utilizador interage com ele. É a métrica que mais se aproxima da perceção real de velocidade - porque não basta uma página carregar depressa se depois demora meio segundo a responder a um clique.

Para sites WordPress, o caminho para um bom INP exige gestão disciplinada de JavaScript. Cada plugin adicionado, cada script de terceiros incluído e cada event handler não otimizado contribui para o bloqueio da thread principal. As correções descritas neste guia - adiar scripts, carregar condicionalmente, quebrar tarefas longas, usar passive listeners e reduzir o DOM - podem levar um site de INP mau (acima de 500ms) para INP bom (abaixo de 200ms).

Para sites onde estas otimizações não são suficientes, a mudança arquitetural para Headless WordPress com Astro ou Next.js oferece uma saída mais estável. Com zero ou mínimo JavaScript no cliente, o INP deixa de ser um problema.

O investimento compensa diretamente em rankings de pesquisa, envolvimento dos utilizadores e taxas de conversão. Cada milissegundo de melhoria no INP torna o site mais responsivo - é o Google recompensa essa responsividade com maior visibilidade nos resultados de pesquisa.

Precisa de ajuda para otimizar os seus Core Web Vitals? Veja os nossos serviços de otimização de velocidade WordPress ou envie uma mensagem com o contexto do projeto em contacto.