Audité centenas de sites WordPress ao longo dos anos, e a conversa geralmente começa do mesmo jeito: "Instalamos um plugin de cache, mas nossos scores ainda são terríveis." A verdade que ninguém no ecossistema WordPress quer admitir é que a maioria dos problemas de performance não é solucionável com plugins. São arquiteturais. WordPress foi construído em 2003 para renderizar posts de blog com PHP. Estamos em 2025, e estamos pedindo para ele alimentar sites de marketing complexos, plataformas de e-commerce e aplicações web — tudo enquanto as Core Web Vitals do Google determinam cada vez mais se alguém realmente encontra seu conteúdo.

Este artigo decompõe exatamente por que sites WordPress são lentos, mapeia cada problema para as métricas de Core Web Vitals que sofrem, e mostra como uma arquitetura headless com Next.js os resolve na raiz. Não com gambiarras. Na raiz.

Índice

• Entendendo Core Web Vitals em 2025
• Por Que WordPress é Arquiteturalmente Lento
• Plugin Bloat: O Assassino Silencioso de Performance
• Problemas de Database Query Que Plugins Não Conseguem Resolver
• Hospedagem WordPress: Você Provavelmente Está Pagando Demais por Mediocridade
• Como Next.js Resolve Cada Core Web Vital
• A Arquitetura Headless: WordPress como CMS, Next.js como Frontend
• Benchmarks Reais de Performance: WordPress vs Next.js
• Caminho de Migração: De WordPress Monolítico para Headless Next.js
• FAQ

Entendendo Core Web Vitals em 2025

Google atualizou suas Core Web Vitals em março de 2024, substituindo First Input Delay (FID) por Interaction to Next Paint (INP). Essa mudança importa mais do que a maioria das pessoas percebe. Aqui estão as quatro métricas que determinam a nota de performance do seu site:

Métrica	O Que Mede	Bom	Precisa Melhorar	Ruim
LCP (Largest Contentful Paint)	Quão rápido seu conteúdo principal carrega	≤ 2.5s	2.5s – 4.0s	> 4.0s
INP (Interaction to Next Paint)	Responsividade ao input do usuário	≤ 200ms	200ms – 500ms	> 500ms
CLS (Cumulative Layout Shift)	Estabilidade visual durante o carregamento	≤ 0.1	0.1 – 0.25	> 0.25
TTFB (Time to First Byte)	Tempo de resposta do servidor	≤ 800ms	800ms – 1800ms	> 1800ms

De acordo com o Chrome UX Report do início de 2025, apenas 42% dos origins WordPress passam em todos os três limites de Core Web Vitals. Compare isso com 67% para origins com Next.js. Não é uma diferença marginal — é uma liga diferente.

Por Que Essas Métricas Realmente Importam

Google foi claro: Core Web Vitals são um sinal de ranking. Mas além de SEO, essas métricas correlacionam diretamente com taxas de conversão. A Vodafone descobriu que uma melhoria de 31% em LCP levou a um aumento de 8% em vendas. Os dados internos do Shopify mostram que cada redução de 100ms no tempo de carregamento da página aumenta a conversão em 1.3%.

Seu site WordPress não é apenas lento. Ele está te fazendo perder dinheiro.

Por Que WordPress é Arquiteturalmente Lento

Deixa eu te passar pelo que acontece quando alguém visita uma página WordPress típica:

1. DNS lookup → resolve seu domínio
2. TCP/TLS handshake → estabelece conexão segura
3. Request atinge o servidor → Apache/Nginx recebe
4. PHP faz bootstrap do WordPress → carrega wp-config.php, inicializa o core do WordPress
5. Plugin initialization → cada plugin ativo se prende ao init, wp_loaded, etc.
6. Tema carrega → functions.php roda, hierarquia de templates é resolvida
7. Database queries executam → WP_Query roda, frequentemente 30-100+ queries por página
8. PHP renderiza HTML → arquivos de template geram a página completa
9. HTML é enviado para o navegador → finalmente, a resposta começa
10. Navegador faz parse do HTML → descobre CSS, JS, fonts, imagens
11. Recursos que bloqueiam render carregam → folhas de estilo de 15 plugins diferentes
12. Página finalmente renderiza → usuário vê o conteúdo

