O Astro 7.4 adicionou a opção --timings ao comando de build e abriu, como recurso experimental, o prerender de páginas em worker threads. As duas mudanças se complementam: a primeira localiza o custo; a segunda tenta distribuir a parte paralelizável entre núcleos.
A versão foi publicada em 15 de outubro de 2026. Ela também elevou o Node.js mínimo para 22.22.0, separou serviços de imagem usados no build e no runtime, acrescentou um handler notFound() para entrypoints compostos e passou a avisar sobre configurações de fonte que o provedor não oferece.
--timings divide o build em fases
Ao executar astro build --timings, o relatório separa configuração, setup, bundles e geração de páginas. Ele também detalha plugins do Vite, processamento de Markdown, syntax highlighting, renderização por página, transformações de imagem e integrações.
O resumo lista as páginas mais lentas e apresenta mediana e p95. Isso ajuda a distinguir um custo fixo do projeto de um layout ou rota que fica mais cara conforme o número de páginas cresce.
O exemplo oficial encontrou chamadas encadeadas
No exemplo da equipe, cada post buscava comentários e depois cada comentário buscava o perfil do autor. O relatório mostrou que gerar páginas consumia aproximadamente 81% do build e que quase todo o tempo estava na renderização dos componentes.
Ao buscar os perfis em paralelo com Promise.all() e passar os dados aos componentes, a geração caiu de 2,10 para 1,13 segundo no cenário demonstrado. O ponto não é que Promise.all() sempre resolve: a medição revelou duas rodadas de rede em sequência e indicou onde testar a mudança.
Prerender paralelo usa worker threads
O sinalizador experimental.parallelPrerender distribui páginas estáticas por worker threads do Node.js. Por padrão, o Astro usa todos os núcleos disponíveis menos um. É possível informar um número menor de workers.
Cada worker ainda renderiza em paralelo a quantidade de páginas definida em build.concurrency. A combinação multiplica o trabalho simultâneo e o uso de memória, então aumentar ambos sem medir pode causar falta de memória ou reduzir o ganho.
O recurso busca builds grandes com renderização pesada de CPU. Ele não tem efeito quando o adapter fornece o próprio mecanismo de prerender; entre os adapters oficiais citados no lançamento, isso ocorre com @astrojs/cloudflare.
A ordem recomendada é medir, corrigir e paralelizar
Uma chamada externa repetida por página pode ficar mais rápida com concorrência e, ao mesmo tempo, pressionar a API remota ou alcançar seu limite de taxa. Uma transformação de imagem pode usar todos os núcleos e se beneficiar de workers. Um build limitado por memória pode piorar quando cada thread replica estado.
Por isso, o próprio anúncio apresenta --timings como etapa anterior ao prerender paralelo ou ao build incremental. O relatório não escolhe a correção, mas evita aplicar concorrência a uma fase que não era o gargalo.