Core Web Vitals 2026: O Alvo Real É 2,0 Segundos (e 56% dos Sites WordPress Ficam Aquém)

Abriram o PageSpeed Insights, inseriram o URL do vosso site, e o resultado foi 52 em 100 no mobile. O LCP estava em 3,8 segundos. O INP em 340 milissegundos. A pontuação era vermelha. Este não é um cenário hipotético — 56% dos sites WordPress falham nos Core Web Vitals no mobile em 2026, segundo dados reais do Chrome UX Report. E ao contrário do que muitos pensam, estas métricas não são apenas uma questão técnica: são um fator de posicionamento no Google com impacto direto no tráfego orgânico. Sites com LCP acima de 3 segundos foram significativamente penalizados na atualização de março de 2026 — uma atualização que introduziu pontuação holística de Core Web Vitals a nível de site — registando quedas de tráfego substanciais face a concorrentes mais rápidos com conteúdo equivalente (Google Core Update, março 2026).

O Que São os Core Web Vitals e O Que Mudou em 2026

Os Core Web Vitals são um conjunto de métricas de experiência do utilizador que o Google utiliza como fator de ranking desde 2021. Medem três dimensões fundamentais de qualidade de uma página web: velocidade de carregamento, resposta a interações, e estabilidade visual. O que distingue estas métricas de outras é que o Google as mede com dados reais de utilizadores — não simulações de laboratório — recolhidos pelo Chrome e agregados no Chrome UX Report (CrUX).

Em 2026, os Core Web Vitals são compostos por três métricas:

A mudança mais significativa dos últimos dois anos foi a substituição do FID (First Input Delay) pelo INP (Interaction to Next Paint), efetiva desde 12 de março de 2024. O FID media apenas o atraso na primeira interação do utilizador; o INP é mais exigente — mede a resposta a todas as interações durante a visita inteira, do primeiro clique à última ação antes de sair. O resultado é que muitos sites que passavam tranquilamente com FID agora falham com INP.

LCP: O Alvo Real É 2,0 Segundos, Não 2,5

O limiar oficial de “Bom” para LCP continua em 2,5 segundos. Mas há uma distinção importante que os dados de 2026 tornaram clara: passar em “Bom” não significa competir com os primeiros resultados do Google.

A atualização de março de 2026 revelou um padrão consistente nos dados de ranking: páginas com LCP entre 2,0 e 2,5 segundos (dentro do intervalo “Bom”) foram sistematicamente ultrapassadas por páginas com LCP abaixo dos 2,0 segundos em resultados competitivos. O algoritmo do Google não usa apenas uma classificação binária bom/mau — usa os valores concretos como sinal de qualidade.

O LCP de 2,0 segundos é o alvo competitivo de 2026 — não uma exigência oficial, mas a fronteira onde os primeiros resultados do Google habitualmente se situam. Sites que ficam entre 2,0 e 2,5 segundos passam nos Core Web Vitals mas ficam aquém da fasquia que separa as posições de topo das posições intermédias em nichos competitivos.

O LCP mede o tempo que demora a aparecer o maior elemento visível na área visível da página — normalmente uma imagem de destaque, o banner principal, ou o título de um artigo. Para a maioria dos sites WordPress, o LCP é determinado por uma imagem acima do dobramento — e As imagens são o elemento LCP em mais de 75% das páginas (HTTP Archive 2025) — o que torna a otimização de imagens a alavanca com maior impacto no LCP para a maioria dos sites WordPress.

As Principais Causas de LCP Lento em WordPress

• Imagem LCP em JPEG pesado sem otimização — uma imagem de 800KB onde caberiam 120KB em WebP ou AVIF
• Lazy loading aplicado à imagem LCP — o lazy loading adia o carregamento de imagens fora do ecrã, mas quando é aplicado à imagem principal (LCP), o efeito é o oposto do desejado: a imagem mais importante carrega por último
• TTFB alto — se o servidor demora mais de 800ms a responder, o LCP nunca pode ser bom, independentemente de tudo o resto
• Recursos de bloqueio de renderização — CSS e JavaScript que impedem o browser de mostrar conteúdo enquanto não terminam de carregar

INP: A Métrica de Responsividade que o WordPress Tem de Gerir

