Seu visitante chega na sua homepage do WordPress e espera. O servidor inicializa PHP, consulta o banco de dados dezessete vezes, executa funções do tema, carrega hooks de plugins, renderiza o DOM e, finalmente, pinta o texto — 2,8 segundos após o clique. Você já instalou três plugins de cache. Seu LCP ainda fica em 3,1 segundos, seu CLS alterna layout conforme as fontes mudam, e o Google Search Console continua sinalizando as mesmas falhas de Core Web Vitals. O problema não é sua hospedagem ou seu CDN. WordPress foi arquitetado em 2003 para renderizar posts de blog com PHP no servidor a cada requisição. Duas décadas depois, você está pedindo ao mesmo runtime para alimentar sites de marketing, plataformas de e-commerce e web apps — enquanto o algoritmo de Core Web Vitals do Google decide se alguém encontra seu conteúdo. Nenhum plugin consegue reescrever o modelo de execução, mas uma migração para Next.js consegue. Aqui está o detalhamento técnico do que está quebrando e os padrões exatos que corrigem.

Este artigo detalha 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 Next.js corrige na raiz. Não com gambiarras. Na raiz.

Índice

Por Que Seu Site WordPress É Lento e Como Next.js Corrige

Entendendo Core Web Vitals em 2026

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

Métrica O Que Mede Bom Precisa de Melhoria Ruim
LCP (Largest Contentful Paint) Velocidade de carregamento do seu conteúdo principal ≤ 2,5s 2,5s – 4,0s > 4,0s
INP (Interaction to Next Paint) Responsividade à entrada do usuário ≤ 200ms 200ms – 500ms > 500ms
CLS (Cumulative Layout Shift) Estabilidade visual durante 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 2026, apenas 42% das origens WordPress passam em todos os três limites de Core Web Vitals. Compare isso com 67% para origens alimentadas por 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 fator de ranking. Mas além de SEO, estas métricas se correlacionam diretamente com taxas de conversão. Vodafone descobriu que uma melhoria de 31% no LCP levou a um aumento de 8% nas vendas. Os dados internos do Shopify mostram que cada redução de 100ms no tempo de carregamento aumenta a conversão em 1,3%.

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

Por Que WordPress É Arquitetonicamente Lento

Vou te guiar pelo que acontece quando alguém visita uma página WordPress típica:

  1. Busca DNS → resolve seu domínio
  2. Handshake TCP/TLS → estabelece conexão segura
  3. Requisição chega no servidor → Apache/Nginx recebe
  4. PHP inicializa WordPress → carrega wp-config.php, inicializa o núcleo WordPress
  5. Inicialização de plugins → cada plugin ativo liga-se a init, wp_loaded, etc.
  6. Tema carrega → functions.php é executado, hierarquia de template se resolve
  7. Consultas ao banco de dados executam → WP_Query executa, frequentemente 30-100+ consultas por página
  8. PHP renderiza HTML → arquivos de template geram a página completa
  9. HTML enviado ao navegador → finalmente, a resposta começa
  10. Navegador analisa HTML → descobre CSS, JS, fontes, imagens
  11. Recursos bloqueadores de renderização carregam → folhas de estilo de 15 plugins diferentes
  12. Página finalmente renderiza → usuário vê conteúdo

Os passos 4 até 9 acontecem em cada requisição não armazenada em cache. Isso é PHP analisando 200+ arquivos, executando dúzias de consultas ao banco de dados 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 suporta. Mas mesmo com PHP 8.3 e OPcache habilitado, você ainda está executando um processo síncrono e bloqueante. O núcleo WordPress sozinho carrega aproximadamente 100.000 linhas de código PHP em cada requisição. Adicione WooCommerce e você passa de 400.000 linhas.

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

O Problema do Tema

A maioria dos temas WordPress são construídos para flexibilidade, não performance. Um tema como Avada, Divi ou Elementor carrega seu framework inteiro de CSS e JavaScript em cada página, independente se você usa essas funcionalidades ou não. 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 com 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">
<!-- ... mais 12 folhas de estilo -->

Cada uma delas é um recurso bloqueador de renderização. Seu LCP não consegue acontecer até que todos sejam baixados e analisados.

Plugin Bloat: O Assassino Silencioso de Performance

O site WordPress médio executa 20-30 plugins. Vi sites com 70+. Cada plugin potencialmente:

  • Adiciona seus próprios arquivos CSS e JS (frequentemente em cada página, até onde não usados)
  • Registra hooks WordPress que executam em cada requisição
  • Executa suas próprias consultas ao banco de dados
  • Carrega seus próprios arquivos PHP durante a fase de bootstrap
  • Adiciona scripts e estilos inline ao <head>

Um Exemplo Real

Auditei recentemente um site de marketing executando WordPress com 34 plugins ativos. Aqui está como o waterfall de rede se parecia:

  • 47 arquivos CSS carregados na homepage
  • 38 arquivos JavaScript carregados na homepage
  • Peso total da página: 4,7MB
  • Total de requisições: 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 longe do problema fundamental de carregar código que não precisa. Minificar e combinar 47 arquivos CSS ainda deixa você com um payload de CSS massivo que bloqueia a renderização.

