Artigo originalmente publicado em RET Tecnologia.
O Elefante na Sala
WordPress alimenta 43% da internet. É uma plataforma incrível para blogs e sites simples. Mas quando agências vendem WordPress como "solução de alta performance para empresas"? É desonestidade técnica.
O Benchmark: 50 Sites WordPress vs 50 Sites Next.js
Rodamos Lighthouse (Performance, Accessibility, Best Practices, SEO) em 100 sites reais de empresas brasileiras. 50 em WordPress, 50 em Next.js/React. Todos com mais de 1.000 visitas/mês.
Resultados Médios:
| Métrica | WordPress (média) | Next.js (média) |
|---|---|---|
| Performance Score | 38/100 | 92/100 |
| LCP (Largest Contentful Paint) | 4.8s | 0.8s |
| TBT (Total Blocking Time) | 890ms | 45ms |
| CLS (Layout Shift) | 0.24 | 0.02 |
| First Load JS | 1.2MB | 87KB |
| Requests HTTP | 78 | 12 |
| TTFB | 1.4s | 0.08s |
WordPress foi 6x mais lento, 14x mais pesado em JavaScript, e fez quase 7x mais requests HTTP.
Por Que WordPress É Lento (Estruturalmente)
Não é culpa do WordPress em si. É da arquitetura.
1. PHP Server-Rendered
Cada visita dispara uma execução PHP no servidor. O servidor precisa: conectar ao MySQL → rodar queries → montar HTML → enviar. Isso leva 800ms-2s só de processamento.
Next.js: Páginas pré-renderizadas (SSG) são HTML estático já pronto. TTFB: 20-80ms.
2. Plugins = JavaScript Incontrolável
Sites WordPress médios rodam 15-30 plugins. Cada plugin injeta:
- JavaScript próprio (muitas vezes jQuery + dependências)
- CSS próprio (muitas vezes não minificado)
- Fonts externas (muitas vezes duplicadas)
Resultado: 1.2MB de JavaScript competindo para executar no celular do usuário.
3. Sem Code Splitting
WordPress carrega TUDO na primeira requisição. Slider da home, galeria da página de fotos, formulário de contato — tudo junto, mesmo que o usuário esteja apenas na home.
Next.js: Code splitting automático. Cada página carrega apenas o necessário.
4. Banco de Dados Saturado
WooCommerce + ACF + Yoast + WPML = consultas SQL complexas em cada page load. Sem cache agressivo (Redis/Varnish), o MySQL vira gargalo em < 500 visitantes simultâneos.
"Mas E o Cache? E o CDN?"
Sim, existem soluções de cache (WP Rocket, W3 Total Cache, Cloudflare). Elas ajudam — mas são band-aids:
- WP Rocket: Reduz LCP de 4.8s para ~2.5s. Ainda longe dos 0.8s do Next.js.
- CDN: Melhora TTFB mas não resolve o JavaScript pesado.
- Cache de página: Quebra com conteúdo dinâmico (carrinhos, logins, personalização).
Otimizar WordPress para performance é como colocar aerodinâmica num caminhão. Melhora, mas nunca vai ser um carro de corrida.
Quando WordPress Faz Sentido (De Verdade)
✅ Blog pessoal ou de conteúdo puro
✅ Site simples de até 5 páginas sem interatividade
✅ Orçamento < R$ 3.000
✅ Sem necessidade de performance para SEO competitivo
Quando NÃO Faz Sentido (E Agências Insistem)
✗ E-commerce com mais de 100 produtos
✗ Geração de leads B2B com tráfego pago
✗ Sites institucionais de empresas que faturam > R$ 500k/ano
✗ Plataformas SaaS ou sistemas
✗ Qualquer caso onde Core Web Vitals impactam receita
A Arquitetura RET: Performance Nativa
Na RET, construímos com Next.js 16 + Edge Computing:
- SSG + ISR: Páginas estáticas que se atualizam sem rebuild completo.
- React Server Components: Lógica pesada roda no servidor, não no celular.
- Image Optimization: AVIF/WebP automático com blur placeholder.
- Edge Functions: Código roda a milissegundos do usuário, em 40+ regiões.
O resultado não é opinião. São números do Lighthouse.
Se sua agência promete "WordPress otimizado", peça o print do Lighthouse em mobile. Se o score for < 80, você está pagando por um produto lento.
Top comments (0)