WordPress ou Astro: o que a escolha de plataforma custa

O WordPress monta a página quando o visitante pede. Um gerador de site estático monta cada página uma vez, antes de alguém chegar, e depois entrega um arquivo. A escolha mudou porque o segundo caminho deixou de exigir alguém escrevendo HTML à mão para cada página.

O que mudou no cálculo

Vinte anos atrás um sistema de gestão de conteúdo ganhava o lugar dele resolvendo um trabalho: transformar texto em página web. Fazer isso à mão para algumas centenas de páginas era trabalho que ninguém queria repetir, então um banco de dados e uma tela de administração se pagavam sozinhos.

Esse trabalho hoje é feito numa etapa de build. Um gerador lê markdown, aplica um template e escreve arquivos HTML numa pasta. A publicação acontece num pipeline, e o pipeline pode ser disparado por um commit, um formulário ou uma tarefa agendada. O custo de produzir HTML caiu para quase nada, e o custo de manter uma aplicação no ar não caiu junto.

O que não mudou é o motivo de um CMS existir. Alguns sites realmente produzem uma página diferente para cada visitante. Uma área de assinante, um carrinho com estoque ao vivo ou uma thread de comentários precisa de código rodando no momento do pedido. Para esses casos, uma pasta estática é a forma errada.

O WordPress também mudou. O editor de blocos facilitou a publicação, e as atualizações automáticas de versão menor (em inglês) tiraram uma classe de manutenção do caminho. O WordPress Playground (em inglês) roda o WordPress na hora, em qualquer aparelho, sem hospedagem. Isto não é uma história de antigo contra novo.

Como cada caminho entrega a página

Quase todo o resto depende de como a página chega ao visitante.

No WordPress, o pedido do visitante chega a um servidor web que roda PHP. O WordPress inicia, consulta o banco de dados, executa o tema e cada plugin ativo, monta um documento HTML e devolve. A página de requisitos é explícita ao dizer que o WordPress precisa de um servidor web com PHP e de um banco de dados atrás. Esse trabalho se repete a cada pedido, a menos que um cache guarde a página pronta e sirva no lugar.

Cache é a resposta padrão, e é uma resposta de verdade. Também é mais uma peça para configurar, invalidar e manter funcionando depois de uma atualização.

Num site estático, o mesmo HTML foi escrito antes. A documentação do próprio Astro (em inglês) afirma que, por padrão, as páginas e rotas dele são pré-renderizadas no build como páginas estáticas. O pedido do visitante resolve para um arquivo, normalmente na borda de uma CDN perto dele. Nenhum processo PHP inicia, nenhum banco é consultado e nenhum código de plugin roda para produzir aquele documento.

A questão aqui é de dependência, não só de velocidade. No WordPress a experiência do visitante depende da saúde de uma aplicação no ar naquele instante. Num site estático ela depende de o arquivo existir e estar acessível.

Estático também não é a única opção dentro de um gerador. O Astro documenta renderização sob demanda (em inglês) por meio de um adaptador de servidor, o que traz o servidor de volta para as rotas que precisam dele. Escolher um gerador não obriga o caminho estático.

Segurança pela superfície de ataque

O próprio manual de hardening do WordPress (em inglês) resume o assunto numa linha: segurança é redução de risco, não eliminação de risco. Esse enquadramento deveria sobreviver a qualquer comparação.

A superfície do WordPress é uma lista de coisas alcançáveis de fora. Uma tela de login fica na internet pública. Credenciais de banco ficam no disco. Plugins e temas de autores diferentes rodam com os mesmos privilégios do núcleo. Caminhos de upload, a API REST e o XML-RPC somam mais entradas. O mesmo manual (em inglês) diz que o host é responsável pela infraestrutura, e não pela aplicação que você instala. Depois manda manter os plugins atualizados e apagar os que você não usa.

Nada disso é defeito. Faz parte de manter uma aplicação. Um sistema que aceita entrada, guarda e permite que administradores ajam sobre ela precisa autenticar, autorizar e validar tudo.

Um site estático tem uma lista muito mais curta. Não há login para alcançar, não há banco escutando no momento do pedido e não há código de servidor executando a cada visita. O que está publicado é HTML, CSS, imagens e fontes. Não existe contra o que autenticar um estranho, porque nenhum estranho consegue fazer o site trabalhar.

Mas a superfície de ataque não some. Ela muda de lugar. Um site estático ainda tem conta de hospedagem, conta de domínio e repositório. Um token de deploy exposto ou um notebook comprometido alcança o site publicado tão direto quanto um plugin explorado alcança um site WordPress. Proteger o pipeline de build passa a ser o trabalho que antes era proteger o painel.

O que cada caminho custa para se manter vivo