A Armadilha de Dependência de Plugins

Aqui está o que piora tudo isso: plugins dependem de outros plugins. Você instala WooCommerce, depois precisa de um plugin de gateway de pagamento, depois um plugin de calculadora de envio, depois um plugin de filtro de produto. Cada um adiciona peso. Você não consegue remover nenhum sem quebrar funcionalidade.

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

Por Que Seu Site WordPress É Lento e Como Next.js Corrige - arquitetura

Problemas de Consultas ao Banco de Dados Que Plugins Não Conseguem Corrigir

WordPress usa um único banco de dados MySQL com um esquema notoriamente flat. A tabela wp_options é carregada com entradas autoload='yes' em cada requisição. Vi tabelas wp_options com 3.000+ linhas autocarregadas totalizando 8MB de dados.

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

-- Se isto retorna > 1MB, você tem um problema

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

Verificação de Contagem de Consultas Real

Instale o plugin Query Monitor no seu site WordPress e observe o número de consultas. Uma página de produto WooCommerce "simples" normalmente executa 150-300 consultas ao banco de dados. Um post de blog com posts relacionados, sidebar de posts populares e breadcrumbs? Geralmente 80-120 consultas.

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

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

Vamos falar sobre hospedagem, porque é aqui que muito dinheiro é desperdiçado.

Tipo de Hospedagem Custo Mensal TTFB Típico Consegue Corrigir Arquitetura?
Compartilhada (GoDaddy, Bluehost) $3-15 1,5-4,0s Não
WordPress Gerenciado (WP Engine, Flywheel) $25-300 400ms-1,2s Não
Premium Gerenciado (Kinsta, Pagely) $35-600 200ms-600ms Não
VPS/Dedicado (DigitalOcean, AWS) $20-500 200ms-800ms Não
Next.js em Vercel/Edge $0-20 50-150ms Sim

Note aquela última coluna. Nenhum valor de upgrade de hospedagem corrige os problemas arquiteturais. Você está pagando preços premium para fazer PHP rodar mais rápido, quando a solução real é não executar PHP em cada requisição.

Kinsta cobra $35/mês pelo plano iniciante com 25.000 visitas. O tier gratuito da Vercel lida com 100GB de banda. Até o plano Pro da Vercel a $20/mês oferece implantação edge através de seu CDN global. A matemática não mente.

Como Next.js Corrige 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:

Corrigindo TTFB

Next.js oferece múltiplas estratégias de renderização:

// Geração Estática - TTFB efetivamente zero (servido do CDN)
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  return <Article post={post} />;
}

// Isto pré-renderiza no tempo de build
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 nós CDN edge em todo o mundo. TTFB cai para 50-100ms independente de onde seus usuários estão. Sem execução PHP, sem consultas ao banco de dados, sem processamento no servidor no tempo de requisição.

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

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

Corrigindo LCP

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

import Image from 'next/image';

export default function HeroBanner() {
  return (
    <Image
      src="/hero.jpg"
      alt="Banner de herói"
      width={1200}
      height={600}
      priority // Precarrega a imagem LCP
      sizes="100vw"
      // Gera automaticamente srcset, usa WebP/AVIF,
      // carregamento lazy por padrão, previne CLS
    />
  );
}

A prop priority diz ao Next.js para pré-carregar a imagem, melhorando diretamente o LCP. A negociação de formato automática serve WebP ou AVIF aos navegadores que suportam, reduzindo tamanho de imagem em 30-50% comparado a JPEG. Nenhum plugin necessário.

Next.js também elimina CSS bloqueador de renderização 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.

Corrigindo INP

INP mede quão rapidamente seu site responde a interações do usuário. Sites WordPress falham em INP porque:

  • JavaScript pesado de plugins bloqueia a thread principal
  • jQuery e seus plugins competem por tempo de execução
  • Sem code splitting — tudo carrega antecipadamente

Next.js lida com isto através de code splitting automático. Cada página carrega apenas o JavaScript que precisa:

// Este componente só carrega quando o usuário rola até 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.

Corrigindo CLS

CLS no WordPress geralmente vem de:

  • Imagens sem dimensões explícitas
  • Anúncios carregando tarde e empurrando conteúdo para baixo
  • Web fonts causando FOUT/FOIT
  • Banners injetados por plugins aparecendo após 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 inliniza declarações de font 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="pt-BR" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

Sem FOUT. Sem layout shift de fontes. Funciona pronto.

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

Aqui está a parte que muitas pessoas perdem: ficar headless não significa abandonar WordPress. Significa usar WordPress para o que é realmente bom — gerenciamento de conteúdo — enquanto deixa Next.js lidar com o frontend.

A arquitetura se parece com isto:

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

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

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

E Quanto a Outras Opções de Headless CMS?

