Astro 7 mise sur Rust pour accélérer les builds

Le meta-framework Astro passe en version 7 avec une priorité clairement affichée : réduire le temps nécessaire pour construire les sites, en particulier ceux qui contiennent des milliers de pages. Pour y parvenir, Astro s’appuie davantage sur Rust, adopte Vite 8 et remplace plusieurs briques historiques de sa chaîne de compilation.

D’après les benchmarks publiés par l’équipe, les builds sont de 15 à 61 % plus rapides selon les projets. Les sites riches en fichiers Markdown et MDX devraient profiter des gains les plus importants. Astro 7 apporte également un contrôle plus fin sur le traitement des requêtes, stabilise le cache des routes et améliore son fonctionnement avec les agents de code.

Sommaire

1. Vite 8 et Rolldown
2. Un nouveau compilateur Astro écrit en Rust
3. Markdown et MDX passent à Sätteri
4. Le rendu par file d’attente devient la norme
5. Un contrôle complet du routage
6. Le cache des routes passe en stable
7. Des outils pensés pour les agents de code
8. Migration du site en pratique
9. Passer à Astro 7

Vite 8 et Rolldown

Astro 7 intègre Vite 8, dont la principale évolution est l’adoption de Rolldown. Ce bundler écrit en Rust remplace à la fois esbuild et Rollup dans Vite, tout en restant compatible avec leurs principales options et avec l’API des plugins Rollup.

Pour la majorité des projets Astro, cette transition devrait être transparente. Vite fournit une couche de compatibilité qui convertit notamment les configurations esbuild et rollupOptions. Les intégrations ou plugins qui utilisent des API internes de Vite devront en revanche être vérifiés avant la migration.

Pour aller plus loin sur le nouveau bundler, les gains de performance et la migration, consultez l’article consacré aux nouveautés de Vite 8.

Un nouveau compilateur Astro écrit en Rust

Le compilateur des composants .astro, auparavant écrit en Go, est entièrement remplacé par une implémentation en Rust. Le compilateur expérimental introduit avec Astro 6 devient donc le seul compilateur disponible dans Astro 7.

Le gain mesuré sur la compilation des seuls composants reste modéré, autour de 6 % sur le site de documentation d’Astro. Cette réécriture change toutefois certains comportements qu’il faut connaître avant une migration.

Le nouveau compilateur ne corrige plus silencieusement le HTML invalide. Une balise non fermée ou un attribut incomplet provoque maintenant une erreur. Il ne réorganise plus non plus les éléments pour tenter de produire un document valide. Enfin, les espaces entre les éléments suivent désormais les conventions de JSX. Deux éléments inline séparés par un retour à la ligne peuvent donc être rendus sans espace visible. Lorsqu’un espace est nécessaire, il faut l’ajouter explicitement avec {' '}.

Ce fonctionnement plus strict peut révéler des erreurs de template jusque-là masquées par l’ancien compilateur, mais il rend aussi le résultat produit plus prévisible.

Markdown et MDX passent à Sätteri

Astro 7 remplace la pipeline unified, fondée sur remark et rehype, par Sätteri pour traiter par défaut les fichiers Markdown et MDX. Ce processeur Rust était proposé en option depuis Astro 6.4. Il devient maintenant le choix standard.

Sätteri prend nativement en charge plusieurs fonctions qui nécessitaient auparavant des plugins, dont la syntaxe GitHub Flavored Markdown, les identifiants de titres, les notes de bas de page, les directives, les formules mathématiques, le frontmatter YAML ou TOML et les wikilinks. Son système de plugins peut cibler uniquement les types de nœuds utiles, ce qui évite de parcourir tout l’arbre de contenu à chaque transformation.

Les projets qui dépendent de plugins remark ou rehype ne sont pas bloqués. L’ancienne pipeline reste disponible avec @astrojs/markdown-remark, mais elle doit désormais être configurée explicitement.

Ce changement est l’une des principales sources d’amélioration pour les gros sites documentaires. D’après Astro, le passage à Sätteri a retiré plus d’une minute au build de sa documentation et à celui de la documentation Cloudflare.

Le rendu par file d’attente devient la norme

Le Queued Rendering, proposé à titre expérimental dans Astro 6, devient stable et activé par défaut. L’ancien moteur rendait récursivement chaque composant et ses enfants. La nouvelle implémentation place les éléments à traiter dans une file, puis les rend progressivement dans une seule boucle.

