Deixa eu ser honesto com você: nosso antigo site WordPress era envergonhante. Não porque parecia ruim — na verdade parecia bastante decente. Mas internamente? Um Time to Interactive de 3,2 segundos, uma pontuação de performance do Lighthouse rondando 58, e um monte de plugins que faziam cada deploy parecer uma desativação de bomba. Somos uma agência de desenvolvimento web. Construímos sites rápidos para clientes. E nosso próprio site era... não era rápido.

Então demolimos e reconstruímos com Astro. O resultado: 100s perfeitos em todas as quatro categorias do Lighthouse — Performance, Acessibilidade, Melhores Práticas e SEO. Não apenas em uma página. Em todas as páginas. Esta é a história de como chegamos lá, o que quebrou no caminho, e o que faríamos diferente.

Índice

WordPress para Astro: Como Atingimos Lighthouse 100 em Nossa Reconstrução

Por que Deixamos WordPress

Olha, WordPress alimenta algo como 43% da web. Não é uma plataforma ruim. Construímos vários sites em WordPress para clientes e continuaremos fazendo quando for apropriado. Mas para nosso próprio site da agência — um site de marketing na maioria estático com um blog — WordPress era um exagero da pior forma.

Aqui está como era nossa configuração WordPress:

  • Tema: Tema customizado construído em Sage (Roots.io)
  • Plugins: 14 plugins ativos incluindo Yoast SEO, WP Rocket, Advanced Custom Fields Pro, Gravity Forms, e vários outros
  • Hospedagem: Plano WP Engine Professional por $60/mês
  • CDN: Cloudflare Pro por $20/mês
  • Complexidade de build: Templating PHP, Webpack para assets, banco de dados MySQL

Mesmo com WP Rocket fazendo cache agressivo, nossos Core Web Vitals eram mediocres. O Largest Contentful Paint (LCP) era 2,4 segundos em mobile. Cumulative Layout Shift (CLS) era 0,12 — não terrível, mas não bom. E toda vez que atualizávamos um plugin, havia chance não-nula de algo quebrar.

O problema real? Estávamos pagando $80/mês em custos de hospedagem para um site que recebia talvez 3.000 visitas por mês. Não é muito tráfego, e é muito dinheiro para o que era essencialmente um site de brochura com um blog.

O Ponto de Ruptura

O último palha veio em janeiro de 2025. Uma atualização do core do WordPress quebrou nossos blocos Gutenberg customizados. Corrigir exigiu atualizar ACF Pro, que exigiu atualizar a compatibilidade da versão PHP do nosso tema, que exigiu atualizar o ambiente de hospedagem. O que deveria ter sido uma atualização rotineira virou um dia inteiro de trabalho.

Olhei para nosso time e disse, "Dizemos aos clientes para ir headless. Por que não estamos comendo nossa própria comida?"

Por que Escolhemos Astro

Avaliamos quatro opções para a reconstrução:

Framework Prós Contras Nossa Conclusão
Next.js Conhecemos bem, ótimo ecossistema Exagerado para um site de conteúdo, requer servidor ou runtime de borda Muito pesado
Astro Focado em conteúdo, envia zero JS por padrão, arquitetura de islands Ecossistema menor, mais novo Encaixe perfeito
Eleventy Simples, builds rápidos, maduro Modelo de componente limitado, DX menos moderno Segundo lugar
Hugo Builds relâmpago, binário único Templating em Go é penoso, flexibilidade limitada Não para nós

Construímos muitos projetos Next.js para clientes, e é nossa escolha padrão para qualquer coisa com funcionalidade dinâmica. Mas para um site de marketing pesado em conteúdo? Next.js envia um runtime JavaScript para o navegador quer você precise ou não. Mesmo com exportação estática, você está enviando React para o navegador.

A filosofia do Astro ressoou conosco: enviar HTML, adicionar JavaScript apenas onde você precisa. Sua arquitetura de islands significa que você pode ter um componente React totalmente interativo sentado ao lado de HTML completamente estático, e as partes estáticas enviam zero JavaScript. Isso era exatamente o que precisávamos.

Também tínhamos feito mais trabalho de desenvolvimento Astro para clientes ao longo de 2024, então o time estava confortável com o framework. Não era um exercício de aprendizado — era uma ferramenta que já confiávamos.