Os passos 4 até 9 acontecem em cada request sem cache. Isso significa PHP parseando 200+ arquivos, executando dezenas de database queries, e gerando HTML — tudo antes do navegador receber um único byte.

O Problema do PHP

PHP 8.3 é significativamente mais rápido que PHP 7.x, e a maioria dos hosts WordPress agora o suporta. Mas mesmo com PHP 8.3 e OPcache habilitado, você ainda está rodando um processo síncrono e bloqueante. O core do WordPress sozinho carrega aproximadamente 100.000 linhas de código PHP a cada request. Adicione WooCommerce e você passa de 400.000 linhas.

Aqui está a coisa: plugins de cache como WP Super Cache ou W3 Total Cache funcionam ao contornar esse processo — eles servem um arquivo HTML pré-gerado em vez disso. Mas introduzem sua própria complexidade, quebram com conteúdo personalizado, e ainda assim não conseguem consertar o que acontece no navegador.

O Problema do Tema

A maioria dos temas WordPress é construída para flexibilidade, não para performance. Um tema como Avada, Divi ou Elementor carrega todo seu CSS e JavaScript framework em cada página, independente de você usar ou não essas features. Já vi sites Elementor carregando 2.5MB de CSS e 1.8MB de JavaScript em um simples post de blog.

<!-- Head típico do WordPress em um site page-builder -->
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor-pro/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/theme.min.css">
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... 12 mais stylesheets -->

Cada um desses é um recurso que bloqueia render. Seu LCP não consegue acontecer até que todos sejam baixados e parseados.

Plugin Bloat: O Assassino Silencioso de Performance

O site WordPress médio roda 20-30 plugins. Já vi sites com 70+. Cada plugin potencialmente:

• Adiciona seus próprios arquivos CSS e JS (frequentemente em cada página, mesmo onde não usados)
• Registra WordPress hooks que executam em cada request
• Roda suas próprias database queries
• Carrega seus próprios arquivos PHP durante a fase de bootstrap
• Adiciona scripts e estilos inline ao <head>

Um Exemplo Real

Recentemente auditei um site de marketing rodando WordPress com 34 plugins ativos. Aqui está como o network waterfall ficou:

• 47 arquivos CSS carregados na homepage
• 38 arquivos JavaScript carregados na homepage
• Peso total da página: 4.7MB
• Total de requests: 127
• LCP: 6.8 segundos em 4G
• TTFB: 2.1 segundos

O cliente já tinha instalado um plugin de otimização (Autoptimize) e um plugin de cache (LiteSpeed Cache). Mesmo com ambos ativos, LCP era 4.2 segundos. Ainda falhando.

O problema central? Você não consegue otimizar para longe do problema fundamental de carregar código que você não precisa. Minificar e combinar 47 arquivos CSS ainda deixa você com um payload CSS massivo que bloqueia rendering.

A Armadilha de Dependência de Plugins

Aqui está o que torna isso pior: plugins dependem de outros plugins. Você instala WooCommerce, daí precisa de um plugin de gateway de pagamento, daí um plugin de calculadora de shipping, daí um plugin de filtro de produtos. Cada um adiciona peso. Você não consegue remover nenhum deles sem quebrar funcionalidade.

Essa é a armadilha do WordPress. A arquitetura encoraja adicionar plugins para tudo, e não há mecanismo para tree-shake código não usado.

Problemas de Database Query Que Plugins Não Conseguem Resolver

WordPress usa um único banco de dados MySQL com um schema notoriamente flat. A tabela wp_options é carregada com entradas autoload='yes' em cada request. Já vi tabelas wp_options com 3.000+ linhas com autoload totalizando 8MB de dados.

-- Verifique o tamanho de suas opções autoloaded
SELECT SUM(LENGTH(option_value)) as autoload_size 
FROM wp_options 
WHERE autoload = 'yes';

-- Se isso retornar > 1MB, você tem um problema

A tabela wp_postmeta é outro pesadelo. Ela armazena tudo como pares chave-valor, o que significa que WordPress não consegue fazer queries eficientes. Quer encontrar todos os produtos menores que $50? Isso é um JOIN em wp_postmeta com uma comparação de string em um campo text que armazena um número. Nenhum índice consegue te salvar.

