Core Web Vitals para WordPress: Guia de Otimização (2026)

WordPress e Core Web Vitals: O Cenário Atual

O WordPress tem um problema de performance. De acordo com o Relatório de Tecnologia do Core Web Vitals (alimentado por dados CrUX), o WordPress consistentemente fica atrás do Shopify, Wix e Squarespace nas taxas de aprovação do Core Web Vitals em dispositivos móveis. No final de 2025, apenas cerca de 44% dos sites WordPress em dispositivos móveis passaram nos três Core Web Vitals. Compare isso com o Shopify, com cerca de 65%, e o Wix, acima de 60%.

Isso não ocorre porque o WordPress seja inerentemente lento. O core do WordPress é enxuto. O problema é o que é adicionado por cima: temas pesados, page builders inchados, dezenas de plugins injetando cada um seu próprio JavaScript e CSS, imagens não otimizadas e hospedagem compartilhada barata com tempos de resposta de servidor lentos.

A boa notícia: como o WordPress oferece controle total sobre o seu código, hospedagem e estratégia de otimização, é a plataforma onde a otimização qualificada faz a maior diferença. Os sites com os quais trabalho passam rotineiramente no Core Web Vitals em todas as páginas. A chave é entender quais fatores específicos do WordPress afetam cada métrica e resolvê-los sistematicamente.

Core Web Vitals do WordPress em Números

O Relatório de Tecnologia do CrUX e o HTTP Archive rastreiam as taxas de aprovação de CWV para todos os principais CMS. Aqui é onde o WordPress está no final de 2025:

Fonte: Relatório de Tecnologia CrUX via HTTP Archive, junho de 2025. Rankings de INP a partir de análise do SearchEngineJournal.

O principal insight desses dados: o problema do WordPress não é o INP (85.9% de aprovação, apenas um pouco abaixo da média). O problema do WordPress é o LCP, impulsionado por um TTFB lento. Apenas 32% dos sites WordPress têm um bom TTFB de acordo com dados do CrUX, em comparação com plataformas totalmente hospedadas como Shopify, onde o TTFB é tratado em nível de infraestrutura. Este é um problema de qualidade da hospedagem, não um problema da plataforma.

Em todos os sites WordPress monitorados pelo CoreDash, o padrão é consistente: antes da otimização, a mediana do LCP mobile está entre 3.5 e 4.5 segundos. Após a implementação das otimizações de hospedagem, cache e imagens descritas neste guia, a mediana cai para 1.6 a 2.1 segundos. A mudança isolada de maior impacto é quase sempre atualizar de uma hospedagem compartilhada sem cache de página para uma hospedagem gerenciada com cache no nível do servidor e uma CDN, o que por si só reduz tipicamente o TTFB de 800ms+ para menos de 200ms.

Por Que o WordPress Sofre com o Core Web Vitals

Antes de mergulhar nas correções, você precisa entender as cinco causas raízes que fazem os sites WordPress falharem no Core Web Vitals. Todo problema que vejo em meu trabalho de consultoria pode ser rastreado até uma (ou mais) delas:

1. Inchaço dos Page Builders

Page builders como Elementor, Divi e WPBakery adicionam enormes quantidades de HTML, CSS e JavaScript extra a cada página. Apenas o Elementor pode adicionar mais de 21 MB de código descompactado a uma instalação do WordPress. Cada widget, animação e opção de estilo aumenta o tamanho do DOM e o volume de recursos de bloqueio de renderização.

O resultado: páginas inchadas com centenas de elementos empacotadores <div> desnecessários, múltiplos arquivos CSS carregados em todas as páginas, independentemente de seus widgets serem usados, e JavaScript que bloqueia a thread principal durante o carregamento da página. Isso prejudica diretamente o LCP (mais recursos bloqueando a renderização), INP (mais JavaScript competindo pela thread principal) e CLS (recálculos de layout à medida que o CSS do construtor é carregado).

O Gutenberg (o editor de blocos nativo do WordPress) produz HTML significativamente mais limpo com um footprint de DOM menor. Se você estiver construindo um novo site WordPress, considere usar o Gutenberg com um tema leve como GeneratePress, Astra ou Kadence em vez de um page builder pesado.