A Questão da Camada de Conteúdo

Uma decisão que tomamos cedo: não iríamos usar um headless CMS para nosso próprio site. Para projetos de clientes, frequentemente recomendamos configurações headless CMS com Contentful, Sanity ou Storyblok. Mas para nosso blog, onde todo autor é um desenvolvedor confortável com Markdown e Git? Content Collections em Astro com arquivos MDX commitados para o repo era mais simples e rápido.

Sem chamadas de API em tempo de build. Sem rede de entrega de conteúdo para conteúdo. Sem serviço adicional para gerenciar ou pagar. Apenas arquivos em uma pasta.

A Estratégia de Migração

Não fizemos uma migração do tipo big-bang. Aqui está nossa abordagem em fases:

Fase 1: Auditoria de Conteúdo (1 semana) Exportamos todo conteúdo WordPress usando wp-cli e convertemos posts para MDX usando um script customizado construído com turndown (conversor HTML-para-Markdown) mais alguma limpeza regex. Tínhamos 47 posts de blog na época. Cerca de 12 deles eram desatualizados ou com baixo desempenho, então redirecionamos aqueles para conteúdo mais novo relevante e não os migramos.

Fase 2: Design System em Astro (2 semanas) Reconstruímos nossa biblioteca de componentes como componentes Astro. Botões, cards, layouts de seção, navegação — tudo como arquivos .astro. Nenhum framework necessário para nenhum deles. HTML e CSS puros com estilos com escopo.

Fase 3: Build de Páginas (2 semanas) Home page, páginas de capacidades, about, contact, listagem de blog, posts de blog individuais, 404. Construímos todas como páginas Astro com nossa biblioteca de componentes.

Fase 4: Ajuste de Performance (1 semana) É aqui que o trabalho Lighthouse 100 realmente aconteceu. Mais sobre isso abaixo.

Fase 5: Launch e Redirecionamento (2 dias) Configuramos 301 redirects para cada URL antiga, verificamos com Screaming Frog que nada estava quebrado, enviamos o novo sitemap para Google Search Console, e trocamos DNS.

Timeline total: cerca de 6 semanas de trabalho part-time junto com projetos de clientes.

WordPress para Astro: Como Atingimos Lighthouse 100 em Nossa Reconstrução - arquitetura

Decisões de Arquitetura que Fizeram Diferença

Zero JavaScript por Padrão

Nosso site inteiro envia aproximadamente 2KB de JavaScript total. Não é um typo. Dois kilobytes. E a maioria disso é um pequeno script para toggle de navegação mobile e analytics.

Aqui está nossa nav mobile — sem framework, sem dependências:

---
// MobileNav.astro
---
<button id="menu-toggle" aria-expanded="false" aria-controls="mobile-menu">
  <span class="sr-only">Alternar menu</span>
  <svg><!-- ícone hamburger --></svg>
</button>
<nav id="mobile-menu" hidden>
  <slot />
</nav>

<script>
  const toggle = document.getElementById('menu-toggle');
  const menu = document.getElementById('mobile-menu');
  
  toggle?.addEventListener('click', () => {
    const expanded = toggle.getAttribute('aria-expanded') === 'true';
    toggle.setAttribute('aria-expanded', String(!expanded));
    menu?.toggleAttribute('hidden');
  });
</script>

Aquele tag <script> em um componente Astro é agrupado e desduplicado automaticamente. É minúsculo, é vanilla JS, e funciona em todo lugar.

Estratégia CSS: Estilos com Escopo + Uma Camada Global Mínima

Usamos CSS com escopo integrado do Astro para estilos em nível de componente e uma única folha de estilo global (cerca de 8KB minificada) para tipografia, reset, custom properties, e classes utilitárias. Sem Tailwind. Opinião controversa, eu sei.

Amamos Tailwind para aplicações maiores e projetos de clientes. Mas para um site deste tamanho, adicionou complexidade de build e tamanho de arquivo que não precisávamos. Nosso CSS escrito à mão é menor do que a saída do Tailwind teria sido, mesmo com purging.

