Do WordPress ao Astro: nota 100 no Lighthouse em um dia

O site antigo da N3XUS rodava em WordPress com Elementor e um tema pronto. Funcionava, mas dependia de plugins pesados para tudo, carregava cerca de 20 arquivos de JavaScript por página e ainda tinha conteúdo de exemplo do tema esquecido em várias seções.

Migramos para Astro em um dia de trabalho. Este é o caminho, com os números medidos e os erros que cometemos no meio.

Em resumo

Site estático em Astro, sem JavaScript nas páginas públicas, servido por nginx sem root num contêiner.
Deploy por git push: o Coolify publica em cerca de 1 minuto, e o WordPress ficou de reserva.
Lighthouse entre 99 e 100 nas quatro categorias, no celular e no desktop, com CLS 0.
Os três erros que mais custaram: um efeito CSS que sumia com imagens, fontes mudando o layout e uma animação pesando no celular.

A arquitetura nova

Visitante -> Cloudflare (DNS, CDN, WAF) -> Cloudflare Tunnel
          -> Traefik (Coolify) -> nginx sem root -> arquivos estáticos do Astro

Astro gera HTML puro no build. Blog e páginas legais são arquivos Markdown com esquema validado.
nginx sem root, com CSP rígida, HSTS e headers de isolamento.
Coolify builda o Dockerfile a cada push na branch principal, via webhook do GitHub.
Cloudflare Tunnel entrega o tráfego sem nenhuma porta aberta no servidor.
Painel de conteúdo (Sveltia CMS) em /admin/, protegido por Cloudflare Access e com login no GitHub por token restrito ao repositório.

Cuidados para não quebrar nada

URLs estáveis. A política de privacidade e a página de suporte já estavam cadastradas em lojas de aplicativos. Mantivemos exatamente os mesmos endereços e criamos redirecionamentos 301 para as URLs antigas do WordPress que mudaram.

Subdomínio de teste primeiro. O site novo foi para novo.n3xus.dev antes de assumir o domínio principal. Só depois de validar páginas, headers e visual é que o domínio principal foi trocado.

Troca de DNS reversível. O domínio principal era um CNAME apontando para o túnel do servidor antigo. A troca foi mudar só esse destino, e o caminho de volta ficou anotado. E-mail, SPF e registros de verificação no mesmo domínio não foram tocados.

Antes e depois

	Antes (WordPress)	Depois (Astro)
HTML da home	~125 KB	~15 KB
JavaScript nas páginas públicas	cerca de 20 arquivos	nenhum
Peso total por página	não medido	64 a 125 KB
Publicação	painel do WordPress	git push, cerca de 1 minuto
Superfície de ataque	PHP, banco e plugins	arquivos estáticos

O peso total antigo não está na tabela porque não medimos com o mesmo método antes da troca, e não quisemos estimar.

O que deu errado (e como resolvemos)

Imagens que sumiam. Um filter: drop-shadow() aplicado sobre uma imagem grande fazia a imagem e a seção seguinte não serem pintadas no render por software. Removemos o efeito: ele também pesava em celulares fracos.

Layout pulando com as fontes. Quando a fonte final substituía a de reserva, os títulos grandes mudavam de largura e empurravam o conteúdo. A página de soluções teve CLS de 0,33 no desktop. Pré-carregar as fontes principais resolveu.

Celular lento por causa de detalhes. A home oscilava entre 90 e 95 no celular. As causas eram um cursor piscando em animação infinita e um mask-image sobre a grade do topo. Trocamos por um cursor estático e um gradiente comum, e a nota foi para 98 a 100 nos testes.

Símbolos que dependiam da fonte. Uma seta e um ponto de status apareciam como quadrados em alguns ambientes, porque esses caracteres não existem na fonte do site. Viraram SVG e CSS.

O que manteve a qualidade

Regras escritas no README: nada de estilo inline, nada de foto de banco de imagem com pessoas e nada de animação infinita.
CI no GitHub: o build roda a verificação de tipos e falha se aparecer estilo inline no HTML gerado.
Lighthouse em todas as páginas, e não só na home. Os dois piores problemas estavam em páginas internas.

Referências

Se o site da sua empresa ainda depende de um tema pesado e de plugins, podemos conversar sobre a migração.