Para melhorar os core web vitals no WordPress, comece pela hospedagem e pela versão de PHP, ative cache de página e cache de objetos persistente, otimize as imagens e reduza o JavaScript dos plugins. Assim ataca LCP, INP e CLS. Meça sempre com PageSpeed Insights, Chrome DevTools e dados CrUX.
Em resumo:
- Para um bom resultado, o LCP deve ficar em 2,5 segundos ou menos em 75% das visitas; os dados CrUX refletem a experiência real.
- Em páginas de produto e no carrinho, teste filtros e formulários: tarefas longas de JavaScript prejudicam o INP, mesmo que o primeiro clique responda.
- Audite plugins num ambiente de testes, desativando grupos e comparando scripts, pedidos e métricas antes de remover ou substituir os que mais pesam.
- Atualize o PHP após testar a compatibilidade de temas e plugins; se o TTFB continuar alto com cache, peça ao alojamento mais recursos.
- Reserve espaço para imagens, anúncios e barras de cookies antes do carregamento; elementos inseridos tarde podem deslocar a página e provocar cliques falhados.
Índice
- O que medem o LCP, o INP e o CLS e que valores deve atingir
- Como testar corretamente: ferramentas, passos e diferença entre lab e field
- Como decidir por onde começar
- Como reduzir o LCP no WordPress
- Como melhorar o INP: reduzir a latência das interações
- Como reduzir o CLS: estabilidade visual
- Hospedagem, PHP, cache e cache de objetos: as otimizações de servidor
- Imagens, formatos modernos e CDN
- Como auditar plugins e tema
- Checklist rápido para melhorar as Core Web Vitals em WordPress
- A nossa perspetiva: quick wins primeiro, servidor com método
- Diagnóstico e otimização de Core Web Vitals com a ArqWeb
- Perguntas frequentes
- Fontes
O que medem o LCP, o INP e o CLS e que valores deve atingir
O LCP (Largest Contentful Paint) mede quanto tempo demora a aparecer o maior elemento visível, normalmente uma imagem de destaque ou um título grande. Para uma boa experiência, deve ficar em 2,5 segundos ou menos em 75% das visitas, segundo o Web.
O INP (Interaction to Next Paint) mede a latência das interações do utilizador, como cliques, toques e teclas, ao longo de toda a visita. Substituiu o FID, que só olhava para a primeira interação. Com o INP, uma página que responde bem ao primeiro clique mas engasga no menu ou no carrinho passa a ser penalizada. O web.dev explica o INP e insiste em que o essencial é identificar e quebrar as tarefas longas que bloqueiam a thread principal do navegador.
O CLS (Cumulative Layout Shift) mede o quanto o conteúdo se desloca de forma inesperada enquanto a página carrega. É o que provoca aquele clique falhado porque um banner empurrou o botão para baixo.
Estas métricas importam por duas razões. Afetam diretamente a perceção de velocidade e de estabilidade de quem visita o site e fazem parte dos sinais de experiência de página que o Google considera. Por isso, uma página rápida mas instável ou pouco responsiva continua a ter problemas.
Como testar corretamente: ferramentas, passos e diferença entre lab e field
Antes de mexer em qualquer coisa, precisa de uma linha de base fiável. A diferença essencial está entre dados de laboratório (simulados, com um dispositivo e uma rede definidos, como o Lighthouse) e dados de campo (recolhidos de utilizadores reais, como o CrUX, o relatório de experiência de utilizador do Chrome). Os dados de campo refletem o que os visitantes vivem de facto, por isso devem orientar as decisões. Os de laboratório servem para diagnosticar a causa e validar correções.
As ferramentas de base são o PageSpeed Insights (que junta Lighthouse e CrUX), o Chrome DevTools, o WebPageTest e, dentro do WordPress, o Query Monitor.
- Abra o PageSpeed Insights com o URL da página e veja primeiro o separador de dados de campo, se existir.
- Corra o teste de laboratório em móvel, que é normalmente o perfil mais exigente, e repita o teste para perceber a variação.
- Identifique o elemento LCP no relatório e confirme no DevTools (separador Performance) qual é e quando é pedido.
- Procure as tarefas longas na thread principal, que explicam a maioria dos problemas de INP.
- Use o WebPageTest com uma ligação lenta para ver a cascata de pedidos e o tempo até ao primeiro byte.
- Instale o Query Monitor num ambiente de testes para ver consultas lentas, hooks pesados e scripts carregados por cada plugin.
- Registe os valores iniciais numa folha, por página e por métrica, para comparar depois de cada alteração.
Teste sempre as páginas que importam ao negócio (página inicial, páginas de serviço, produto, artigo mais visitado) e não apenas a home.
Como decidir por onde começar
A regra mais prática é atacar a métrica pior e com maior impacto. Na maioria dos sites WordPress, é o LCP, porque depende de servidor, imagens e CSS, áreas onde há ganhos rápidos. A equipa do Chrome recomenda, no seu guia das formas mais eficazes de melhorar as Core Web Vitals, focar nos ganhos rápidos que dão mais retorno em vez de tentar aplicar todas as otimizações técnicas de uma vez.
Pese sempre o esforço contra o retorno. Ativar cache de página ou excluir a imagem principal do lazy-loading leva minutos e costuma mexer logo no LCP. Reescrever um tema ou mudar de arquitetura só se justifica depois de esgotar o resto.
Distinga também o que é servidor do que é front-end. Um tempo até ao primeiro byte (TTFB) alto aponta para hospedagem, PHP, cache e base de dados, e exige muitas vezes intervenção do fornecedor de alojamento. Imagens pesadas, fontes e scripts tratam-se no próprio site.
Como reduzir o LCP no WordPress
O LCP resolve-se em duas frentes: entregar o HTML mais depressa e fazer com que o recurso principal seja pedido e desenhado sem atrasos.
- Não faça lazy-load do elemento LCP. O Web: a imagem principal deve carregar com prioridade, usando
fetchpriority="high"e preload. - Use preload do recurso crítico. O WordPress disponibiliza o filtro wp_preload_resources para imprimir diretivas de preload, incluindo a prioridade de obtenção.
- Reduza o TTFB com hospedagem de qualidade, PHP atualizado e cache de página. Se possível, ative cache de objetos persistente com Redis ou Memcached.
- Otimize as imagens: formatos modernos, compressão,
srcsetpara imagens responsivas e entrega por CDN. - Extraia o CSS crítico e coloque-o inline, para que o primeiro ecrã não espere por folhas de estilo grandes.
- Elimine pedidos de rede desnecessários que competem com o recurso LCP.
O que costuma falhar na prática é um plugin de lazy-loading aplicado a todas as imagens, incluindo a do topo da página. Quase sempre há uma opção para excluir as primeiras imagens, e vale a pena usá-la.
Dica profissional: no DevTools, abra o separador Performance, localize o elemento LCP e veja se o pedido começa tarde. Se começar, o problema é descoberta do recurso (preload, prioridade), não tamanho do ficheiro.
Como melhorar o INP: reduzir a latência das interações
O INP piora quando a thread principal está ocupada com JavaScript no momento em que o visitante clica. Em WordPress, isso vem quase sempre de plugins, construtores de páginas e scripts de terceiros.
- Encontre as tarefas longas com o separador Performance do DevTools e com o Query Monitor, que mostra que plugin carrega que script.
- Divida as tarefas pesadas em pedaços menores, como o web.dev recomenda para o INP, para o navegador poder responder entre elas.
- Aplique
deferouasynca scripts não críticos e carregue condicionalmente os que só são precisos em certas páginas. - Reveja plugins que acrescentam bundles grandes. Quando uma funcionalidade pode ser feita no servidor, prefira essa via.
- Meça antes e depois com interações reais: abrir o menu, filtrar produtos, submeter um formulário.
A documentação do WordPress sobre otimização de desempenho aponta a inflação de plugins como um dos principais obstáculos e recomenda auditar com o Query Monitor e medir o impacto real. Remover os plugins que bloqueiam a renderização ou acrescentam JavaScript em excesso é citado como o passo inicial mais impactante.
Dica profissional: teste o INP com a interação que os seus visitantes mais fazem, não com a primeira que lhe ocorrer. O pior caso costuma estar num filtro, num carrinho ou num formulário com validação em JavaScript.
Como reduzir o CLS: estabilidade visual
O CLS corrige-se sobretudo reservando espaço antes de o conteúdo chegar. O navegador só consegue manter o layout estável se souber, desde o início, que tamanho cada elemento vai ocupar.
- Defina dimensões em imagens, vídeos e iframes, com os atributos
widtheheightou com a propriedade CSSaspect-ratio. - Use marcadores de posição para conteúdo que chega tarde, como anúncios, incorporações e widgets, e evite injetar blocos acima de conteúdo já visível.
- Controle o carregamento das fontes com
font-displaye, quando reduzir os saltos de estilo, aloje-as no próprio servidor. - Remova ou adie scripts de terceiros que provoquem deslocamentos, como pop-ups, barras de cookies mal dimensionadas e widgets de chat.
- Valide no Chrome DevTools, no separador Performance, onde os deslocamentos de layout aparecem assinalados na linha temporal.
Um caso frequente é a barra de cookies ou um banner promocional que aparece depois do carregamento e empurra o conteúdo para baixo. Reservar-lhe espaço fixo, ou posicioná-lo por cima do conteúdo em vez de o inserir no fluxo, resolve o problema.
Dica profissional: se não consegue ver o deslocamento a olho nu, grave a linha temporal no DevTools com o ecrã lento (throttling de CPU). Os saltos ficam muito mais evidentes.
Hospedagem, PHP, cache e cache de objetos: as otimizações de servidor
As otimizações de servidor costumam trazer ganhos mais duradouros do que qualquer plugin de front-end isolado, e a documentação oficial de otimização do WordPress segue essa lógica em camadas: primeiro hospedagem de qualidade e PHP atualizado, depois cache, só depois os recursos do site.
PHP. Atualizar para versões suportadas traz melhorias de segurança e de desempenho. A página de otimização de PHP refere PHP 7.4 como versão oficialmente suportada e recomenda PHP 8 quando houver compatibilidade. Teste primeiro num ambiente de staging, porque plugins e temas antigos podem falhar. Ajuste o php.ini (memory_limit, max_execution_time) apenas quando houver sintomas concretos.
Cache. Combine opcode cache (Opcache) com cache de página, seja por plugin como o WP Super Cache ou o Cache Enabler, seja por proxy inverso como o Varnish. A documentação sobre cache no WordPress refere que esta combinação pode melhorar o desempenho de páginas estáticas centenas de vezes.
Cache de objetos persistente. Com Redis ou Memcached, e através da Transients API, evita consultas repetidas à base de dados.
Cabeçalhos e base de dados. Configure Cache-Control, ETag e compressão, e reduza as opções carregadas automaticamente (autoload) na tabela wp_options. Se o TTFB continuar alto depois de tudo isto, considere mais CPU e memória, ou distribuir a entrega por uma rede edge ou CDN.
Imagens, formatos modernos e CDN
As imagens são o recurso LCP mais comum e o maior peso de muitas páginas, por isso a entrega de media merece método.
Converta para WebP ou AVIF quando o navegador o suporta, mantendo uma alternativa para os restantes, e gere srcset e sizes para que cada dispositivo descarregue apenas o tamanho de que precisa. Plugins como o Smush tratam da compressão e da entrega, mas escolha configurações que não acrescentem JavaScript pesado ao front-end.
Uma CDN descarrega o servidor e aproxima os ficheiros do visitante. Soluções de gestão e entrega de media como o Cloudinary existem como plugin para WordPress. Valide depois os cabeçalhos e os tempos de vida (TTL) dos recursos estáticos, porque uma CDN mal configurada não ganha nada.
O lazy-loading é útil para imagens abaixo da dobra, e plugins como o Rocket Lazy Load tratam disso, mas exclua sempre o elemento LCP. Depois de cada alteração, volte ao PageSpeed Insights e ao WebPageTest para confirmar o efeito.
Como auditar plugins e tema
Uma auditoria de plugins é um procedimento que se repete, e convém fazê-lo num ambiente de staging para não arriscar o site em produção.
- Registe a linha de base (LCP, INP, CLS, TTFB, número de pedidos, peso da página).
- Desative os plugins por grupos e meça o efeito de cada grupo com o Query Monitor e o DevTools.
- Observe o tamanho do DOM, o número de pedidos e os scripts mais pesados.
- Para cada culpado, decida entre configurar melhor, substituir por algo mais leve ou desenvolver uma solução à medida.
- Documente cada mudança e prepare a reversão, para poder voltar atrás de forma controlada.
- Quando uma funcionalidade afeta as métricas e há dúvidas, teste duas versões da página e compare.
A regra prática é simples: menos plugins ativos e um tema leve melhoram quase sempre o desempenho. Temas bem construídos, como o Neve, acrescentam menos carga ao ponto de partida do que temas multiusos cheios de módulos que nunca usa.
Se este diagnóstico lhe parece o ponto de partida certo, o nosso guia WordPress lento: como diagnosticar detalha o processo.
Checklist rápido para melhorar as Core Web Vitals em WordPress
- Valide os dados de campo no PageSpeed Insights e registe a linha de base por página.
- Atualize o PHP e confirme que o alojamento acompanha a carga do site.
- Ative cache de página e, se o alojamento permitir, cache de objetos persistente.
- Identifique o elemento LCP e garanta que não tem lazy-load e que tem prioridade alta.
- Otimize imagens e fontes: formatos modernos,
srcset, dimensões reservadas efont-display. - Audite plugins e tema com o Query Monitor e remova ou substitua o que pesa.
- Meça os resultados no CrUX, lembrando que os dados de campo levam algum tempo a refletir as mudanças.
Em sites de conteúdo, o LCP costuma vir do artigo ou da imagem de destaque. Em lojas, as páginas de produto e o carrinho exigem mais atenção, tanto ao LCP como ao INP. Depois de cada passo, volte à ferramenta de teste que lhe interessa para confirmar o efeito antes de avançar.
A nossa perspetiva: quick wins primeiro, servidor com método
Nos projetos em que trabalhamos, o erro mais comum é saltar para soluções complexas antes de esgotar o que é simples. Na nossa experiência, a ordem que melhor resulta é limpar plugins desnecessários, ativar cache e resolver a imagem LCP, e só depois pensar em mexer na infraestrutura. Quando o gargalo está no servidor, trabalhamos de forma coordenada com o alojamento e medimos com dados de campo antes e depois, para não confundir melhorias reais com variações de laboratório.
O que muita gente subestima é que as Core Web Vitals não se resolvem uma vez e acabam. Cada plugin novo, cada campanha com um script extra, cada banner pode desfazer o trabalho. Por isso, mais do que uma otimização pontual, vale a pena criar o hábito de medir sempre que algo muda. E quando as melhorias exigem alterações no servidor ou desenvolvimento à medida, o apoio profissional poupa tempo e riscos.
— Tomás
Diagnóstico e otimização de Core Web Vitals com a ArqWeb
Se prefere entregar o trabalho técnico, é para isso que existe a nossa assistência WordPress. Fazemos o diagnóstico, explicamos em linguagem clara o que encontrámos e intervimos onde faz diferença, seja no servidor, no tema ou nos plugins.
Um diagnóstico típico nosso inclui:
- Medição do TTFB e da resposta do servidor, com indicação do que depende do alojamento.
- Análise do LCP, com identificação do elemento e do que atrasa o seu carregamento.
- Análise do INP, com localização das tarefas longas e dos scripts responsáveis.
- Análise do CLS, com os elementos que se deslocam e como reservar-lhes espaço.
- Um plano de ação por prioridade, ordenado por impacto e esforço.
Também podemos tratar de alterações e migrações quando a otimização exige mexer na estrutura do site, sempre com o cuidado de não perder o posicionamento no Google. Os nossos serviços estão reunidos na página de serviços. Se quer saber onde está o problema do seu site, contacte-nos através da assistência WordPress e dizemos-lhe por onde começar.
Perguntas frequentes
O que são as Core Web Vitals num site?
São três métricas que o Google usa para avaliar a experiência real de quem visita uma página: LCP (velocidade de carregamento do maior elemento), INP (capacidade de resposta às interações) e CLS (estabilidade visual). Medem-se com dados de laboratório e, de preferência, com dados de campo de utilizadores reais.
As Core Web Vitals afetam o SEO?
Sim, fazem parte dos sinais de experiência de página, mas são apenas um fator entre muitos. Um conteúdo relevante continua a pesar mais. Ainda assim, um site lento ou instável perde visitantes e conversões, e isso conta por si só.
O WordPress está desatualizado em 2026?
Não. O WordPress continua a ser mantido e a receber melhorias de desempenho, e as suas boas práticas de otimização estão documentadas oficialmente. O que o torna lento, quase sempre, é o excesso de plugins, um alojamento fraco ou um tema pesado, não a plataforma em si.
O que é o núcleo do WordPress (WordPress core)?
É o software base do WordPress, ou seja, os ficheiros e funcionalidades oficiais que existem antes de acrescentar temas e plugins. Manter o núcleo atualizado, juntamente com o PHP, é uma das bases de um site seguro e rápido.
Fontes
O navegador só desenha a página depois de processar o CSS e de executar o JavaScript síncrono. Tudo o que for desnecessário no caminho crítico atrasa o LCP e agrava o INP.
Extraia o CSS crítico, ou seja, o necessário para o primeiro ecrã, e coloque-o inline. Adie o carregamento do restante, ou carregue-o só nas páginas em que é usado. Os temas com folhas gigantes para todas as páginas são um problema recorrente.
Nas fontes, hospedá-las no próprio servidor reduz a dependência de terceiros e dá controlo sobre o font-display, o que limita os flashes de texto invisível ou sem estilo. O plugin Host Webfonts Local automatiza esse processo.
Minifique e comprima os ficheiros, use cache de longa duração com versionamento e reveja os bundles de JavaScript para reduzir o número de pedidos. Por fim, desconfie dos plugins que injetam scripts em todas as páginas. Quando existe uma alternativa por hooks do lado do servidor, ela tende a ser mais leve.