Cette stratégie consomme moins de mémoire et peut être environ 2,4 fois plus rapide sur les pages qui contiennent beaucoup d’expressions. Le gain sera plus limité sur des pages essentiellement statiques.

Un contrôle complet du routage avec src/fetch.ts

Astro 7 stabilise également l’Advanced Routing présenté dans Astro 6.3. La création d’un fichier src/fetch.ts permet de prendre la main sur tout le pipeline de requêtes avec une interface fondée sur le standard fetch.

Il devient ainsi possible de rediriger certaines requêtes vers un service externe, d’exécuter une authentification avant les Actions Astro ou de choisir précisément l’ordre des middlewares. L’API est aussi compatible avec Hono, dont les middlewares peuvent être composés avec les pages, les Actions et les fonctions d’internationalisation d’Astro.

Cette nouveauté vise surtout les applications qui dépassent le simple routage par fichiers. En l’absence de src/fetch.ts, Astro conserve son comportement habituel.

Le cache des routes passe en stable

Le Route Caching quitte lui aussi le statut expérimental. Astro propose maintenant une API indépendante de la plateforme pour mettre en cache les réponses générées à la demande. Les règles peuvent être définies dans une page avec Astro.cache, dans un endpoint avec context.cache ou globalement dans routeRules.

L’API gère notamment la durée de conservation, le stale-while-revalidate, l’invalidation par chemin et les tags. Elle s’intègre aux Live Content Collections, dont les loaders peuvent transmettre directement leurs informations de cache à Astro.

Astro fournit un provider en mémoire pour commencer. Des providers CDN expérimentaux sont également disponibles pour Netlify, Vercel et Cloudflare afin de servir les réponses directement depuis leur réseau edge. Le provider Cloudflare dépend toutefois d’une fonctionnalité encore en bêta privée.

Des outils pensés pour les agents de code

Astro 7 introduit plusieurs adaptations destinées aux outils de développement assistés par IA. La commande astro dev --background lance le serveur de développement comme un processus géré en arrière-plan. Astro peut détecter qu’il est exécuté par un agent et activer automatiquement ce mode.

Le serveur expose alors des commandes pour consulter son état, lire ses logs ou l’arrêter. Un fichier de verrouillage empêche le lancement accidentel de plusieurs instances et un endpoint /_astro/status permet de vérifier que le serveur est prêt.

Le logger devient aussi configurable et peut produire du JSON structuré avec astro dev --json. Cette sortie facilite le travail des agents, mais aussi l’envoi des logs d’une application SSR vers Kibana, CloudWatch ou Grafana Loki. Une API permet enfin de combiner plusieurs handlers pour conserver une sortie lisible dans le terminal tout en fournissant des données exploitables par d’autres outils.

Migration du site en pratique

Ce site étant construit avec Astro, sa migration a servi de test sur un projet réel contenant plusieurs centaines d’articles, de brèves, de guides et de pages générées statiquement. Le passage à Astro 7 s’est révélé assez simple, mais il a surtout mis en lumière plusieurs dépendances implicites et un problème d’organisation dans le code du projet.

Une mise à niveau automatique, puis quelques ajustements

La migration a été lancée sur une branche dédiée avec l’outil officiel :

npx @astrojs/upgrade

L’outil a mis à jour les dépendances et signalé les changements incompatibles. Il n’a modifié ni les templates ni la configuration Markdown. Le premier build a donc permis d’identifier les adaptations réellement nécessaires.

Le premier blocage concernait les anciennes options markdown.remarkPlugins, markdown.rehypePlugins et markdown.remarkRehype. Elles reposent sur le processeur unified, qui n’est plus installé par défaut avec Astro 7.

Le site utilisait rehype-external-links pour ajouter target="_blank" et les attributs rel adaptés aux liens externes. Installer @astrojs/markdown-remark aurait permis de conserver ce fonctionnement, mais aussi toute l’ancienne chaîne Markdown en JavaScript. Cette solution a fonctionné pendant un premier essai, puis a été écartée afin de conserver Sätteri.

Sätteri dispose de sa propre API de plugins HAST. La documentation officielle propose justement un exemple de traitement des liens externes, adapté ici aux besoins du site :

import { satteri } from '@astrojs/markdown-satteri';
import { defineHastPlugin } from 'satteri';