Verificação de Realidade de Query Count

Instale o plugin Query Monitor em seu site WordPress e olhe o query count. Uma página de produto WooCommerce "simples" tipicamente roda 150-300 database queries. Um post de blog com posts relacionados, sidebar de posts populares, e breadcrumbs? Geralmente 80-120 queries.

Compare isso com uma abordagem headless onde seu frontend Next.js faz exatamente uma chamada de API (ou zero, se usando geração estática) para obter todos os dados que precisa.

Hospedagem WordPress: Você Provavelmente Está Pagando Demais por Mediocridade

Vamos conversar sobre hospedagem, porque aqui é onde muito dinheiro é desperdiçado.

Tipo de Hospedagem	Custo Mensal	TTFB Típico	Consegue Consertar Arquitetura?
Shared (GoDaddy, Bluehost)	$3-15	1.5-4.0s	Não
Managed WordPress (WP Engine, Flywheel)	$25-300	400ms-1.2s	Não
Premium Managed (Kinsta, Pagely)	$35-600	200ms-600ms	Não
VPS/Dedicated (DigitalOcean, AWS)	$20-500	200ms-800ms	Não
Next.js em Vercel/Edge	$0-20	50-150ms	Sim

Repare nessa última coluna. Nenhuma quantidade de upgrade de hospedagem conserta os problemas arquiteturais. Você está pagando preços premium para fazer PHP rodar mais rápido, quando a solução real é não rodar PHP em cada request.

Kinsta cobra $35/mês pelo plano starter com 25.000 visitas. O tier gratuito da Vercel manipula 100GB de bandwidth. Até o plano Pro da Vercel por $20/mês te dá edge deployment através de seu CDN global. A matemática não mente.

Como Next.js Resolve Cada Core Web Vital

Vamos ser específicos. Aqui está como Next.js (especialmente com o App Router no Next.js 14/15) aborda cada métrica:

Consertando TTFB

Next.js te dá múltiplas estratégias de rendering:

// Static Generation - TTFB efetivamente zero (servido de CDN)
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  return <Article post={post} />;
}

// Isso pré-renderiza no build time
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Com geração estática, suas páginas são arquivos HTML pré-construídos servidos de edge CDN nodes pelo mundo. TTFB cai para 50-100ms independente de onde seus usuários estão. Sem execução PHP, sem database queries, sem processamento server-side em tempo de request.

Para conteúdo dinâmico, Next.js suporta ISR (Incremental Static Regeneration), que serve páginas estáticas em cache enquanto revalida no background:

// Revalida a cada 60 segundos
export const revalidate = 60;

Consertando LCP

Next.js inclui o componente <Image> que manipula tudo que plugins do WordPress tentam (e falham) fazer:

import Image from 'next/image';

export default function HeroBanner() {
  return (
    <Image
      src="/hero.jpg"
      alt="Hero banner"
      width={1200}
      height={600}
      priority // Faz preload da imagem LCP
      sizes="100vw"
      // Gera automaticamente srcset, usa WebP/AVIF,
      // lazy loads por padrão, previne CLS
    />
  );
}

A prop priority diz para Next.js fazer preload da imagem, melhorando diretamente LCP. A negociação de formato automática serve WebP ou AVIF para navegadores suportados, reduzindo tamanho de imagem em 30-50% comparado a JPEG. Nenhum plugin necessário.

Next.js também elimina CSS que bloqueia render através de CSS Modules e extração automática de CSS crítico. Apenas o CSS usado em uma página específica é carregado.

Consertando INP

INP mede quão rápido seu site responde a interações do usuário. Sites WordPress falham em INP por causa de:

• JavaScript pesado de plugins bloqueando a main thread
• jQuery e seus plugins competindo por tempo de execução
• Sem code splitting — tudo carrega antecipadamente

Next.js manipula isso com code splitting automático. Cada página carrega apenas o JavaScript que precisa:

// Esse componente carrega apenas quando o usuário rola para ele
import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
  loading: () => <ChartSkeleton />,
  ssr: false, // Não renderize no servidor
});

React Server Components (padrão no App Router) vão ainda mais longe: componentes que não precisam de interatividade enviam zero JavaScript para o navegador. Um post de blog sem elementos interativos? Zero KB de JavaScript de componente.