/* Custom properties globais */
:root {
  --color-text: #1a1a2e;
  --color-bg: #ffffff;
  --color-accent: #e94560;
  --color-accent-dark: #c81e45;
  --font-body: 'Inter', system-ui, sans-serif;
  --font-heading: 'Cal Sans', var(--font-body);
  --max-width: 72rem;
  --space-unit: 0.25rem;
}

Geração Estática com Pré-carregamento Inteligente

Cada página é gerada estaticamente em tempo de build. Usamos a integração prefetch integrada do Astro para pré-carregar links ao passar o mouse, tornando a navegação instantânea:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://socialanimal.dev',
  integrations: [mdx(), sitemap()],
  prefetch: {
    prefetchAll: false,
    defaultStrategy: 'hover',
  },
  build: {
    inlineStylesheets: 'auto',
  },
});

Mergulho Profundo em Otimizações de Performance

Chegar ao Lighthouse 100 não é apenas sobre escolher o framework correto. Astro te dá um início, mas os últimos 10-15 pontos requerem esforço deliberado. Aqui está o que fizemos.

Otimização de Imagens

O componente <Image /> integrado do Astro trata imagens responsivas com conversão automática de formato (WebP/AVIF), lazy loading, e atributos width/height apropriados para prevenir CLS.

---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image 
  src={heroImage} 
  alt="Time de desenvolvimento Social Animal trabalhando em arquitetura headless"
  widths={[400, 800, 1200]}
  sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  format="avif"
  fallbackFormat="webp"
  quality={80}
  loading="eager"
/>

Para a imagem hero especificamente, usamos loading="eager" já que está acima da dobra. Tudo mais recebe loading="lazy" por padrão.

Também passamos por cada imagem no site e perguntamos: "Isso realmente precisa ser uma imagem?" Vários elementos decorativos viraram gradientes CSS ou SVGs em vez disso. Nosso background de seção hero, por exemplo, é um gradiente CSS com uma textura de ruído sutil aplicada via um pequeno SVG inline.

Estratégia de Carregamento de Fonts

Fonts são um matador do Lighthouse. Aqui está nossa abordagem:

  1. Auto-hospede tudo. Sem Google Fonts CDN. Baixamos Inter e Cal Sans e servimos do nosso próprio domínio. Isso elimina uma DNS lookup, conexão TCP, e TLS handshake para fonts.googleapis.com.

  2. Subset agressivamente. Usamos glyphhanger para analisar quais caracteres realmente usamos, então fizemos subset de nossas fonts com pyftsubset. Nossa Inter Regular WOFF2 foi de 96KB para 18KB.

  3. Use font-display: swap com um fallback de fonte do sistema cuidadosamente escolhida que combina métricas proximamente, minimizando layout shift durante swap.

  4. Pré-carregue os arquivos de font críticos:

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/cal-sans-latin-600.woff2" as="font" type="font/woff2" crossorigin />

Hospedagem: Cloudflare Pages

Nos mudamos de WP Engine ($60/mês) para Cloudflare Pages (tier gratuito). Sim, gratuito. Nosso site está bem dentro dos limites do plano gratuito do Cloudflare — 500 builds por mês, bandwidth ilimitado, requisições ilimitadas.

Cloudflare Pages faz deploy de um Git push, serve de sua rede global de edge, e trata cache headers automaticamente. Tempos de build são em média 22 segundos para nosso site inteiro. Compare isso com nossa configuração WordPress onde uma purga de cache sozinha podia levar mais tempo.

Custo mensal de hospedagem foi de $80 para $0.

Inlining de CSS Crítico

Astro automaticamente faz inline de pequenas folhas de estilo quando você define build.inlineStylesheets: 'auto'. Para nossas páginas, cada estilo crítico é feito inline na <head>, significando que não há requisições CSS que bloqueiam render. O navegador pode começar a pintar imediatamente.

Disciplina com Scripts de Terceiros

É aqui que a maioria dos sites perde suas pontuações perfeitas. Cada script de terceiro é um potencial desastre de performance. Limitamos os nossos impiedosamente:

  • Analytics: Trocamos de Google Analytics (70KB+ de JavaScript) para Plausible Analytics (script < 1KB, carregado async). Pagamos $9/mês pela Plausible, e a qualidade de dados é honestamente melhor para nossas necessidades.
  • Forms: Nosso formulário de contact em /contact usa um simples formulário HTML com manipulação server-side via Cloudflare Pages Functions. Sem biblioteca de formulários JavaScript.
  • Sem chat widgets. Sem embeds de redes sociais. Sem banners de consentimento de cookies (não usamos cookies que requerem consentimento).

