Astro: por que usar em sites com milhares de páginas

Um site com 50 páginas perdoa quase qualquer escolha técnica. Um site com 5 mil não perdoa. Cada kilobyte de JavaScript extra, cada segundo a mais no build e cada campo de conteúdo sem padrão se repetem milhares de vezes.

O Astro é um framework web criado para esse tipo de projeto: sites guiados por conteúdo, como blogs, documentações, portais e catálogos. Este texto explica por que ele costuma funcionar bem em escala, com base na documentação oficial e em dados públicos consultados em 8 de outubro de 2026. Também mostra onde ele deixa de ser a melhor escolha.

Uma transparência necessária: o site do Token & Tech é construído com Astro. Por isso, nos apoiamos em fontes verificáveis e apontamos os limites com o mesmo cuidado que as vantagens.

O que é o Astro

A página Why Astro? define o Astro como “o framework web para construir sites guiados por conteúdo”. Dois princípios aparecem logo no início.

O primeiro é ser server-first (servidor primeiro): o Astro prefere montar o HTML no servidor ou no momento do build, em vez de montar a página no navegador do visitante. O segundo é o zero JavaScript por padrão: as páginas chegam ao navegador sem JavaScript, a não ser que você peça.

Em junho de 2026, a equipe lançou o Astro 7. Em janeiro do mesmo ano, a empresa responsável pelo projeto passou a fazer parte da Cloudflare. Segundo o anúncio, o Astro continua de código aberto, sob licença MIT, e segue compatível com várias plataformas de hospedagem, não só a da Cloudflare. Vale acompanhar se essa promessa se mantém, já que ela é uma declaração de intenção, não uma garantia técnica.

Por que o número de páginas muda a escolha

Em um site pequeno, um framework pesado custa pouco. Em um site grande, três custos se acumulam.

• Custo para o visitante: o JavaScript que cada página carrega pesa no celular de quem lê, principalmente em conexões lentas.
• Custo de build: o build é a etapa em que o framework transforma código e conteúdo nos arquivos finais do site. Com milhares de páginas, ele pode levar minutos.
• Custo editorial: milhares de arquivos de conteúdo só ficam consistentes se houver regras que o computador consiga verificar.

O Astro tem respostas para os três. Nenhuma é mágica, e cada uma tem contrapartidas.

Ilhas: interatividade só onde precisa

O conceito central do Astro é a arquitetura de ilhas. A documentação sobre ilhas descreve a página como HTML estático, com pequenas “ilhas” de JavaScript apenas onde há interatividade ou personalização. O termo “ilha de componente” foi cunhado em 2019 por Katie Sylor-Miller, então na Etsy, e expandido em 2020 por Jason Miller, criador do Preact, segundo a mesma página.

Na prática, funciona assim. Por padrão, o Astro remove todo o JavaScript de cliente dos componentes. Para tornar um componente interativo, você adiciona uma diretiva client:*. Existem variações: client:load carrega o componente imediatamente, client:idle espera o navegador ficar ocioso e client:visible só carrega quando o componente entra na tela.

Isso vale também para componentes de outras bibliotecas. O Astro tem integrações oficiais para React, Preact, Svelte, Vue, SolidJS e AlpineJS. Um componente React usado no Astro vira HTML estático no servidor e só envia JavaScript se receber uma diretiva de cliente.

Para um portal com milhares de artigos, a consequência é direta. O texto, os títulos e os links, que são a maior parte da página, chegam como HTML pronto. O botão de busca ou o formulário de newsletter carregam o próprio JavaScript, sem arrastar o resto da página junto.

Há ainda as ilhas de servidor, ativadas com server:defer. Elas renderizam um trecho dinâmico no servidor, separado do resto da página, e mostram um conteúdo provisório enquanto isso. Servem, por exemplo, para exibir o avatar de um usuário logado sem atrasar o carregamento do artigo.

Conteúdo como dado: coleções com schema

O segundo pilar para sites grandes são as coleções de conteúdo (content collections). A documentação das coleções explica que cada conjunto de conteúdo é declarado em um arquivo de configuração, com um loader, que é a peça que lê os dados.

O loader glob() lê pastas de arquivos Markdown, MDX, JSON ou YAML. O file() lê várias entradas de um único arquivo. Loaders próprios podem buscar dados de um CMS, de um banco de dados ou de uma API.

Cada coleção pode ter um schema, uma descrição formal de quais campos cada item deve ter e de que tipo. O Astro usa a biblioteca Zod para isso. Se um artigo estiver sem data ou com um campo errado, o build acusa o erro. A mesma estrutura gera tipos de TypeScript e permite ligar itens de coleções diferentes com reference(), como um artigo ligado ao seu autor.

Dois pontos da documentação interessam a quem tem muito conteúdo. As coleções geradas no build servem para dados “relativamente estáticos”, podem ser guardadas em cache entre um build e outro e, segundo a página, comportam “dezenas de milhares de entradas”. Para volumes ainda maiores, a própria documentação sugere renderizar páginas sob demanda em vez de gerar tudo de uma vez.

O detalhamento desse recurso está no texto sobre Content Collections do Astro.

Gerar milhares de rotas no build

No modo estático, que é o padrão, o Astro precisa saber todas as rotas no momento do build. A documentação de rotas explica que uma página dinâmica, como [slug].astro, exporta a função getStaticPaths(), que devolve a lista de URLs a criar. A função paginate() divide listas longas em páginas numeradas, com links de anterior e próxima.