const externalLinks = defineHastPlugin({
  name: 'external-links',
  element: {
    filter: ['a'],
    visit(node, context) {
      const href = node.properties.href;
      const isExternal = typeof href === 'string'
        && (/^https?:\/\//.test(href) || href.startsWith('//'));

      if (isExternal) {
        context.setProperty(node, 'target', '_blank');
        context.setProperty(node, 'rel', ['noopener', 'noreferrer']);
      }
    },
  },
});

markdown: {
  processor: satteri({
    hastPlugins: [externalLinks],
  }),
}

Les anciens packages Markdown ont ensuite été retirés. Des tests ciblés ont confirmé que les liens externes conservaient leurs attributs, tandis que les liens internes et les ancres restaient inchangés.

Aligner les dépendances autour de Vite 8

La migration a également révélé que @tailwindcss/vite 4.2.1 ne déclarait pas encore sa compatibilité avec Vite 8. npm conservait donc une seconde installation de Vite 7 pour satisfaire ses dépendances.

La version 4.2.2 de Tailwind ajoute explicitement la compatibilité avec Vite 8. Le cœur et le plugin ont donc été mis à jour ensemble :

npm install @tailwindcss/vite@4.2.2 tailwindcss@4.2.2
npm install --save-dev vite@8.0.16

Après cette correction, Astro, Tailwind et vitefu utilisent la même installation de Vite.

Reproduire le véritable flux de déploiement

Un build local réussi ne suffisait pas à valider la migration. La reproduction du flux Docker complet a révélé deux autres dépendances cachées.

Le script de postbuild importait esbuild sans le déclarer dans package.json. Jusqu’à Astro 6, ce package était installé indirectement avec Vite. Comme Vite 8 utilise Rolldown, il a fallu déclarer esbuild explicitement :

npm install --save-dev esbuild

Le second problème venait de l’image node:22-alpine. Alpine repose sur musl, mais Sätteri 0.9.1 ne fournit pas de binding Linux musl. L’étape de construction utilise désormais une image Debian compatible glibc :

FROM node:22-bookworm-slim AS builder

L’image finale reste basée sur nginx:stable-alpine, car elle ne contient que les fichiers statiques produits par l’étape précédente. Le build Docker complet a ensuite validé l’installation, la génération des pages, les sitemaps, Pagefind et la minification des scripts.

Ce que la migration a réellement mis en évidence

Les premières mesures montraient un build Astro 7 légèrement plus rapide que le build Astro 6 réalisé avant la migration. Elles ne suffisent toutefois pas à isoler l’effet de la nouvelle version. Une seule exécution avait été réalisée pour chaque configuration et le temps total était largement dominé par le code du projet.

L’examen des logs a finalement révélé le principal problème. Plusieurs composants reconstruisaient, filtraient et triaient les mêmes collections pour chaque page. La sidebar recalculait les catégories, les tags, les dossiers et les contenus mis en avant. Les pages individuelles reparcouraient aussi les articles pour produire la navigation et les recommandations. Les pages de catégories et de tags reconstruisaient à leur tour leurs taxonomies.

Ces données sont maintenant préparées une seule fois pendant le build, puis partagées entre les routes. Les navigations et recommandations utilisent des index par URL, catégorie et tag. Les collections de guides, de dossiers et de glossaire suivent le même principe.

Cette optimisation a eu un effet bien plus important que l’écart observé pendant la migration du framework. Le build complet est passé de près de trois minutes à moins de vingt secondes sur la même machine. Une comparaison par empreinte SHA-256 a confirmé que les 587 fichiers HTML générés sont strictement identiques avant et après le changement. Le build Docker complet produit également le site, les sitemaps et l’index Pagefind sans erreur.

Ce résultat ne permet pas d’affirmer qu’Astro 7 est responsable de cette accélération. Le code optimisé n’a pas été reconstruit avec Astro 6 dans une configuration équivalente. La comparaison initiale reste donc un retour de migration utile, mais pas une mesure isolée des performances du framework.

Passer à Astro 7

La migration automatisée reste la méthode recommandée :

npx @astrojs/upgrade

Une mise à jour manuelle est également possible :

npm install astro@latest

Avant de migrer un projet existant, les principaux points à contrôler sont la validité des templates .astro, les espaces entre éléments inline, la compatibilité des plugins Vite et l’utilisation de plugins remark ou rehype. Les flags experimental.rustCompiler et experimental.queuedRendering peuvent être supprimés. Une configuration expérimentale du cache doit quant à elle être déplacée au niveau principal de astro.config.mjs.

Source : Astro 7.0.