O INP (Interaction to Next Paint) é a métrica que avalia a responsividade em toda a visita. Globalmente, cerca de 14% dos sites WordPress falham o limiar de 200 milissegundos (dados CrUX, maio 2026) — mas é a métrica que mais deteriora em sites com JavaScript pesado, como a maioria dos themes WordPress premium. A razão é estrutural em WordPress: a maioria dos temas e plugins modernos carrega JavaScript significativo que ocupa a thread principal do browser, impedindo que as interações do utilizador (cliques, toques, preenchimento de formulários) recebam resposta rápida.

Um INP de 340ms significa que, quando um utilizador clica num botão ou seleciona uma opção, a página demora mais de um terço de segundo a reagir visivelmente. Numa loja WooCommerce, este atraso acontece ao adicionar produtos ao carrinho, ao aplicar filtros, ao clicar em “Finalizar compra”. É perceptível ao utilizador comum — e o Google mede-o.

O diagnóstico começa por identificar quais as interações com pior desempenho. No Chrome DevTools (tecla F12 → separador Performance → ativar “Web Vitals”), é possível registar interações reais e ver quais consomem mais tempo na thread principal. Os culpados mais comuns em WordPress são:

• Scripts de terceiros carregados de forma síncrona — Google Tag Manager, Meta Pixel, chat ao vivo, heatmaps que bloqueiam a thread principal
• Event listeners desnecessários — plugins que registam dezenas de listeners para funcionalidades que podem não estar sequer ativas na página
• JavaScript de plugins inativos — um plugin desativado mas não desinstalado pode continuar a registar scripts em certas configurações
• Temas com JavaScript pesado — temas premium com animações, carrosséis e efeitos visuais que monopolizam a thread principal

CLS: A Instabilidade que Irrita Utilizadores e o Google Regista

O CLS (Cumulative Layout Shift) mede a soma total de deslocamentos de layout inesperados durante o carregamento e uso da página. O limiar de “Bom” é ≤ 0,1 — o que parece um número pequeno, mas é atingido facilmente por comportamentos comuns em WordPress:

• Imagens sem dimensões definidas — quando o browser não sabe o tamanho de uma imagem antes de a carregar, reserva zero espaço; quando a imagem aparece, empurra o conteúdo abaixo dela para baixo
• Fontes web com FOIT/FOUT — quando o texto aparece primeiro numa fonte de sistema e depois muda para a fonte personalizada, o tamanho pode variar e deslocar elementos circundantes
• Anúncios, banners e iframes sem espaço reservado — um banner publicitário que aparece no topo da página e empurra todo o conteúdo para baixo é uma violação clássica de CLS
• Conteúdo dinâmico injetado acima do dobramento — avisos de cookies, barras de promoções, popups que aparecem sobre o conteúdo e deslocam elementos existentes

A correção de CLS é frequentemente a mais simples das três métricas: basta adicionar atributos width e height a todas as imagens no HTML, reservar espaço para anúncios e iframes com CSS, e usar font-display: swap (com fonte de fallback de dimensões semelhantes) para minimizar o deslocamento causado por fontes web.

TTFB: O Diagnóstico por Trás do LCP Lento

O TTFB (Time to First Byte) não é um Core Web Vital — mas é o diagnóstico que explica grande parte dos problemas de LCP. É o tempo entre o browser fazer o pedido HTTP e receber o primeiro byte de resposta do servidor. O limiar de “Bom” é ≤ 800 milissegundos.

Um TTFB alto significa que o servidor está lento a gerar a página — e se o servidor demora 1,5 segundos só a começar a responder, é matematicamente impossível ter um LCP abaixo de 2,5 segundos com qualquer outra otimização. Apenas 32% dos sites WordPress têm TTFB “Bom”, segundo dados do CrUX — o problema mais comum é a ausência de cache de página, que obriga o PHP e a base de dados a gerar cada pedido do zero. Se o TTFB não melhora após ativar cache, o servidor precisa de atenção — o serviço de otimização WordPress da OnePixel inclui diagnóstico e correção de TTFB elevado.

Em WordPress, o TTFB é controlado por três fatores: a qualidade do alojamento (a infraestrutura base), a presença de cache de página (que serve HTML pré-gerado em vez de executar PHP), e a eficiência das consultas à base de dados (um tema de wp_options sobrecarregado pode adicionar centenas de milissegundos ao TTFB).