O Scorecard Lighthouse 100

Aqui estão nossas pontuações reais do Lighthouse a partir de maio de 2025, medidas usando Chrome DevTools em uma conexão acelerada (simulação mobile padrão do Lighthouse):

Métrica Pontuação
Performance 100
Acessibilidade 100
Melhores Práticas 100
SEO 100
First Contentful Paint 0,6s
Largest Contentful Paint 0,8s
Total Blocking Time 0ms
Cumulative Layout Shift 0
Speed Index 0,8s

O Total Blocking Time de 0ms é minha stat favorita. Zero. Essencialmente não há JavaScript bloqueando a main thread. Nunca.

Antes e Depois: Os Números

Métrica WordPress (Antes) Astro (Depois) Melhoria
Lighthouse Performance 58 100 +72%
LCP (mobile) 2,4s 0,8s 3x mais rápido
CLS 0,12 0 Eliminado
TBT 380ms 0ms Eliminado
Peso da página (home) 1,8MB 142KB 92% menor
Requisições HTTP 47 6 87% menos
JavaScript enviado 340KB 2KB 99,4% menos
Custo mensal de hospedagem $80 $9 (apenas Plausible) 89% mais barato
Tempo de build/deploy 3-5 min 22 seg ~10x mais rápido
Time to First Byte 420ms 18ms 23x mais rápido

A redução de peso da página é vertiginosa mesmo para nós. 1,8MB para 142KB. É o que acontece quando você para de enviar jQuery, React, o script loader do WP Rocket, o injetor de schema markup do Yoast, e as folhas de estilo de catorze plugins.

O Que Fizemos Errado Pelo Caminho

Não foi tudo vela lisa. Tempo de honestidade.

Erro 1: Quase Over-Engineered a Gestão de Conteúdo

Nosso primeiro instinto foi configurar Sanity como um headless CMS para o blog. Passamos dois dias configurando schemas e configurando o Sanity Studio antes de nos questionarmos, "Quem realmente vai usar isso?" A resposta foi... nós. Desenvolvedores. Que estamos perfeitamente satisfeitos escrevendo MDX em VS Code. Tiramos Sanity e fomos com Astro Content Collections. Economizou custos contínuos e complexidade.

Erro 2: Font Subsetting Quebrou Caracteres Especiais

Nosso subset de font inicial era muito agressivo. Removemos caracteres que pensávamos nunca usar, então publicamos um post de blog com um em dash e algumas aspas curvadas que renderizaram como caixas. Lição: teste seus subsets com conteúdo real, não apenas "ABCDEFG."

Erro 3: Esquecemos de OpenGraph Images

Lançamos sem imagens OG dinâmicas. Quando alguém compartilhava um post de blog no Twitter/X ou LinkedIn, mostrava um fallback genérico. Tivemos que voltar e construir um pipeline de geração de imagem OG usando @astrojs/og (que usa Satori por baixo). Deveria ter estado no escopo original.

Erro 4: O Mapa de 301 Redirect Tinha Lacunas

Apesar de usar Screaming Frog para mapear URLs antigas, perdemos alguns URLs de imagem que sites externos estavam hotlinkando. Pegamos estes na analytics do Cloudflare cerca de uma semana após o launch e adicionamos os redirects faltantes. Sempre cheque seus server logs após uma migração — Google Search Console não vai pegar tudo.

Lições para Sua Própria Migração