2. Excesso de Plugins

O site WordPress médio tem de 20 a 30 plugins ativos. Cada plugin pode injetar seu próprio CSS e JavaScript em cada página, mesmo em páginas onde o plugin não é usado. Um plugin de formulário de contato carregando seus scripts na sua página inicial. Um script do WooCommerce carregando nas suas postagens do blog. Um plugin de slider carregando em todos os lugares, mesmo que você o use apenas em uma página.

Já auditei sites WordPress onde a remoção de scripts de plugins não utilizados reduziu o JavaScript total em mais de 40%. A correção não é necessariamente remover os plugins por completo. Trata-se de carregamento condicional: garantir que os recursos de cada plugin carreguem apenas nas páginas onde são realmente necessários. Plugins como Perfmatters e Asset CleanUp oferecem controle por página sobre quais scripts e estilos são carregados.

3. Imagens Não Otimizadas

O WordPress não impõe a otimização de imagens por padrão. Os editores de conteúdo fazem upload de fotos de 3000x2000 pixels direto de suas câmeras, e o WordPress as entrega em resolução total, mesmo quando o tema as exibe com apenas 800 pixels de largura. O elemento LCP na maioria das páginas do WordPress é uma imagem, e uma hero image não otimizada é a causa mais comum de falha no LCP.

O WordPress 5.8+ adicionou suporte nativo ao formato WebP e o WordPress 5.5+ adicionou lazy loading nativo, mas esses recursos requerem configuração adequada. Muitos temas e plugins os substituem ou implementam as suas próprias versões (muitas vezes piores). Consulte nosso guia sobre como otimizar imagens para o Core Web Vitals para a estratégia completa.

4. Hospedagem Lenta e Resposta do Servidor

O Time to First Byte (TTFB) do seu servidor estabelece o limite para o seu LCP. Nenhuma quantidade de otimização de frontend pode compensar um servidor que leva 800ms para responder. A hospedagem compartilhada barata (onde centenas de sites compartilham um único servidor) é a causa mais comum de TTFB ruim em sites WordPress.

O WordPress é um CMS dinâmico que executa PHP e consulta um banco de dados MySQL em cada solicitação de página (a menos que o cache esteja configurado). Sem cache de página, o WordPress é inerentemente mais lento que sites estáticos. Com cache adequado e um host de qualidade, o TTFB pode ficar abaixo de 200ms. Sem ele, de 500ms a 1500ms é comum. Saiba mais em nosso guia de otimização do Time to First Byte.

5. Problemas de Carregamento de Fontes

Muitos temas WordPress carregam o Google Fonts dos servidores do Google, o que requer uma pesquisa de DNS e conexão com um domínio externo antes que as fontes comecem a ser baixadas. Isso atrasa a renderização de texto (prejudicando o LCP para elementos LCP baseados em texto) e pode causar Flash of Unstyled Text (FOUT) quando a web font é trocada e substitui a fonte de fallback, causando CLS.

A solução: hospede as suas fontes localmente (self-host) e use font-display: swap ou font-display: optional com uma fonte de fallback devidamente correspondida para minimizar as mudanças de layout.

Corrigindo o LCP no WordPress

O Largest Contentful Paint mede a rapidez com que seu conteúdo principal se torna visível. No WordPress, as falhas de LCP quase sempre são rastreadas até imagens, recursos de bloqueio de renderização ou resposta lenta do servidor. Aqui está a ordem de prioridade para corrigir o LCP:

Identifique Seu Elemento LCP

Execute sua página no PageSpeed Insights e olhe em "Diagnósticos" por "Elemento Largest Contentful Paint." Na maioria das páginas do WordPress, essa é a hero image, a imagem em destaque ou o primeiro bloco de texto grande. Saber qual é o seu elemento LCP determina sua estratégia de otimização.

Faça o Preload da Imagem LCP

Se o seu elemento LCP for uma imagem, adicione uma dica de preload na seção <head> do seu tema. No WordPress, você pode adicionar isso através do functions.php do seu tema:

// Preload the hero image on the homepage
function preload_lcp_image() {
    if ( is_front_page() ) {
        echo '<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" fetchpriority="high">';
    }
}
add_action( 'wp_head', 'preload_lcp_image', 1 );

