WordPress 7.0 vs Astro 7 na Cloudflare - quem ganha em 2026?

Para a maioria dos sites de empresa, o Astro 7 na Cloudflare sai mais barato, mais rápido e mais fácil de proteger do que o WordPress 7.0. Só que essa vantagem tem um preço sobre o qual a versão anterior desta comparação nada disse: o framework tem o seu próprio ritmo de lançamentos e alguém o paga em horas de programação.

Escrevi a primeira versão desta comparação em abril, contra o Astro 6 e um WordPress 7.0 ainda em release candidate. Ambos saíram entretanto, e mudámos este site de Astro 6 para Astro 7. Tenho por isso algo que na altura não tinha: uma factura discriminada de uma migração maior de framework, feita no nosso próprio corpus de bem mais de dez mil páginas.

A recomendação de plataforma não mudou. O que mudou foi o quanto sei sobre os custos escondidos do lado do Astro.

#WordPress 7.0, três meses depois do lançamento

O WordPress 7.0 saiu a 20 de maio de 2026. Vale a pena separar o que foi anunciado do que veio mesmo no pacote.

#AI Client e Abilities API

O AI Client é infraestrutura, não um redator com IA já feito. O WordPress 7.0 traz uma API unificada para falar com modelos, mas exige uma chave externa e configuração antes de fazer o que quer que seja. A Abilities API permite que agentes descubram e invoquem funcionalidades do WordPress de forma programática, algo que interessa a quem faz plugins e que é praticamente invisível para quem edita conteúdo.

É um alicerce importante. Não é uma funcionalidade que um cliente note no painel no primeiro dia.

#A colaboração em tempo real não chegou

A edição em simultâneo foi a promessa mais ruidosa desta versão e foi retirada depois de problemas técnicos. Três meses volvidos continua ausente da linha 7.0. Quem vendeu o WordPress 7.0 a um cliente prometendo vários redatores no mesmo documento tem uma conversa incómoda pela frente.

#A arquitetura por baixo não se mexeu

O painel renovado e os blocos novos são um avanço visual. Por baixo continuam o PHP, o MySQL e um servidor convencional que tem de ser corrigido, colocado em cache e vigiado. Nenhuma das novidades da 7.0 muda o facto de cada plugin alargar a superfície de ataque, nem que o desempenho só aparece depois de uma camada de cache e CDN.

#WordPress 7.0, a troca

O que dá:

• O melhor editor de conteúdo para pessoas não técnicas, sem concorrência real nessa categoria
• Um ecossistema de plugins que se conta às dezenas de milhares
• WooCommerce como plataforma de comércio completa
• A Abilities API como alicerce para integrações com agentes

O que custa:

• Peso do núcleo e sobrecarga que não se consegue desligar
• Uma superfície de ataque que cresce com cada plugin
• Orçamento de alojamento, cópias de segurança, monitorização e plugins de segurança
• Desempenho que só chega depois de cache e CDN
• Versões de segurança de poucas em poucas semanas

#Astro 7 e o que mudou mesmo face à versão 6

O Astro 7.0.0 saiu a 22 de junho de 2026, 104 dias depois do Astro 6.0.0. Três alterações têm consequências que não se veem no changelog até se correr a própria compilação.

#O compilador Rust deixou de ser uma experiência

No Astro 6 o compilador escrito em Rust era uma experiência opcional. O Astro 7 troca a dependência @astrojs/compiler por @astrojs/compiler-rs e torna-a o comportamento predefinido. As compilações ficam mais rápidas. O analisador torna-se, ao mesmo tempo, mais rigoroso.

A nós partiu-nos em exatamente uma linha. Um comentário HTML escrito dentro de uma expressão JSX, algo como {import.meta.env.DEV && ( <!-- ... --> )}, passava no compilador antigo e é rejeitado pelo novo. A correção é um comentário JavaScript. Um minuto de trabalho, desde que se saiba o que procurar, porque a mensagem de erro aponta para uma posição no resultado compilado e não na origem.

#Vite 8 por baixo

O Astro 6 assentava em Vite 7. O Astro 7 passa para Vite 8, a linha assente em Rolldown. Para a maioria dos projetos é invisível, mas em corpus grandes vale a pena vigiar a memória durante a compilação, porque o perfil de alocação é diferente do anterior.

#O CSP faz hash dos estilos inline, e é aí que dói

Esta é a alteração que nos custou um dia inteiro.