WordPress vs Concorrência: Os Números de 2026

Os dados do HTTP Archive de 2025-2026 pintam um quadro claro sobre o desempenho relativo do WordPress:

A diferença não é intrínseca ao WordPress — é estrutural. O Shopify controla o TTFB ao nível da infraestrutura, otimiza imagens automaticamente, e tem um conjunto limitado de templates testados. O WordPress é uma plataforma aberta onde qualquer combinação de 60.000 plugins pode ser instalada. A média de plugins num site WordPress em produção é de 20 a 30 — cada um potencialmente adicionando CSS, JavaScript, e consultas à base de dados.

A boa notícia é que um WordPress bem configurado consegue igualar ou superar plataformas comerciais — mas requer otimização ativa, não apenas instalação e publicação de conteúdo.

Como Melhorar Cada Métrica: O Que Funciona de Facto

Para LCP: Imagens e Cache em Primeiro

• Converter todas as imagens para WebP ou AVIF — WebP reduz o tamanho 25-35% face ao JPEG; AVIF reduz 30-50%. Plugins como ShortPixel, Imagify ou o Converter for Media fazem a conversão automaticamente. O AVIF tem suporte universal nos browsers modernos desde 2023.
• Nunca aplicar lazy loading à imagem LCP — identificar qual é a imagem LCP na página (geralmente o banner ou a primeira imagem do artigo) e garantir que não tem loading="lazy". Adicionalmente, adicionar fetchpriority="high" ao elemento LCP sinaliza ao browser que este recurso é prioritário.
• Ativar cache de página — WP Rocket, FlyingPress, LiteSpeed Cache ou W3 Total Cache. Sem cache de página, o PHP gera cada pedido do zero; com cache, o servidor serve HTML estático pré-gerado, reduzindo o TTFB de 1-3 segundos para 50-150ms.
• Usar um CDN — um Content Delivery Network serve os recursos estáticos (imagens, CSS, JavaScript) a partir de servidores geograficamente próximos do visitante. Para Portugal, um CDN com pontos de presença em Lisboa ou Madrid reduz significativamente a latência para utilizadores portugueses.
• Inline de CSS crítico — o CSS necessário para renderizar a área visível inicial deve ser incluído diretamente no HTML (inline), evitando um pedido HTTP extra que bloqueia a renderização. WP Rocket e FlyingPress geram e inserem este CSS crítico automaticamente.

Para INP: Reduzir a Carga na Thread Principal

• Diferir JavaScript não crítico — adicionar defer a scripts que não são necessários no carregamento inicial (analytics, chat, formulários abaixo do dobramento). O defer descarrega o script em paralelo mas executa-o apenas após o HTML estar completamente processado.
• Desativar plugins desnecessários por página — o plugin Perfmatters permite desativar seletivamente scripts de plugins em páginas onde não são usados. Um plugin de WooCommerce a carregar scripts em páginas de blog, ou um plugin de formulários a carregar em todas as páginas mesmo que o formulário só exista em /contacto, são causas comuns de INP elevado.
• Auditar scripts de terceiros — Google Tag Manager, Meta Pixel, Hotjar, Intercom, e similares têm impacto significativo no INP. Cada script deve ser avaliado pelo valor que gera versus o custo em performance. Um pixel de remarketing numa landing page com taxa de conversão de 2% pode estar a degradar a experiência de 100% dos visitantes.
• Escolher temas leves — temas baseados em Tailwind CSS ou CSS vanilla com JavaScript mínimo (GeneratePress, Kadence, Astra) têm melhor desempenho de INP do que temas com builders de arrastar-e-largar que geram JavaScript complexo.

Para CLS: Dimensões e Fontes