Além disso, adicione fetchpriority="high" diretamente à tag <img> da sua imagem LCP. O WordPress 6.3+ faz isso automaticamente para a primeira imagem de conteúdo, mas verifique se está funcionando em seu tema. Para a estratégia completa, veja como fazer preload da imagem LCP.

Elimine Recursos de Bloqueio de Renderização

Temas e plugins do WordPress frequentemente enfileiram CSS e JavaScript no <head> que bloqueiam a renderização. Use um plugin de performance para adiar (defer) o JavaScript não crítico e carregar o CSS não crítico de forma assíncrona. As opções mais eficazes:

• WP Rocket: atrasa a execução de JavaScript até a interação do usuário, gera CSS crítico automaticamente
• FlyingPress: alternativa leve com recursos semelhantes de adiamento (defer) e CSS crítico
• Perfmatters: gerenciamento granular de scripts por página, desativa recursos não utilizados
• Nosso plugin WP Core Web Vitals: projetado especificamente para otimização de CWV com detecção de LCP e cronometragem avançada de imagens

Para controle manual, veja 14 métodos para adiar JavaScript e como gerar e usar CSS crítico.

Ative o Cache de Página

O cache de página armazena o HTML totalmente renderizado de cada página para que o WordPress não precise executar PHP e consultar o banco de dados em cada visita. Isso reduz drasticamente o TTFB, o que melhora diretamente o LCP. A maioria dos provedores de hospedagem WordPress gerenciados de qualidade (Kinsta, SiteGround, WP Engine, Cloudways) inclui cache em nível de servidor. Se o seu não possui, instale um plugin de cache.

Também configure uma CDN para entregar páginas em cache a partir de localizações edge mais próximas aos seus visitantes. Veja como configurar a Cloudflare para performance.

Corrigindo o INP no WordPress

A Interaction to Next Paint mede com que rapidez o seu site responde a cliques, toques e pressões de teclas. Os sites WordPress falham no INP devido ao excesso de JavaScript na thread principal. As maiores causas:

O Problema de JavaScript dos Plugins

Cada plugin instalado pode adicionar JavaScript que executa em cada carregamento de página. Mesmo se um visitante nunca interagir com um recurso, o JavaScript para aquele recurso ainda compete pelo tempo da thread principal. Quando um visitante clica num botão, o navegador não pode responder até que a thread principal esteja livre.

Audite os seus plugins de forma implacável. Para cada plugin, pergunte: ele precisa ser carregado neste tipo de página? Use a aba Cobertura do Chrome DevTools para ver quanto de JavaScript não é utilizado em cada página. Depois, use um plugin de gerenciamento de scripts para desativar scripts específicos nas páginas onde eles não são necessários.

Gerenciamento de Scripts do WooCommerce

O WooCommerce é um dos maiores contribuintes para problemas de INP no WordPress. Por padrão, o WooCommerce carrega o seu JavaScript e CSS em todas as páginas, incluindo posts de blog e páginas estáticas que não possuem funcionalidade de comércio. Use um plugin como Disable WooCommerce Bloat ou Perfmatters para evitar que os recursos do WooCommerce sejam carregados em páginas que não são de loja.

Defer e Delay para Scripts de Terceiros

Google Analytics, Facebook Pixel, Google Tag Manager, widgets de chat e ferramentas de marketing adicionam JavaScript que bloqueia a thread principal. A estratégia mais eficaz é atrasar (delay) esses scripts até a primeira interação do usuário (rolagem, clique ou pressionamento de tecla). Dessa forma, os scripts de terceiros não afetam a responsividade inicial da página de forma alguma.

O recurso "Delay JavaScript Execution" do WP Rocket faz isso automaticamente. Você também pode implementá-lo manualmente com nosso guia sobre como adiar JavaScript.

Corrigindo o CLS no WordPress

O Cumulative Layout Shift mede movimentos inesperados de conteúdo. Os sites WordPress falham no CLS devido à falta de dimensões nas imagens, troca de fontes e conteúdo injetado dinamicamente.

Defina as Dimensões das Imagens