WordPress não é a única opção para a camada de conteúdo. Se estiver começando do zero, plataformas de headless CMS de propósito específico como Sanity, Contentful ou Storyblok frequentemente são melhores escolhas. Foram construídas API-first, então não há bagagem legada.

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

Benchmarks de Performance Real: 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
Requisições 85 12 86% menos
Pontuação Lighthouse 45-65 95-100 Diferença gritante

"Otimizado" significa WordPress: PHP 8.3, cache de objeto Redis, CDN, plugin de otimização de imagem, plugin de cache, otimização de banco de dados. Todas as coisas que você supostamente faz. E ainda assim não é próximo.

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

Migração não precisa ser tudo ou nada. Aqui está a abordagem faseada que típicamente recomendamos:

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

  • Auditar performance do site WordPress atual com PageSpeed Insights e dados CrUX
  • Inventariar todos os plugins e mapeá-los para funcionalidade frontend vs. backend
  • Identificar modelos de conteúdo e campos personalizados
  • Avaliar se manter WordPress como headless CMS ou migrar conteúdo completamente

Fase 2: Construção de Frontend (4-8 semanas)

  • Configurar projeto Next.js com o App Router
  • Instalar e configurar WPGraphQL no WordPress
  • Construir biblioteca de componentes correspondendo ao design atual (ou redesenhar — bom momento)
  • Implementar geração estática para páginas de conteúdo
  • Configurar modo preview para editores de conteúdo

Fase 3: Lançamento e Redirecionamento (1-2 semanas)

  • Implantar frontend Next.js em Vercel (ou Netlify ou Cloudflare Pages)
  • Configurar DNS e redirecionamentos
  • Verificar que todas as URLs são redirecionadas apropriadamente (preservação de SEO é crítica)
  • Trancar admin do WordPress (remover acesso público)

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

  • Monitorar Core Web Vitals no Google Search Console
  • Afinar intervalos de revalidação de ISR
  • Adicionar middleware de edge para personalização
  • Considerar migração para um headless CMS de propósito específico se WordPress se torna um gargalo

Se estiver considerando este tipo de migração, você pode verificar nossa página de preços para números aproximados, ou entrar em contato direto para discutir sua situação específica.

Para sites construídos com Astro em vez de Next.js (particularmente blogs e sites de marketing densos em conteúdo), 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é certo ponto. Comece com um host de qualidade (Kinsta ou Cloudways), ative cache de objeto Redis, use um tema leve como GeneratePress, reduza plugins para menos de 15 e configure um CDN. Você consegue levar um site WordPress para a faixa "precisa de melhoria" de Core Web Vitals dessa forma. Mas quebrar consistentemente para a faixa "bom" 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) normalmente custa $15.000-$40.000 para uma migração completa. Sites de e-commerce com WooCommerce são mais envolventes, variando de $50.000-$150.000+. O ROI geralmente vem de taxas de conversão melhoradas e custos de hospedagem reduzidos. Nossa página de preços tem mais detalhes.

Meus rankings de SEO vão cair se mudar para Next.js?

Não se você lidar com a migração apropriadamente. Redirecionamentos 301 apropriados, estruturas de URL idênticas (ou redirecionamentos mapeados), tags meta válidas, dados estruturados e um sitemap XML são essenciais. Next.js realmente tem vantagens de SEO — Core Web Vitals mais rápido melhora diretamente rankings, e a Metadata API torna fácil gerenciar meta tags programaticamente. A maioria dos sites vê melhoria de ranking dentro de 2-3 meses de migração.

Editores de conteúdo perdem o admin do WordPress se ficarmos headless?

Não. Em uma configuração 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 o tema frontend mais — em vez disso, usam um botão preview que mostra a versão renderizada em Next.js. Alguns times acham que isto é realmente melhor porque o preview é uma representação precisa do site em produção.

E quanto ao WooCommerce — Next.js consegue lidar com e-commerce?

Sim, mas é um projeto maior. Você consegue usar WooCommerce headlessly via sua REST API ou extensão WooCommerce WPGraphQL. Alternativamente, muitos times migram para a Storefront API do Shopify ou Saleor para o backend de commerce, usando Next.js como frontend. O fluxo de checkout requer cuidadoso manuseio pois envolve processamento de pagamento e conformidade PCI. É possível, mas planeje 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 todas opções viáveis. Astro em particular é excelente para sites densos em conteúdo porque envia zero JavaScript por padrão. Next.js ganha para sites que precisam de interatividade significativa, funcionalidades dinâmicas ou e-commerce. Trabalhamos com 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 no 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 gerada recentemente, que é então armazenada em cache no edge. A revalidação acontece em background, então usuários nunca esperam por um build. Você também consegue definir revalidação baseada em tempo (ex., reconstruir a cada 60 segundos) como fallback.

Qual é o maior erro que times cometem ao ficar 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 tratam isto como um novo começo — mantendo o conteúdo mas repensando a apresentação — acabam com resultados dramaticamente melhores do que times que tentam copiar cada widget e sidebar do seu tema antigo.