• Definir width e height em todas as imagens — o WordPress adiciona automaticamente estas dimensões às imagens inseridas pelo editor de blocos; o problema surge com imagens adicionadas diretamente em HTML, temas antigos, ou builders de página que omitem os atributos.
• Hospedar fontes Google localmente — em vez de carregar fontes do CDN do Google (fonts.googleapis.com), servir os ficheiros de fonte diretamente do servidor do site elimina um pedido HTTP externo e permite controlar o comportamento de carregamento. Plugins como OMGF (Optimize My Fonts) ou a funcionalidade integrada do FlyingPress automatizam este processo.
• Usar font-display: swap com fallback calibrado — font-display: swap mostra texto com uma fonte de sistema enquanto a fonte personalizada carrega, evitando texto invisível; para minimizar o deslocamento visual quando a fonte troca, escolher uma fonte de sistema com métricas similares (line-height, x-height) à fonte final.
• Reservar espaço para conteúdo dinâmico — se o vosso site tem um aviso de cookies, uma barra de promoção, ou anúncios que aparecem após o carregamento, definir uma altura fixa no CSS para esse espaço evita que o restante conteúdo seja empurrado quando o elemento aparece.

Ferramentas para Medir os Core Web Vitals

A distinção mais importante em medição de Core Web Vitals é entre dados de laboratório (simulação) e dados de campo (utilizadores reais). O Google usa dados de campo para rankings — o PageSpeed Insights mostra ambos, mas o que importa para SEO é o painel “Descobrir o que os seus utilizadores reais experimentam”.

O primeiro lugar a começar é o Google Search Console → Core Web Vitals. Este relatório mostra o estado agregado do site dividido em URLs “Boas”, “A melhorar”, e “Fracas” — e agrupa URLs com problemas semelhantes. É mais eficiente do que analisar página a página no PageSpeed Insights. Uma vez identificado qual o tipo de problema mais comum (LCP, INP ou CLS), e em que secção do site ocorre, o PageSpeed Insights permite fazer o diagnóstico detalhado de um URL específico.

Lista de Verificação: Core Web Vitals no WordPress

• ☐ Verificar o relatório Core Web Vitals no Google Search Console
• ☐ Testar a página principal no PageSpeed Insights — anotar LCP, INP, CLS e TTFB
• ☐ Identificar o elemento LCP da página principal (geralmente uma imagem)
• ☐ Garantir que a imagem LCP não tem loading="lazy"
• ☐ Adicionar fetchpriority="high" à imagem LCP
• ☐ Converter imagens para WebP ou AVIF (ShortPixel, Imagify, ou Converter for Media)
• ☐ Definir width e height em todas as imagens
• ☐ Ativar cache de página (WP Rocket, FlyingPress, LiteSpeed Cache)
• ☐ Ativar geração de CSS crítico inline
• ☐ Adiar carregamento de JavaScript não crítico com defer
• ☐ Hospedar fontes Google localmente (OMGF ou FlyingPress)
• ☐ Aplicar font-display: swap nas fontes web
• ☐ Verificar TTFB — se > 800ms, priorizar cache de página ou upgrade de alojamento (o plano de manutenção WordPress da OnePixel inclui auditoria de TTFB)
• ☐ Auditar scripts de terceiros — desativar nas páginas onde não são necessários
• ☐ Verificar o CLS — testar com navegação lenta no Chrome DevTools (modo “throttle: Slow 3G”)

O Impacto Real nos Rankings em 2026

O Google é consistente em afirmar que os Core Web Vitals são um fator de desempate — conteúdo relevante e de qualidade continua a ser o fator principal. Mas a atualização de dezembro de 2025 tornou mais claro o que “desempate” significa na prática: sites com performance fraca sofreram perdas de tráfego 20 a 30% mais severas do que concorrentes com conteúdo equivalente mas melhor performance.

Para PMEs portuguesas, o impacto mais tangível não é necessariamente no ranking direto — é na taxa de rejeição e conversão. Estudos de 2025 mostram que cada segundo adicional de tempo de carregamento aumenta a taxa de rejeição em 32%. Um site de prestação de serviços que converte 3% dos visitantes em leads, com melhorias de LCP de 3,8s para 1,9s, pode esperar um aumento de 20 a 30% em leads sem qualquer alteração de conteúdo ou investimento em publicidade.

A performance deixou de ser uma preocupação exclusiva de developers. É um indicador de negócio com impacto direto em tráfego, conversões, e custos de aquisição.

Se o vosso site WordPress tem pontuações de Core Web Vitals abaixo do esperado, contacte-nos — nos planos de manutenção da OnePixel incluímos auditoria de performance, otimização de imagens, configuração de cache e CDN, e monitorização contínua dos Core Web Vitals com alertas quando os valores saem dos limiares de “Bom”.