Cada tag <img> precisa de atributos explícitos de width e height para que o navegador possa reservar o espaço correto antes que a imagem carregue. O WordPress adiciona isso automaticamente desde a versão 5.5, mas muitos temas substituem esse comportamento ou usam marcação de imagem personalizada que omite as dimensões. Verifique os templates de imagem do seu tema e certifique-se de que as dimensões estejam presentes.

Reserve Espaço para Anúncios e Conteúdo Dinâmico

Espaços de anúncios, banners de consentimento de cookies, popups de inscrição de e-mail e barras de notificação que injetam conteúdo após o carregamento da página são as causas mais comuns de CLS em sites WordPress. Reserve espaço explícito para esses elementos usando declarações CSS min-height para que o conteúdo ao redor não mude de lugar quando eles aparecerem.

Corrija a Mudança de Layout Relacionada às Fontes

Quando uma web font carrega e substitui a fonte de fallback, o texto pode refluir e deslocar os elementos ao redor. A solução é dupla: hospede suas fontes localmente (self-host) (eliminando a pesquisa de DNS externo) e configure seu CSS para usar font-display: optional ou uma fallback cuidadosamente ajustada usando a propriedade CSS size-adjust. Dessa forma, mesmo que a web font carregue tarde, o texto não sofrerá mudanças de layout. Para um guia completo, veja o nosso guia de otimização de CLS.

Hospedagem WordPress e o Core Web Vitals

O seu provedor de hospedagem define o teto de performance do seu site WordPress. Veja como os principais tipos de hospedagem afetam o Core Web Vitals:

Se o seu TTFB estiver consistentemente acima de 400ms, nenhuma quantidade de otimização de frontend fará com que você consiga um bom LCP. Faça o upgrade da sua hospedagem primeiro. Hospedagens WordPress gerenciadas, como SiteGround, Kinsta e Cloudways, oferecem cache no nível do servidor, PHP 8.x e integração com CDN que reduzem drasticamente o TTFB.

Dados do CrUX confirmam que esse é o maior problema do WordPress: apenas 32% dos sites WordPress têm um bom TTFB, comparado a plataformas totalmente hospedadas como Shopify e Wix, onde a infraestrutura é gerenciada. Dados de campo do CoreDash mostram o mesmo padrão. Sites WordPress em hospedagem compartilhada possuem uma média de TTFB p75 de 900ms a 1400ms. O mesmo site migrado para uma hospedagem gerenciada com cache no nível do servidor cai para 120ms a 250ms. Essa única mudança muitas vezes move o LCP de "pobre" para "bom" sem qualquer outra otimização.

Page Builders: Performance Comparada

Sua escolha de page builder (ou a não utilização de um) é a maior decisão de arquitetura que afeta o Core Web Vitals no WordPress. Aqui está o que eu vejo consistentemente em minhas auditorias:

Se você já está usando Elementor ou Divi e não pode migrar, ative os recursos "Optimized DOM Output" e "Optimized Asset Loading", remova widgets e animações não utilizados e use um plugin de cache como WP Rocket para compensar a sobrecarga extra.

Dados de campo do CoreDash de sites WordPress contam a mesma história. Sites construídos com Gutenberg e temas leves alcançam consistentemente um LCP mobile mediano inferior a 2.0 segundos. Sites em Elementor antes da otimização normalmente mostram um LCP mobile mediano de 3.8 a 5.2 segundos, com a diferença sendo quase que inteiramente atribuída a recursos CSS e JavaScript adicionais que bloqueiam a renderização. Após a otimização (CSS crítico, JS adiado, DOM reduzido), sites em Elementor podem alcançar 2.0 a 2.8 segundos, mas eles requerem manutenção contínua, pois atualizações de plugins e do construtor frequentemente reintroduzem inchaço (bloat).

O Checklist de Otimização do Core Web Vitals para WordPress

Aqui está a abordagem sistemática que uso ao otimizar sites WordPress para o Core Web Vitals. Siga esses passos em ordem:

Infraestrutura (faça isso primeiro)