Quanto tempo isso leva depende do projeto. O único número publicado com método e máquina descritos vem da própria equipe do Astro, no anúncio da versão 7. Os testes rodaram em um MacBook Pro com chip M4 Pro e 48 GB de memória. Alguns resultados, antes e depois da atualização:

Site	Páginas (aprox.)	Antes	Depois
docs.astro.build	6.313	114,54 s	73,53 s
developers.cloudflare.com	8.431	386,89 s	261,94 s
aspire.dev	13.275	385,84 s	326,11 s

Leia esses números com cautela. Eles foram medidos pelo fornecedor, em uma máquina de alto desempenho, e a página não descreve quantas vezes cada build foi repetido. Servem para mostrar a ordem de grandeza (minutos, não horas, para sites de 6 a 13 mil páginas), não para prever o seu caso.

Na versão 5, de dezembro de 2024, o anúncio oficial já falava em builds de coleções até cinco vezes mais rápidos para Markdown em sites com muito conteúdo e em uso de memória de 25% a 50% menor. A página também não descreve o método.

A referência de configuração mostra dois ajustes ligados a builds grandes. O cacheDir define onde ficam artefatos reaproveitados nos builds seguintes. O build.concurrency define quantas páginas são geradas em paralelo. A documentação recomenda manter o valor padrão, 1, na maioria dos casos, e avisa que um número alto demais pode deixar o build mais lento por falta de memória.

Quando gerar tudo no build não é mais suficiente

Gerar todas as páginas antes tem uma consequência: para atualizar um conteúdo, é preciso rodar um novo build. Em um blog, isso é aceitável. Em um catálogo com preços que mudam a toda hora, não.

A documentação de renderização sob demanda mostra a saída. Com um adaptador, que é o pacote que conecta o Astro a um ambiente de servidor (Node.js, Netlify, Vercel, Cloudflare e outros), você marca páginas específicas com export const prerender = false. Elas passam a ser montadas a cada visita, e o resto do site continua estático.

A mesma página recomenda começar pelo modo estático e só mudar o padrão para servidor quando a maioria das páginas precisar disso. Para dados que mudam muito, as coleções também têm uma versão “ao vivo” (live collections), que busca os dados a cada requisição, mas exige um adaptador e não aceita MDX nem otimização de imagens, segundo a documentação das coleções.

O que os dados de campo mostram

Promessas de desempenho só valem se aparecem em sites reais. O relatório de tecnologias do HTTP Archive, projeto independente que monitora a web, permite comparar frameworks com dados de uso real.

O relatório mede a fatia de origens (domínios) com bons resultados nas três Core Web Vitals, as métricas do Google para velocidade de carregamento (LCP), estabilidade visual (CLS) e resposta a cliques e toques (INP). A avaliação usa o percentil 75 dos carregamentos de página, separado entre celular e computador.

No dado mais recente disponível, referente a agosto de 2026:

• Astro: 71,0% das origens no celular com as três métricas boas (43.850 origens avaliadas) e 83,6% no computador.
• Média de toda a web medida: 53,0% no celular.
• JavaScript na página inicial: a mediana dos sites em Astro foi de cerca de 405 KB no celular.

Esse último número desfaz um mito. “Zero JavaScript por padrão” não significa zero JavaScript na prática: sites reais adicionam componentes interativos, análise de audiência e scripts de terceiros.

Também há limites no próprio método. Segundo o FAQ do HTTP Archive, as tecnologias são detectadas com a ferramenta Wappalyzer e o rastreamento testa só a URL listada, em geral a página inicial, que pode não representar o site inteiro. E há um viés que nenhum painel corrige: na avaliação da redação, quem escolhe Astro costuma fazer sites de conteúdo, que tendem a ser mais leves do que aplicações. A correlação não prova que o framework, sozinho, causa o resultado.

Quando o Astro não é a melhor escolha

A documentação do Astro é franca sobre o foco. O guia de migração a partir do Next.js observa que aplicações muito interativas, como painéis, podem exigir técnicas avançadas no Astro.

Alguns sinais de que outro caminho pode ser melhor:

• A maior parte da página é interativa. Se quase tudo é estado, formulário e atualização em tempo real, a vantagem das ilhas diminui.
• Navegação de aplicativo. O Astro é, por padrão, um site de várias páginas. O componente <ClientRouter /> transforma a navegação em algo parecido com um aplicativo de página única, mas a documentação de transições avisa que pode ser preciso reinicializar scripts e estado manualmente a cada troca de página.
• Conteúdo que muda o tempo todo, em todas as páginas. Dá para resolver com renderização sob demanda, mas aí você perde parte da simplicidade do site estático e passa a manter um servidor.
• Equipe já especializada em outro ecossistema. O custo de aprender e migrar também conta.

Nesses casos, frameworks voltados a aplicações, como o Next.js, tendem a se encaixar melhor. A comparação detalhada está em Astro ou Next.js: arquitetura e desempenho comparados.

O que levar deste texto

• O Astro foi desenhado para sites de conteúdo: HTML gerado antes, JavaScript só nas ilhas que você escolher.
• Em escala, os ganhos vêm de três frentes: menos código no navegador, rotas geradas a partir de coleções com schema validado e builds com cache. Os números de build publicados são do próprio fornecedor e servem como ordem de grandeza.
• Dados de campo do HTTP Archive, de agosto de 2026, mostram sites em Astro acima da média da web nas Core Web Vitals, mas a medição é de páginas iniciais e não isola o efeito do framework.
• Se o seu projeto é mais aplicação do que publicação, ou se o conteúdo muda a cada minuto, avalie renderização sob demanda ou outro framework antes de decidir.