Quem já vendeu sites sem manutenção sabe como é comum dizer ao cliente que vai entregar um CMS superfácil, no qual ele poderá fazer alterações grandes ou pequenas sem dificuldade.
Na proposta, o cliente acha ótimo, mas, depois da entrega, passa meses sem mudar nada. E, nas raras vezes em que quer alterar alguma coisa, escreve para você fazer.
É normal: ele está concentrado no próprio negócio e só quer que o site lhe traga clientes. Tudo certo.
Depois de ver isso tantas vezes, sempre achei que o WordPress é ótimo, especialmente para quem desenvolve, pois exige uma manutenção que nem sempre deveria ser necessária..
Por isso eu pensava que deveria haver alternativas. Outros caminhos que até agora não tinha encontrado.
Porque, com sites feitos em HTML puro, você sabe que qualquer mudança mínima, como o telefone do atendimento, leva um bom tempo. E muitas vezes você precisa de alguma funcionalidade complexa que, em princípio, exige uma linguagem de servidor.
E sim, PHP é uma opção, com seus includes e suas possibilidades. Mas o desenvolvimento fica bem mais complicado do que com WordPress. Sem falar que você precisará de hospedagem com essa linguagem instalada e terá de mantê-la atualizada.
Mas há pouco tempo descobri o Astro. E tudo fez sentido.
A filosofia do Astro: HTML primeiro, JavaScript só quando necessário
Se você ainda não conhece a ferramenta, pode começar entendendo o que é o Astro e como ele funciona, principalmente a parte técnica. Aqui vamos nos concentrar nas consequências práticas da sua arquitetura..
A proposta é entregar o conteúdo em HTML e reservar o código executado no navegador para as partes que realmente precisam dele. E, além da geração estática, também aceita renderização sob demanda.
Vamos ver o que isso significa.
As vantagens do Astro
Antes de começar, vale esclarecer que algumas vantagens são universais, enquanto outras só fazem sentido para certos tipos de site.
Vou explicar.
Desempenho desde a arquitetura
Em uma página de serviços, entregar um documento já pronto evita processamento durante a visita. Não é preciso um servidor para montar conteúdo que não mudou; basta devolver um arquivo HTML armazenado.
Isso cria uma ótima base para carregar (muito) rápido. Especialmente com imagens bem otimizadas (olá, webp), CSS otimizado e entrega eficiente dos arquivos.
A vantagem é que você começa com uma estrutura leve e depois acrescenta apenas o necessário, de forma consciente e por necessidade real..
O Astro procura evitar todo o JavaScript desnecessário, pois reduzir JavaScript diminui o download e também o trabalho do dispositivo. Em um PC geralmente não é problema, mas em um celular, sobretudo dos mais simples, pesa mais: ele precisa interpretar e executar tudo o que recebe, além de fazer o restante.
Num site informativo, enviar muita lógica que quase não acrescenta funções ao visitante é um desperdício de recursos.
Por outro lado, o Astro facilita a integração das pequenas ferramentas interativas realmente necessárias. O benefício continua se você controlar o que adiciona.
HTML limpo e boa base para SEO
Ter o conteúdo principal disponível em HTML facilita o acesso.
Além disso, é relativamente fácil seguir as boas práticas de SEO, pois permite criar uma estrutura clara de títulos, links e seções.
Menor superfície de ataque
Essa é boa para quem quer evitar manutenção.
Numa publicação estática, não há CMS nem banco de dados rodando na parte pública. Há menos funções expostas para proteger..
Isso reduz MUITO determinados riscos, embora não torne o projeto invulnerável. A conta de hospedagem, o repositório no GitHub e os serviços conectados ainda precisam de proteção. E, se você usa um formulário com backend, esse backend deve validar os dados e limitar abusos. O bom é que alguns sites quase nunca precisam disso.
Hospedagem simples e barata
Outra vantagem universal.
Servir arquivos estáticos costuma exigir menos infraestrutura do que executar uma aplicação com banco de dados e linguagem de servidor. Em projetos pequenos, um site estático pode caber num plano gratuito ou econômico, conforme as condições do provedor.
Aliás, uma das grandes vantagens é poder publicar gratuitamente o build do site no CloudFlare e não pagar nada de hospedagem. Sim, você elimina completamente esse custo.
Mas é preciso separar a hospedagem do site do restante do projeto:
- Pelo domínio, você sempre vai pagar.
- O e-mail também pode sair de graça..
- Se usar APIs — da Meta ou de outras empresas —, dependerá do uso.
Resumindo, dispensar o servidor tradicional não significa que tudo seja gratuito, mas elimina a maior despesa dos sites empresariais.
Componentes sem transformar o site inteiro numa SPA
Uma SPA (Single Page Application) é uma aplicação em que grande parte da navegação e da interface depende do código do navegador. Esse modelo pode servir para certos produtos (como as redes sociais e seus feeds), mas um site de serviços raramente precisa disso.
Já o Astro permite reaproveitar componentes e estruturas compartilhadas quando necessário, sem obrigar o site inteiro a funcionar como SPA. Você corrige um bloco comum uma vez e mantém páginas entregues como documentos normais.
Flexibilidade com o conteúdo
Não precisar de CMS não significa que você não possa incluir um.
Você pode começar com arquivos estáticos num site empresarial e conectar um CMS caso decida criar um blog. Também pode conectar sistemas que a empresa já utiliza e buscar dados neles.
Essa liberdade oferece soluções diferentes para todo tipo de site.
Integração com Git
Como precisa apenas de arquivos, sem banco de dados, o Astro se integra muito bem ao Git.
Manter o histórico do projeto no Git facilita ver o que mudou, testar antes de publicar e recuperar uma versão anterior.
Com IA escrevendo código, essa rastreabilidade é especialmente útil: você pode revisar uma alteração específica sem depender da memória do assistente.
Separação entre frontend e serviços externos
Sim, ter HTML é ótimo, mas só ele não faz um formulário funcionar e entregar as respostas. Para isso é necessário um servidor.
O bom é que, com HTML, você pode conectar a API de serviços como o Zoho Mail e receber as respostas no endereço de e-mail indicado. Tudo gratuitamente.
Se já usa essa ferramenta para o e-mail corporativo, não precisa adicionar mais nada ao seu stack.
Os principais pontos fracos do Astro
Agora vamos falar das desvantagens do framework, que o tornam pouco indicado para alguns projetos.
Não inclui um CMS pronto para usar
Quando vou desenvolver um site, minha primeira pergunta prática é: quem vai atualizá-lo ou mantê-lo?
Se o cliente espera abrir um painel, trocar uma foto e publicar, o Astro sozinho não oferece essa experiência. É preciso trabalhar com arquivos ou acrescentar uma ferramenta de edição.
Para um cliente que precisa mudar o site sem ligar para você, o Astro não é a melhor escolha.
Exige mais decisões técnicas
Você precisa decidir onde ficam os textos, como publicar mudanças, como implementar o formulário e o que fazer se algum serviço falhar.
Com um CMS como WordPress, quase tudo isso já vem pronto.
Mas a vantagem de fazer com Astro é poder planejar o sistema uma vez e reutilizá-lo em vários sites.
As integrações exigem desenvolvimento
Há serviços que facilitam muito o trabalho, mas você nem sempre encontrará uma solução pronta para instalar e atender a todas as necessidades, como os plugins típicos de um CMS.
Por exemplo, não basta criar o layout de um formulário. Você precisa conectar o envio, tratar erros, proteger credenciais e conferir se as mensagens chegam. Reservas com horários, pagamentos e cancelamentos multiplicam o trabalho e as decisões.
A IA pode acelerar a implementação, mas ainda é preciso alguém capaz de revisar o resultado e assumir a responsabilidade por ele.
Menos prático para equipes editoriais
Quem publica ocasionalmente pode trabalhar (relativamente) bem com Markdown. Uma equipe com vários autores, revisões, agendamento e gestão constante de imagens precisa de uma experiência editorial mais completa.
Ou seja, um bom e velho CMS.
É possível instalar um CMS adequado por cima do Astro; a pergunta é por que fazer isso em vez de usar apenas o CMS.
Builds podem complicar projetos enormes
Na geração estática, as páginas publicadas precisam ser construídas. O tempo depende da quantidade, de como os dados são obtidos e do processamento realizado.
Um catálogo grande com muitas imagens ou consultas externas pode complicar o processo. Não existe um número universal de URLs a partir do qual o Astro deixe de servir: é preciso medir o projeto e decidir o que gerar antes e o que renderizar sob demanda.
E, se uma atualização urgente depender de um build que falhar, o conteúdo antigo continuará publicado até a correção.
Ecossistema menor que o do WordPress
O Astro tem integrações e templates, mas não oferece a mesma quantidade de soluções prontas para necessidades empresariais muito variadas.
No WordPress é comum encontrar várias opções para reservas, áreas de membros ou fluxos editoriais. Com Astro talvez seja necessário conectar serviços ou desenvolver parte do comportamento. Isso afeta o tempo de desenvolvimento, o orçamento e quem poderá cuidar do site depois.
Curva de aprendizado para quem vem de PHP ou WordPress
Se seu processo habitual é instalar um tema e configurar plugins, aparecem novas ferramentas: pacotes, repositórios, builds e deploys.
Você não precisa dominar tudo de uma vez. Mas precisa entender o caminho dos arquivos editados até aquilo que vai ao ar. Caso contrário, pode pedir uma correção à IA, vê-la localmente e achar que já está no site de verdade.
Nem todo projeto combina com uma arquitetura estática
Tudo o que foi dito se resume a isto.
Uma página pública relativamente estável e um painel com dados pessoais em tempo real têm necessidades diferentes.
O Astro pode adicionar recursos de servidor e funcionalidades dinâmicas, mas outra plataforma talvez resolva melhor o conjunto. A questão não é se o Astro consegue, mas se vale a pena.
Esclarecimentos sobre as limitações do Astro
Já falei disso ao longo do artigo, mas quero resumir aqui para deixar tudo claro.
Não ter CMS não significa não poder usar um CMS
Você pode acrescentar um editor e uma fonte de conteúdo. A limitação real é ter de escolhê-los e integrá-los, com seus custos e manutenção.
Não exigir banco de dados não significa não poder utilizar um
O Astro não obriga a ter banco de dados num site simples.
Se o projeto precisar armazenar usuários, reservas ou informações variáveis, poderá se conectar a um banco. Chaves e consultas sensíveis devem permanecer num ambiente de servidor seguro.
Gerar conteúdo estático não significa que o Astro sirva apenas sites estáticos
Você pode combinar estratégias e serviços.
Uma página pronta pode enviar um formulário para um backend. O conteúdo público e o processamento da mensagem são tarefas diferentes.
O que importa para o carregamento é aquilo que o visitante recebe.
Parte do código serve para construir a página e não roda durante a visita. Confundir esses momentos leva a avaliar mal o peso real do site.
Quando eu escolheria o Astro
Vamos ao que importa.
Eu consideraria Astro para:
- Um site empresarial.
- Um portfólio.
- Documentação.
Desde que:
- As páginas sejam relativamente estáveis.
- Ninguém além de mim vá alterá-las.
- Eu queira bom desempenho.
- Baixo custo (sem pagar servidor).
- E meu stack inclua desenvolvimento com IA e integração com Git.
Quando eu não escolheria o Astro
Eu não usaria se:
- O cliente precisar editar por conta própria.
- O frontend precisar de mudanças constantes.
- O blog for o centro do site.
- Para uma revista.
- Para um ecommerce.
- Para uma área de membros.
Enfim, quando um CMS facilitar o trabalho.
Conclusão: o Astro nem sempre é melhor; depende do projeto
Adoro a abordagem do Astro. É algo que eu procurava há muito tempo, pois permite construir muitos sites com conteúdo estático e uma estrutura muito, muito ajustada às necessidades reais.
Além disso, integra-se muito bem à IA para desenvolver quase tudo.
Mas também é preciso pensar na vida desse site depois da entrega.
Se o cliente conseguir mantê-lo, as integrações estiverem resolvidas e o conteúdo combinar com a solução, é uma opção muito interessante.
Como você deve imaginar, a comparação que mais faço em cada projeto é Astro vs WordPress. No artigo do link, explico como decidir considerando todo o trabalho, da edição à manutenção e ao orçamento do cliente.
Perguntas frequentes
Quais são as principais desvantagens do Astro?
Não inclui um CMS pronto, exige mais decisões técnicas e alguns recursos precisam de desenvolvimento ou serviços externos. Também é menos prático para equipes que publicam conteúdo constantemente.
O Astro é bom para SEO?
Sim. Ele facilita entregar conteúdo em HTML e construir páginas leves e bem estruturadas. É uma boa base técnica, mas o posicionamento também depende do conteúdo, dos links e de outros fatores.
O Astro precisa de banco de dados?
Não. Um site simples funciona com arquivos estáticos, mas o Astro também pode se conectar a bancos para armazenar ou consultar informações dinâmicas.
É possível usar um CMS com Astro?
Sim. Você pode conectar um CMS para administrar o conteúdo, mas terá de escolher, integrar e manter essa ferramenta. O Astro não inclui um painel editorial completo de fábrica.
É possível hospedar um site Astro gratuitamente?
Sim. Um site estático pode ser publicado em serviços com planos gratuitos, como Cloudflare, se cumprir as condições. Domínio, e-mail e outros serviços podem ter custos separados.
O Astro permite criar sites dinâmicos?
Sim. Embora se destaque na geração estática, aceita renderização no servidor e conexões com APIs e serviços externos para adicionar funcionalidades dinâmicas.
O Astro é adequado para sites empresariais?
Para mim, é um dos melhores usos, sobretudo se o conteúdo muda pouco e a manutenção fica com alguém que entende da parte técnica. Permite criar sites rápidos sem um CMS tradicional.
O Astro é recomendado para blogs ou revistas?
Pode ser usado, mas não seria minha primeira escolha para uma revista ou blog com publicações frequentes e vários editores. O WordPress geralmente oferece gestão editorial mais confortável.
O Astro é melhor que o WordPress?
Depende do projeto. Eu escolheria Astro para sites empresariais relativamente estáveis e WordPress quando o cliente precisa editar conteúdo com frequência ou aproveitar recursos já disponíveis por plugins.
Deixe um comentário