Se você está considerando sair de WordPress para um framework focado em estático-primeiro, aqui está o que eu diria:

  1. Faça auditoria antes de migrar. Elimine conteúdo que não está performando. Uma migração é uma ótima oportunidade de podar.

  2. Combine a ferramenta com o trabalho. Astro era perfeito para nós porque somos principalmente conteúdo. Se você precisa de interatividade pesada, Next.js ou um framework similar pode ser a melhor escolha.

  3. Não replique sua arquitetura antiga por cargo cult. Não tentamos replicar nossa configuração WordPress em Astro. Repensamos tudo do zero. Realmente precisamos de um plugin de formulário? Não, um elemento <form> com uma função serverless funciona bem.

  4. Meça antes, meça depois, meça continuamente. Configuramos um job Lighthouse CI em GitHub Actions que roda em cada pull request. Se um PR cai qualquer pontuação abaixo de 95, ele falha a verificação.

  5. Orce para os "últimos 5%". Ir de Lighthouse 85 para 95 é direto. Ir de 95 para 100 requer subsetting de font, análise de CSS crítico, otimização de formato de imagem, e auditoria de script de terceiro. Planeje tempo para isso.

  6. Seus custos de hospedagem devem envergonhar seu setup antigo. Se você está servindo arquivos estáticos e ainda pagando taxas de hospedagem significativas, algo está errado. Hospedagem estática é uma commodity agora.

Se você está interessado no que uma migração assim pareceria para seu projeto, confira nossa página de preços ou entre em contato. Fizemos esse caminho de migração para vários clientes agora, e os ganhos de performance são consistentemente dramáticos.

FAQ

Quanto tempo leva para migrar um site WordPress para Astro? Para nosso site (cerca de 50 páginas incluindo posts de blog), levou aproximadamente 6 semanas de trabalho part-time. Um site maior com centenas de posts e tipos de post customizados complexos poderia levar 8-12 semanas. O desenvolvimento real é geralmente mais rápido do que a auditoria de conteúdo e mapeamento de redirect.

Você pode obter Lighthouse 100 com Next.js em vez de Astro? É possível mas significativamente mais difícil. Next.js envia um runtime JavaScript para o navegador mesmo para páginas estáticas (a camada de hidratação React). Você pode chegar perto — pontuações de 95-99 são alcançáveis com otimização cuidadosa. Mas a abordagem zero-JS-por-padrão do Astro torna scores perfeitos muito mais atingíveis para sites de conteúdo.

E sobre funcionalidades WordPress como formulários de contato e busca? Formulários de contato funcionam bem com formulários HTML planos e backend de função serverless (Cloudflare Pages Functions, Netlify Functions, etc.). Para busca, usamos uma busca client-side com Pagefind, que constrói um índice de busca em tempo de build e envia apenas 5KB de JavaScript. É rápido e funciona offline.

Migrar de WordPress para Astro prejudica SEO? Não se você lidar apropriadamente. Configuramos 301 redirects para cada URL, mantivemos nossa estrutura de URL onde possível, enviamos um novo sitemap, e mantivemos todos nossos dados estruturados. Nosso tráfego orgânico realmente aumentou 23% nos três meses após migração, provavelmente devido aos Core Web Vitals melhorados.

Como você lida com conteúdo dinâmico como comentários em um site Astro? Não temos comentários em nosso blog — eram principalmente spam no WordPress de qualquer forma. Se você precisa de comentários, serviços como Giscus (baseado em GitHub Discussions) ou Hyvor Talk funcionam bem como componentes embarcados. Eles carregam como Astro islands, então não afetam carregamento de página inicial.

Astro é production-ready para sites grandes? Absolutamente. Astro 5.x (lançado final de 2024) é maduro e estável. Empresas como Porsche, Google, Microsoft, e Netlify usam em produção. A performance de build também escala bem — sites com milhares de páginas fazem build em menos de um minuto com a configuração correta.

Como é a manutenção contínua comparada com WordPress? Dramaticamente menos. Sem atualizações de plugin, sem manutenção de banco de dados, sem patches de segurança de PHP. Atualizamos Astro e suas dependências talvez uma vez por mês via PRs do Dependabot. Cada atualização leva cerca de 5 minutos para revisar e fazer merge. Compare com a esteira de atualização WordPress.

Membros de time não-técnicos ainda podem editar conteúdo em um site Astro? Com nossa configuração (arquivos MDX em Git), você precisa estar confortável com Markdown e fluxos de trabalho Git básicos. Para times com editores não-técnicos, recomendamos parear Astro com um headless CMS como Sanity, Contentful, ou Storyblok. Os editores recebem uma interface visual, e você ainda obtém todos os benefícios de performance da geração estática.