Consertando CLS

CLS em WordPress geralmente vem de:

• Imagens sem dimensões explícitas
• Anúncios carregando tardiamente e empurrando conteúdo para baixo
• Web fonts causando FOUT/FOIT
• Banners injetados por plugins aparecendo após o carregamento

Next.js previne CLS por padrão. O componente <Image> requer dimensões (ou usa fill com um container dimensionado). O módulo next/font inlina declarações de fonte e usa font-display: swap com zero layout shift:

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'] });

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

Sem FOUT. Sem layout shift de fonts. Funciona.

A Arquitetura Headless: WordPress como CMS, Next.js como Frontend

Aqui está a parte que muita gente perde: ir headless não significa abandonar WordPress. Significa usar WordPress para o que é realmente bom — gerenciamento de conteúdo — enquanto deixa Next.js manipular o frontend.

A arquitetura fica assim:

[Admin WordPress] → [REST API / WPGraphQL] → [Frontend Next.js] → [Vercel Edge CDN]
     ↑                                              ↑
  Editores de conteúdo                        Seus usuários
  usam o familiar                            recebem páginas rápidas
  dashboard WP                                servidas de edge

Seu time de conteúdo mantém seu workflow. Seus usuários conseguem um site rápido. Você consegue código limpo e mantível.

Fazemos muito esse tipo de trabalho em nossa prática de desenvolvimento Next.js e desenvolvimento de headless CMS. O padrão é bem estabelecido e testado em produção.

E Sobre Outras Opções de Headless CMS?

WordPress não é a única opção para a camada de conteúdo. Se você está começando do zero, plataformas headless CMS propositais como Sanity, Contentful, ou Storyblok são frequentemente melhores escolhas. Elas são construídas API-first, então não há bagagem legada.

Mas se você tem anos de conteúdo em WordPress e um time treinado nele, WordPress headless com WPGraphQL é uma abordagem perfeitamente válida.

Benchmarks Reais de Performance: WordPress vs Next.js

Aqui estão números reais de migrações que fizemos e case studies publicamente disponíveis:

Métrica	WordPress (Otimizado)	Next.js (Estático)	Melhoria
TTFB	650ms	80ms	87% mais rápido
LCP	3.8s	1.2s	68% mais rápido
INP	380ms	90ms	76% mais rápido
CLS	0.18	0.01	94% melhor
Peso da Página	3.2MB	450KB	86% mais leve
Requests	85	12	86% menos
Lighthouse Score	45-65	95-100	Noite e dia

"Otimizado" WordPress significa: PHP 8.3, Redis object cache, CDN, plugin de otimização de imagem, plugin de cache, otimização de database. Todas as coisas que você deveria fazer. E ainda assim não é nem perto.

Caminho de Migração: De WordPress Monolítico para Headless Next.js

A migração não precisa ser tudo-ou-nada. Aqui está a abordagem faseada que normalmente recomendamos:

Fase 1: Avaliação (1-2 semanas)

• Audite a performance do site WordPress atual com PageSpeed Insights e dados de CrUX
• Faça inventário de todos os plugins e mapeie para funcionalidade frontend vs. backend
• Identifique modelos de conteúdo e campos customizados
• Avalie se mantém WordPress como CMS headless ou migra conteúdo completamente

Fase 2: Frontend Build (4-8 semanas)

• Configure projeto Next.js com o App Router
• Instale e configure WPGraphQL em WordPress
• Construa component library que corresponda ao design atual (ou redesenhe — é bom fazer)
• Implemente geração estática para páginas de conteúdo
• Configure modo preview para editores de conteúdo

Fase 3: Launch e Redirect (1-2 semanas)

• Implante frontend Next.js em Vercel (ou Netlify, ou Cloudflare Pages)
• Configure DNS e redirects
• Verifique que todas as URLs são propriamente redirecionadas (preservação de SEO é crítica)
• Bloqueie o admin WordPress (remova acesso público)

Fase 4: Otimização (contínua)

• Monitore Core Web Vitals em Google Search Console
• Fine-tune intervalos de revalidação de ISR
• Adicione edge middleware para personalização
• Considere migrar para um CMS headless propositado se WordPress se torna um gargalo