• Atualize para uma hospedagem WordPress gerenciada com cache de servidor e PHP 8.x
• Configure uma CDN (guia de configuração da Cloudflare)
• Ative o cache de página (no nível do servidor ou via WP Rocket / LiteSpeed Cache)
• Ative a compressão GZIP ou Brotli

Tema e Construtor

• Mude para um tema leve (GeneratePress, Astra, Kadence) se possível
• Se usar um page builder, ative a saída otimizada de DOM e o carregamento de recursos
• Remova recursos de tema, widgets e animações não utilizados
• Atualize o core do WordPress, o tema e todos os plugins para as versões mais recentes

Imagens

• Faça o preload da imagem LCP com fetchpriority="high"
• Converta imagens para WebP ou AVIF usando ShortPixel, Imagify ou Smush
• Sirva imagens responsivas com os atributos adequados srcset e sizes
• Adicione width e height explícitos a todas as tags <img>
• NÃO aplique lazy load em imagens above the fold (isso prejudica o LCP)

JavaScript e CSS

• Adie (defer) o JavaScript não crítico
• Atrase scripts de terceiros até que ocorra uma interação do usuário
• Gere e insira inline o CSS crítico
• Remova scripts de plugins não utilizados por página usando o Perfmatters ou o Asset CleanUp
• Desative os recursos do WooCommerce em páginas que não são de loja

Fontes

• Hospede localmente o Google Fonts
• Faça o preload dos arquivos de fonte críticos
• Use font-display: swap ou optional
• Limite a um máximo de 2 famílias de fontes

Monitoramento

• Configure o Monitoramento de Usuários Reais do CoreDash para rastrear dados de campo continuamente
• Monitore o relatório do Core Web Vitals no Google Search Console semanalmente
• Teste novamente após cada atualização de tema, mudança de plugin ou atualização de conteúdo

Para o checklist completo multiplataforma cobrindo todas as áreas de otimização, veja o nosso Ultimate Core Web Vitals Checklist.

Medindo o Core Web Vitals no WordPress

O WordPress não possui relatórios integrados do Core Web Vitals. Você precisa de ferramentas externas para medir a sua performance:

• Google Search Console: mostra quais páginas passam ou falham em todo o seu site, com base em dados de campo reais do CrUX. Verifique o relatório "Principais métricas da Web" (Core Web Vitals) na seção "Experiência".
• PageSpeed Insights: testa URLs individuais com dados de campo (CrUX) e dados de laboratório (Lighthouse). Use isso para diagnosticar páginas específicas.
• CoreDash: Monitoramento de Usuários Reais (RUM) que fornece dados de campo em tempo real, divididos por página, dispositivo, país e elementos individuais. Ao contrário da janela móvel de 28 dias do CrUX, o CoreDash mostra o impacto imediato das suas mudanças.
• Chrome DevTools: use o painel de Performance para identificar tarefas longas que bloqueiam o INP e a aba Cobertura para encontrar JavaScript e CSS não utilizados.

Para uma comparação completa dessas ferramentas, confira a nossa visão geral do Core Web Vitals, que inclui uma tabela de comparação de ferramentas de medição.

Erros Comuns de Core Web Vitals no WordPress

Em minha experiência auditando centenas de sites WordPress, estes são os erros que vejo com mais frequência:

• Fazer lazy load da imagem LCP. O WordPress adiciona loading="lazy" às imagens por padrão. Se a sua hero image for o elemento LCP, fazer lazy load dela atrasa o seu carregamento. Certifique-se de que a imagem LCP seja excluída do lazy loading e que possua fetchpriority="high".
• Muitos plugins de otimização. Instalar WP Rocket, Autoptimize, LiteSpeed Cache e W3 Total Cache simultaneamente cria conflitos. Escolha um plugin de cache/otimização e configure-o corretamente.
• Ignorar dados de campo. Uma pontuação de 95 no Lighthouse não significa que você passou no Core Web Vitals. O Google usa dados de campo de visitantes reais. Seus visitantes reais em dispositivos reais podem ter uma experiência completamente diferente. Verifique sempre o Search Console ou use RUM.
• Não testar após atualizações. Uma atualização de tema ou plugin pode regredir silenciosamente os seus Core Web Vitals. Monitore continuamente, e não apenas após a otimização inicial.