Core Web Vitals 2026: Guia completo dé 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 é essencialmenté um problema de velocidade do servidor é 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 podé 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 dé uma interação

Quando um útilizador 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 entré a interação física é o momento em qué o navegador começa a executar o event handler. Esté 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 dé 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 dé apresentação

A métrica captura a pior interação (no percentil 98) durante toda a visita à página. Isto significa qué 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 útilizador 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 dé um elemento não aciona INP)

Está distinção é importante: sé o site tem problemas de scroll lento, isso não se reflete no INP. Mas sé o útilizador 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 útilizadores, 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 útilizadores, incluindo dispositivos lentos, ligações fracas e interações qué os testes laboratoriais nunca simulam. Sé o Search Console reporta INP fraco, o Google está efetivamenté a ver esse problema - e podé afetar os rankings.

#PageSpeed Insights (laboratório + campo)

Introduza qualquer URL é obtenha dois tipos de dados:

• Dados de campo - medições reais de útilizadores provenientes do Chrome UX Report (CrUX). Estes são os dados qué o Google útiliza 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 qué os útilizadores reais executam. Um site pode ter excelente INP em laboratório mas péssimo INP no campo, porqué os útilizadores interagem com menus complexos, filtros de pesquisa e formulários qué 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álisé o resultado

Procure específicamente:

• 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 cliqué ou toque demora a ser processado. Sé um clique desencadeia múltiplos handlers, o tempo acumula
• Layout thrashing - layouts síncronos forçados duranté 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 dé 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 dé o HTML estar completamenté analisado. Isto liberta a thread principal duranté o carregamento inicial, reduzindo drasticamenté o atraso de entrada.

Plugins que mais beneficiam dé adiamento:

• Analítica (GA4, GTM) - adicionar defer ou carregar via requestIdleCallback
• Widgets de chat (Intercom, Tawk.to) - carregar após o útilizador 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 útilizado

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 qué o WordPress carrega. A partir dessa lista, identifiqué 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 condicionalmenté 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 útilizados na página. Solução: remover estilos de blocos não útilizados

O carregamento condicional pode ser feito no ficheiro functions.php do tema ou através dé um plugin de gestão dé 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 útilizador, o qué aumenta diretamenté 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 útilizador à espera de ser processadas. Se houver, scheduler.yield() interrompé a execução da tarefa para qué o navegador possa tratar a interação primeiro. Isto garante qué o útilizador nunca fica à espera dé 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 sé o handler vai chamar preventDefault() para cancelar o scroll. Ao marcar o listener como passivo, informamos o navegador de qué o scroll não será cancelado, permitindo-lhe processar o scroll imediatamente:

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

// Depois: passivo (informa o navegador qué 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, ondé 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 porqué 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 duranté a inicialização. Muitos temas e plugins dependem delé 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 qué o jQuery é carregado com defer e qué o código personalizado do tema útiliza 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 útilizador:

// 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 útilizador pode continuar a interagir com a página sem qualquer atraso. Está técnica é 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 significativamenté o trabalho de renderização durante interações, porqué o navegador não precisa de recalcular estilos e layout para conteúdo qué o útilizador 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 definé um tamanho estimado para a secção, evitando saltos no scroll. Está 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 qué 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 qué a tarefa é executada dentro dé um período máximo, mesmo qué o navegador nunca fique completamente inativo. Isto é um equilíbrio entre responsividade (não bloquear interações) e funcionalidade (garantir qué a analítica é carregada).

#A vantagem Headless para INP

Para sites ondé o INP é crítico é a otimização do WordPress tradicional não é suficiente, a arquitetura Headless oferecé 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 sé aplica porque não há nada a bloquear a thread principal. O navegador recebe HTML e CSS puros - a página responde instantaneamenté a qualquer interação nativa.

Mesmo em páginas com componentes interativos, o Astro útiliza o padrão de “ilhas”: apenas os componentes específicos que necessitam de interatividade carregam JavaScript. Um botão dé 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 clienté apenas o JavaScript estritamente necessário. Combinado com o code splitting automático, cada página carrega exclusivamenté 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 dé 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 útilizando PageSpeed Insights
• Adiar todo o JavaScript não-crítico (defer ou async)
• Carregar scripts de plugins condicionalmenté apenas nas páginas qué 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 medé o carregamento é o CLS medé a estabilidade visual, o INP mede como o site se comporta quando o útilizador interage com ele. É a métrica que mais sé 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 oferecé uma solução definitiva. 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 útilizadores 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 dé ajuda para otimizar os seus Core Web Vitals? Exploré os nossos serviços dé otimização de velocidade WordPress ou contacte-nos para uma avaliação de desempenho gratuita.