Preço varia por host e por região, então compare por mecanismo em vez de por fatura.

O WordPress pede que você opere um sistema rodando. Núcleo, temas e plugins atualizam em calendários próprios, e cada atualização precisa ser testada contra o resto da pilha. Você carrega um host que roda PHP e banco de dados, mais backup, disponibilidade, versão do PHP, tamanho do banco e invalidação de cache. A recompensa é que adicionar uma capacidade costuma ser uma instalação, e o modelo de conteúdo se dobra ao que você precisa.

Um site estático pede que você opere um build. As dependências atualizam, e um build pode quebrar, mas quebra onde você vê antes do visitante. A hospedagem pode ser uma CDN servindo arquivos, que é uma forma mais barata que uma máquina rodando uma aplicação. O modelo de conteúdo é fixado pelo schema que você escreve, então um campo novo é mudança de código.

Os custos se invertem num ponto específico. Um site com muitos editores, papéis, histórico de revisão, publicação agendada e comentários no próprio site está pedindo uma aplicação. Reconstruir isso num pipeline estático significa reconstruir um sistema de gestão de conteúdo, e a maioria dos times faz pior que o que deixou.

Desempenho, contado no que o visitante baixa

Comece contando as requisições de cada lado.

Uma página WordPress costuma entregar o documento, o CSS e o JavaScript do tema e os da biblioteca de blocos. Soma-se o que cada plugin ativo acrescenta no front. Cada plugin que embarca assets soma requisições, e cada plugin de otimização criado para reduzir isso é mais um plugin para manter.

Uma página estática entrega o documento, uma folha de estilo e imagens. A documentação de ilhas do Astro descreve o modelo direto. A maior parte da página vira HTML estático, e pequenas ilhas de JavaScript entram só onde há interatividade ou personalização.

O Core Web Vitals transforma isso numa meta publicada. O Google Search Central declara os limites como Largest Contentful Paint abaixo de 2,5 segundos, Interaction to Next Paint abaixo de 200 milissegundos e Cumulative Layout Shift abaixo de 0,1. O guia do web.dev sobre as métricas é a fonte do percentil 75: cada limite é atingido quando 75 por cento dos carregamentos ficam abaixo dele.

Aqui, o que importa é o que move cada métrica. O LCP melhora quando o maior elemento não espera trabalho de servidor. O INP melhora quando a thread principal não está ocupada hidratando um script grande. O CLS melhora quando o espaço do layout é reservado antes de o conteúdo chegar. HTML estático começa com menos para desfazer.

Pesquisa de percepção dá outros números. Os limites de tempo de resposta do NN/g (em inglês) põem 0,1 segundo como fronteira do instantâneo e 1 segundo como o limite que preserva o fluxo de pensamento. Dez segundos é o limite da atenção. O artigo sobre tempo de resposta de sites (em inglês) registra que imagem grande deixou de ser a causa principal da lentidão, o que conversa com a contagem de requisições acima. Os indicadores de progresso (em inglês) tratam do que mostrar quando a espera é inevitável.

Os dois referenciais divergem de propósito. O NN/g mede o que a pessoa sente, interação por interação, enquanto o Core Web Vitals é dado de campo no percentil 75. Uma página pode passar no LCP de 2,5 segundos e ainda ficar acima do limite de 1 segundo que preserva o fluxo de pensamento (Core Web Vitals, NN/g (em inglês)).

O contraponto: um site WordPress bem cacheado e com tema leve passa nos três. O Google mede as suas páginas, não o seu framework, e o dado de campo decide o resultado.

Quando o WordPress ainda é a escolha certa

• Muitos editores que nunca deveriam tocar em código, com papéis e permissões diferentes por pessoa.
• Conteúdo que difere por visitante ou por sessão, como área de assinante, estoque ao vivo ou carrinho.
• Uma capacidade que você não consegue construir e para a qual existe plugin mantido, como pagamento, agendamento ou plataforma de curso.
• Comentários e comunidade dentro do site, em vez de numa plataforma social.
• Um time que já conhece WordPress, onde retreinar custaria mais que hospedar.
• Um host que cuida do servidor, para você nunca encostar na máquina.

E não são poucos casos. O WordPress é a resposta correta mais vezes do que um texto de comparação costuma admitir.

A pergunta que decide

Faça uma pergunta: a página difere por visitante no momento do pedido?

Se a resposta é não, o trabalho pertence ao build, e servir arquivos tira uma camada de código rodando do caminho do visitante. Se a resposta é sim, você precisa de uma aplicação, e o WordPress é uma aplicação madura, com muitos plugins, temas e gente que sabe mantê-la.

Custo, velocidade e segurança saem dessa resposta.

A mesma decisão de adotar ou construir aparece em o texto sobre Material Design, em escala menor.