O Astro 7 calcula hashes dos blocos <style> embutidos na página e coloca-os na diretiva style-src. Segundo a especificação da Content Security Policy, a presença de qualquer hash numa diretiva anula 'unsafe-inline'. O resultado: todos os atributos style="" dinâmicos deixam de funcionar. No nosso caso caíram as cores de token do Shiki nos blocos de código, além de variáveis de tema, velocidades de animação e imagens de fundo. Só a página inicial deu 26 violações de CSP, e ficaram afetadas todas as páginas com realce de sintaxe.

Não existe interruptor para desligar o cálculo de hashes. 'unsafe-hashes' por si só também não resolve, porque cobre os atributos de estilo mas não o conteúdo dos elementos <style>.

A solução acabou por ser mais simples do que parecia, porque o conjunto de estilos inline é finito. Em cerca de 260 mil ocorrências em todo o corpus havia 143 valores únicos. Recolhê-los uma vez, escrever os hashes na configuração, acrescentar 'unsafe-hashes' para o caso dos atributos, e as violações caem para zero em todos os tipos de template.

Fica uma obrigação permanente. Qualquer componente novo que introduza um valor de estilo inline novo ou entra na lista ou é bloqueado em silêncio em produção. Isto precisa de uma verificação em CI, caso contrário fica-se a saber pelo aviso de um utilizador.

#Uma nova cadeia de markdown predefinida

O Astro 7 muda o processamento predefinido de markdown. Quem mantém a sua própria cadeia de remark e rehype tem de incluir @astrojs/markdown-remark de forma explícita para conservar o comportamento anterior. É uma linha nas dependências, mas quando falta produz uma diferença silenciosa de renderização em vez de um erro de compilação, e é por isso que passa despercebida com facilidade.

#O que nos custou mesmo a migração de Astro 6 para 7

Números do nosso próprio lançamento, não da documentação.

Três das quatro grandes alterações incompatíveis não nos aplicavam, e é esse o cerne da questão. Não temos Astro DB, não há adaptador de servidor para mover e compilamos de forma estática, por isso a reorganização do ponto de entrada do servidor passou-nos ao lado. Um projeto com SSR, adaptador e base de dados do Astro recebe uma factura completamente diferente pela mesma migração.

A lição prática: o custo de uma versão maior do Astro não escala com o tamanho do site. Escala com o número de pontos de contacto com o ambiente de execução. As nossas mais de catorze mil páginas custaram menos do que teria custado uma única aplicação com Astro DB e adaptador próprio.

#Comparação direta 2026

Resultado: Astro 7, WordPress 3, um empate.

O WordPress recuperou um ponto nesta edição, e não por causa de uma funcionalidade nova. Recuperou-o pelo ritmo de lançamentos. Um site WordPress de há três anos ainda compila, porque não há compilação. Um site Astro de há três anos está duas versões maiores atrás e alguém tem de o levar para a frente.

#Quando migrar em 2026, a minha checklist de 8 pontos

Migrar faz sentido quando cumpre pelo menos cinco de oito:

1. Site de conteúdo, blogue ou página de destino, ou seja, exatamente aquilo para que o Astro foi feito
2. PageSpeed abaixo de 80 apesar de otimizar o WordPress, o que indica um problema de arquitetura e não de configuração
3. Custos de alojamento acima de cerca de duzentos euros por mês
4. Incidentes de segurança recorrentes, correções de plugins, tentativas de força bruta
5. Uma equipa de programação que domina JavaScript e TypeScript e que ainda cá estará para executar a próxima atualização maior
6. Sem necessidade de WooCommerce nem de uma área de utilizador autenticado pesada
7. O SEO é prioritário e os Core Web Vitals mexem com as posições
8. O site serve vários países e o TTFB global conta

O ponto cinco está mais largo do que na versão de abril desta lista, e está de propósito. O requisito não é saber JavaScript no dia do lançamento. O requisito é saber quem executa npm update nove meses depois.

Três ou menos: fique no WordPress. Quatro: pondere o híbrido. Cinco ou mais: a migração compensa.

#Caso de estudo, antes e depois

#Site institucional, cliente de Varsóvia

Antes: WordPress com Elementor, PageSpeed a vermelho em telemóvel, tempo de carregamento medido em segundos, uma rubrica mensal fixa de alojamento.

Depois: Astro na Cloudflare Pages, PageSpeed a verde, tempo de carregamento bem abaixo do segundo, alojamento estático no plano gratuito.