Se você está considerando esse tipo de migração, pode conferir nossa pricing page para números aproximados, ou nos contate diretamente para discutir sua situação específica.

Para sites construídos com Astro em vez de Next.js (particularmente blogs e sites de marketing com conteúdo pesado), também temos uma prática de desenvolvimento Astro que entrega performance ainda mais agressiva para sites static-first.

FAQ

Consigo acelerar WordPress sem mudar para Next.js? Sim, até um ponto. Comece com um host de qualidade (Kinsta ou Cloudways), habilite cache de objeto Redis, use um tema leve como GeneratePress, reduza plugins para menos de 15, e configure um CDN. Você consegue colocar um site WordPress na faixa de "precisa melhorar" para Core Web Vitals dessa forma. Mas quebrar na faixa de "bom" consistentemente em todas as métricas — especialmente INP — é extremamente difícil com uma arquitetura WordPress tradicional.

Quanto custa migrar de WordPress para headless Next.js? Depende da complexidade do site. Um site de marketing simples (10-30 páginas, blog) tipicamente roda $15,000-$40,000 para uma migração completa. Sites de e-commerce com WooCommerce são mais envolvidos, variando de $50,000-$150,000+. O ROI geralmente vem de taxas de conversão melhoradas e custos de hospedagem reduzidos. Nossa pricing page tem mais detalhes.

Meus rankings de SEO vão cair se eu mudar para Next.js? Não se você manipular a migração propriamente. 301 redirects adequados, estruturas de URL idênticas (ou redirects mapeados), meta tags válidas, dados estruturados, e um XML sitemap são todos essenciais. Next.js na verdade tem vantagens de SEO — Core Web Vitals mais rápidas melhoram diretamente rankings, e a Metadata API torna fácil gerenciar meta tags programaticamente. A maioria dos sites vê melhorias de ranking dentro de 2-3 meses da migração.

Editores de conteúdo perdem o admin WordPress se formos headless? Não. Em uma setup headless, WordPress continua servindo como backend de gerenciamento de conteúdo. Editores usam o mesmo dashboard, o mesmo editor, o mesmo workflow. Eles simplesmente não veem mais o tema frontend — em vez disso, usam um botão de preview que mostra a versão renderizada em Next.js. Alguns times acham que isso é na verdade melhor porque o preview é uma representação precisa do site em produção.

E sobre WooCommerce — Next.js consegue manipular e-commerce? Sim, mas é um projeto maior. Você consegue usar WooCommerce headlessly via sua REST API ou extensão WPGraphQL WooCommerce. Alternativamente, muitos times migram para a Storefront API do Shopify ou Saleor para o backend de comércio, usando Next.js como o frontend. O checkout flow requer cuidado especial já que envolve processamento de pagamento e conformidade com PCI. É viável, mas planeje por tempo de desenvolvimento extra.

Next.js é a única opção para um frontend rápido? Não. Astro, Remix, SvelteKit, e até Nuxt (para times Vue) são todos viáveis. Astro em particular é excelente para sites com conteúdo pesado porque envia zero JavaScript por padrão. Next.js vence para sites que precisam de significativa interatividade, features dinâmicas, ou e-commerce. Trabalhamos com ambos Next.js e Astro dependendo das necessidades do projeto.

Como Incremental Static Regeneration (ISR) funciona com conteúdo WordPress? Quando você publica ou atualiza um post em WordPress, um webhook dispara e diz à sua implantação Next.js para revalidar essa página específica. O próximo visitante recebe uma página estática recém-gerada, que é então cacheada na edge. A revalidação acontece no background, então usuários nunca esperam por um build. Você também pode definir revalidação baseada em tempo (ex., rebuild a cada 60 segundos) como fallback.

Qual é o maior erro que times cometem ao ir headless? Tentar replicar seu site WordPress 1:1 em Next.js. Uma migração headless é uma oportunidade para repensar sua arquitetura de conteúdo, simplificar suas estruturas de página, e eliminar anos de cruft acumulado. Times que a tratam como um fresh start — mantendo o conteúdo mas repensando a apresentação — acabam com resultados dramaticamente melhores que times que tentam copiar cada widget e sidebar de seu antigo tema.