Efeito líquido: a rubrica de alojamento desapareceu e os Core Web Vitals passaram de vermelho a verde nos templates principais. Esse mesmo site passou depois pela migração de Astro 6 para 7 dentro da nossa manutenção e o cliente não notou nada além de um deploy.

#wppoland.com, este site

Mais de catorze mil páginas pré-renderizadas em seis línguas, das quais cerca de três mil aparecem nos sitemaps como conteúdo destinado a indexação. O resto é um desdobramento cidade vezes serviço com noindex. Alojamento no plano gratuito da Cloudflare. Este mesmo site corria antes sobre WordPress com alojamento mensal pago.

Migrar esse corpus da 6 para a 7 foram cinco ficheiros e um dia de trabalho, quase todo ele de Content Security Policy.

#Quem opera o site depois de o projeto financiado terminar

Em Portugal há um fator que não aparece em nenhuma comparação técnica e que na prática decide muitos projetos: uma parte relevante dos sites de PME nasce dentro de uma candidatura a apoios à digitalização, no contexto do Portugal 2030 ou do PRR. Isso muda a conversa toda.

O que muda, em concreto:

• há um prazo de execução que não se negoceia com o fornecedor, negoceia-se com o calendário da candidatura
• a empresa tem de conseguir operar o site depois, muitas vezes sem qualquer contrato de manutenção ativo
• quem fica com o site é tipicamente uma pessoa de marketing que acumula redes sociais, catálogo e loja
• o orçamento fecha antes de se saber o que o site precisa mesmo de fazer

Nesse enquadramento, o argumento técnico a favor do Astro perde força, mesmo quando está correto. Um site estático é mais rápido e mais barato de servir, mas se a empresa não tem quem lhe toque, o que determina se o site continua vivo ao fim de dois anos é a diferença entre publicar um artigo em cinco minutos e ter de pedir a alguém de fora. Sites parados desde o mês seguinte à entrega são um padrão que se repete, e raramente por causa da plataforma escolhida.

O ritmo de lançamentos da secção anterior agrava exatamente este caso, e é a razão pela qual o dizemos por escrito na proposta. Uma candidatura fecha o orçamento no início e não prevê rubrica para uma atualização maior de framework dezoito meses depois. O site continua no ar, porque HTML estático não deixa de funcionar, mas o primeiro pedido de alteração já não é uma alteração: é uma migração que ninguém orçamentou.

A leitura que fazemos com clientes portugueses é simples. Se o projeto termina e a empresa fica sozinha com o site, o WordPress 7.0 continua a ser a escolha defensável, com todo o custo de manutenção que isso implica. Se fica uma agência ou um responsável técnico ligado ao projeto para além da entrega, o Astro compensa, sobretudo na variante híbrida com o WordPress apenas como editor.

Há ainda um detalhe do mercado nacional que vale a pena assumir: muitas equipas portuguesas trabalham em simultâneo para clientes locais e para clientes estrangeiros. Se a equipa que vai ficar com o site já mantém projetos em stack moderna para fora, o risco de escolher Astro em Portugal desce bastante, porque a competência já está dentro de casa.

#Como é a migração de WordPress para Astro na prática

#Passo 1, auditoria do site WordPress

Conte os custom post types, liste os plugins com o que cada um faz de facto, mapeie os templates. Isto determina a complexidade de tudo o resto.

#Passo 2, exportar o conteúdo

WP CLI ou a API REST para retirar artigos, páginas e media para markdown ou JSON. A maior parte automatiza-se.

#Passo 3, construir os templates Astro

Refazer layouts e componentes em sintaxe .astro. O Tailwind CSS comporta-se de forma idêntica. A maioria dos templates de WordPress tem equivalentes diretos.

#Passo 4, Content Collections

Definir tipos de conteúdo com validação Zod. O equivalente aos custom post types, com a diferença de que a tipagem apanha o erro na compilação e não em produção.

#Passo 5, alojamento e DNS

Cloudflare Pages ligado ao repositório Git, domínio configurado. As compilações disparam a cada push.

#Passo 6, redireções um para um

Mapeie cada URL antigo para o novo caminho. É neste passo que morrem as posições quando é feito à pressa.

#Passo 7, testes e submissão ao GSC

Rastreio completo, execuções de Lighthouse em cada tipo de template, sitemap novo na Google Search Console.

#Passo 8, trinta dias de monitorização

Acompanhe posições, indexação e Core Web Vitals ao longo do primeiro mês.

Hoje acrescentaria um nono passo: registe que versão do Astro entregou e o que há a verificar na próxima versão maior. Um runbook escrito no dia da migração custa uma hora. Reconstruir esse conhecimento seis meses depois custa um dia.

#Solução híbrida, WordPress mais Astro

Não é preciso escolher um dos dois. O híbrido é assim:

• WordPress como CMS headless, o painel de edição de conteúdo
• Astro como frontend, a gerar páginas estáticas a partir dos dados do WordPress
• WPGraphQL ou a API REST como ponte
• Cloudflare Pages a alojar o frontend

A redação mantém a interface que conhece, os visitantes recebem uma página estática e a equipa técnica trabalha com uma stack moderna. O modelo de custos completo está no guia de TCO headless contra monolito.

#O custo escondido sobre o qual não escrevi em abril

O Astro 6.0.0 saiu a 10 de março de 2026. O Astro 7.0.0 saiu a 22 de junho. No final de agosto a linha 7.x ia na 7.2.8. Esse ritmo o WordPress nunca o teve.

Para nós é comportável, porque mantemos a nossa própria stack e temos verificações em CI que apanham o desvio antes de chegar a produção. Para um cliente que recebeu um site e desapareceu durante dois anos, a história é outra. O site continua a funcionar, porque HTML estático não deixa de funcionar. Mas acrescentar seja o que for ao fim de dois anos significa saltar duas versões maiores de uma vez, e isso é bastante mais duro do que duas migrações feitas em sequência.

A versão honesta da recomendação é por isso esta. O Astro ganha em desempenho, custo de infraestrutura e segurança. O WordPress ganha por ser seguro deixá-lo entregue a si próprio durante mais tempo. Se o orçamento de manutenção não tem rubrica para revisões técnicas, essa segunda propriedade vale mais do que a tabela sugere.

#Pegada energética e relato de sustentabilidade

Nos clientes abrangidos pelo relato de sustentabilidade, a pegada energética do site começou a aparecer nos cadernos de encargos. Vale a pena separar desde o início o que é possível demonstrar daquilo que apenas soa bem numa proposta.

O mecanismo é real e fácil de explicar a um auditor. Cada visualização de uma página dinâmica no WordPress arranca um processo PHP-FPM e um conjunto de consultas ao MySQL, pelo que a visualização consome ciclos de CPU num centro de dados. Uma página estática sai da cache na periferia da rede e, num acerto de cache normal, não ocupa qualquer processo aplicacional. A direção da diferença não está em causa.

O número está. Não entregamos aos clientes uma percentagem de redução de consumo energético, porque não a medimos, e os valores que circulam em material comercial não têm metodologia publicada por trás. Se tiver de entrar um número concreto num relatório, tem de vir dos dados do fornecedor de alojamento para aquele período, e não de uma comparação de arquiteturas.

Conselho prático: use aquilo que o seu fornecedor publica de facto sobre a infraestrutura e o mix energético, e cite-o como declaração dele, não como medição sua. Passar para uma arquitetura estática é um argumento sobre consumo de recursos, não um certificado ambiental.

#A minha previsão para 2026 e 2027

O WordPress mantém-se dominante em lojas WooCommerce, sites com equipas editoriais não técnicas, projetos construídos sobre plugins já feitos e empresas que precisam de arrancar depressa e barato.

O Astro com Cloudflare fica com os sites de conteúdo e os blogues orientados ao desempenho, os sites institucionais e páginas de destino, a documentação técnica e os sites multilingues com alcance global.

A minha estimativa de abril colocava os frameworks estáticos em 30 a 40 por cento dos sites de conteúdo que hoje correm sobre WordPress, até ao final de 2027. Mantenho-a, com a ressalva da secção anterior: essa migração só compensa onde o frontend está orçamentado como software.

#Conclusão

O WordPress 7.0 é uma versão sólida que não mexe nos alicerces da plataforma. O Astro 7 é mais arrumação por baixo do capô do que funcionalidades novas para o utilizador: compilador Rust por omissão, Vite 8 e um CSP mais rigoroso.

Se está a construir uma loja online: WordPress. Se está a construir um site institucional, um blogue ou uma página de destino onde contam o desempenho e o SEO: Astro 7 com Cloudflare. Se está a construir as duas coisas: pondere o híbrido.

Se tem dúvidas, escreva-me. Se o Astro é a escolha certa para o seu projeto, há mais na página de programador Astro.

Mariusz Szatkowski, programador WordPress e Astro. Organizador do WordCamp Gdynia, contribuidor do WordPress Core. Trabalha em ambas as plataformas para clientes na Polónia e na Europa.