Astro 7.0 est là : builds jusqu'à 61 % plus rapides, faut-il migrer ?

Astro 7.0 est disponible depuis le 14 juillet 2026, et l'équipe du framework revendique des builds jusqu'à 61 % plus rapides sur ses propres benchmarks. Ce n'est pas un simple numéro de version qui grimpe : le compilateur .astro, le pipeline Markdown et MDX, et le moteur de rendu ont tous été réécrits ou remplacés dans cette version majeure.

Pour un site vitrine de quelques pages, la différence ne se sentira pas forcément au quotidien. Mais si vous gérez une documentation, un blog volumineux ou un catalogue e-commerce à plusieurs milliers de pages, Astro 7 change concrètement le temps que vous attendez avant chaque déploiement. On détaille ce qui change, pour qui, et comment migrer sans mauvaise surprise.

Astro en deux mots, pour ceux qui découvrent

Rappel rapide : Astro est un framework web pensé pour générer des sites rapides en limitant le JavaScript envoyé au navigateur, via son architecture d'îlots interactifs. Il équipe des sites de documentation, des blogs et des sites vitrines, et sert de socle à des projets à fort trafic : la documentation officielle d'Astro elle-même (docs.astro.build) ou la documentation développeurs de Cloudflare en font partie, ce qui explique pourquoi la vitesse de build est un sujet suivi de près par l'équipe du projet.

Le gros chantier : tout ce qui pouvait être réécrit en Rust l'a été

Le compilateur .astro, jusqu'ici écrit en Go, est entièrement réécrit en Rust, construit sur oxc pour le parsing et Lightning CSS pour le scoping des styles. Cette réécriture apporte, seule, un gain d'environ 6 % sur les temps de build de docs.astro.build. Un chiffre modeste en apparence, logique puisque la compilation .astro n'est rarement le principal goulot d'étranglement : c'est surtout le traitement Markdown et le bundling qui pèsent sur la durée totale.

C'est justement là que se joue le plus gros changement. Le pipeline Markdown et MDX, jusqu'ici basé sur unified (remark, rehype et une longue liste de plugins JavaScript), est remplacé par défaut par Sätteri, un processeur écrit en Rust par l'équipe cœur d'Astro, qui s'appuie sur pulldown-cmark pour le CommonMark et sur Oxc pour les expressions MDX. Sur les builds de la documentation Astro et de la documentation Cloudflare, le passage à Sätteri a fait gagner plus d'une minute. Sätteri intègre nativement des fonctionnalités qui nécessitaient jusque-là des plugins séparés : tableaux et notes de bas de page GFM, ponctuation intelligente, identifiants de titres, directives de conteneurs, formules mathématiques, frontmatter YAML ou TOML. Les projets qui dépendent de plugins remark ou rehype spécifiques gardent un accès à l'ancien pipeline via le package @astrojs/markdown-remark.

Enfin, Astro 7 embarque Vite 8, décrit par l'équipe comme la mise à jour la plus significative de Vite depuis des années. Le changement central : Vite embarque désormais Rolldown, un bundler écrit en Rust qui remplace à la fois esbuild et Rollup par un outil unique, jusqu'à 10 à 30 fois plus rapide que Rollup selon les benchmarks cités, tout en conservant la compatibilité avec les API de plugins Rollup et Vite. Une couche de compatibilité convertit automatiquement la configuration esbuild et rollupOptions existante vers ses équivalents Rolldown, donc la plupart des projets n'ont rien à changer.

Les chiffres publiés par Astro

Sur des tests réalisés sur un MacBook Pro Apple M4 Pro (48 Go de mémoire), l'équipe Astro annonce des gains de 15 à 61 % selon les sites, certains dépassant le double de vitesse. Quelques exemples cités dans leur communiqué :

• astro.build (environ 308 pages) : de 62,70 s à 24,24 s.
• docs.astro.build (environ 6 313 pages) : de 114,54 s à 73,53 s.
• tauri.app (7 117 pages) : de 86,12 s à 55,33 s.
• developers.cloudflare.com (8 431 pages) : de 386,89 s à 261,94 s.
• biomejs.dev (environ 6 488 pages) : de 176,39 s à 149,90 s.
• aspire.dev (13 275 pages) : de 385,84 s à 326,11 s.

Constat logique : les sites où la compilation .astro et le traitement Markdown pèsent le plus lourd dans le build sont ceux qui gagnent le plus, puisque ce sont exactement les étapes déplacées vers Rust.

Rendu, cache de routes et CDN : moins de travail répété

Le queued rendering, introduit en option expérimentale dans Astro 6.0, devient stable et le moteur de rendu par défaut. Il remplace l'ancienne approche récursive par une file d'attente qui organise plus efficacement le rendu des sections de page, pour un gain annoncé d'environ 2,4 fois sur la vitesse de rendu.

Astro 7 stabilise aussi le cache de routes et ajoute des fournisseurs de cache CDN expérimentaux pour Netlify, Vercel et Cloudflare. L'idée derrière ces deux ajouts est simple : le build le plus rapide reste celui qu'on évite de refaire. Si une route n'a pas changé, pourquoi la reconstruire ou la resservir depuis l'origine ?

Advanced Routing : un point d'entrée bas niveau sur les requêtes

Astro 7 introduit également l'Advanced Routing, avec un nouveau point d'entrée src/fetch.ts qui donne un contrôle complet sur le pipeline de requêtes d'Astro. Concrètement, c'est une porte d'entrée pour des logiques de routage ou de middleware qui sortent du cadre du routage classique basé sur les fichiers, utile pour des cas avancés (A/B testing au niveau requête, réécriture d'URL complexe, logique multi-tenant).

Un œil sur les agents de codage IA

Autre signal de l'époque : Astro peut désormais détecter qu'un agent de codage (Copilot, Claude Code, Cursor ou équivalent) pilote le terminal, faire tourner le serveur de développement en arrière-plan, et produire des logs structurés au format JSON quand un agent a besoin d'un retour exploitable par une machine plutôt que par un humain. Un détail qui compte de plus en plus pour les équipes qui délèguent une partie de leurs tâches de développement à des agents IA.

Migrer : la procédure et les pièges du nouveau compilateur

Pour un projet existant, Astro recommande l'outil automatisé :

npx @astrojs/upgrade

Une mise à jour manuelle reste possible :

npm install astro@latest

Et pour démarrer un nouveau projet directement en version 7 :

npm create astro@latest

Le point de vigilance se situe dans le nouveau compilateur Rust, qui n'est pas strictement identique à l'ancien sur deux points. D'abord, il ne corrige plus automatiquement le HTML mal formé : l'ancien compilateur Go réordonnait, fermait ou déplaçait silencieusement des balises pour produire du HTML valide, parfois de façon surprenante. Le nouveau compilateur traite votre balisage tel quel, et une balise non fermée ou un attribut mal terminé devient une erreur explicite plutôt qu'une correction silencieuse : ce sont de vrais bugs de template qui remontent enfin. Ensuite, la gestion des espaces entre éléments suit désormais les conventions JSX, comme React : un retour à la ligne entre deux éléments en ligne ne produit plus d'espace visible automatiquement, il faut l'expliciter avec une expression littérale dédiée.

Rien de bloquant, mais ce sont exactement les deux points à vérifier en priorité sur un environnement de préproduction avant de basculer un site en production, surtout si votre balisage existant comptait sur la tolérance de l'ancien compilateur.

Qui a intérêt à migrer maintenant

Pour un site vitrine ou un petit blog d'une PME française, le gain de vitesse de build ne se traduira pas forcément par un ressenti fort : quelques secondes gagnées sur un déploiement qui prenait déjà peu de temps. La migration reste néanmoins peu risquée grâce à l'outil automatisé, et il n'y a pas de raison sérieuse d'attendre.

Pour une documentation technique, un blog à forte volumétrie ou un catalogue e-commerce de plusieurs milliers de pages, le calcul change. C'est exactement le profil des sites qui gagnent le plus dans les benchmarks publiés par Astro : moins de temps de build signifie des déploiements en continu plus rapides, un environnement de CI moins sollicité, et une boucle de retour plus courte pour les équipes de contenu.

Notre lecture chez CZSyn

Cette version s'inscrit dans une tendance de fond qui dépasse Astro : la bascule progressive de l'outillage JavaScript vers des composants natifs écrits en Rust, déjà largement engagée par Vite avec Rolldown et par Lightning CSS. Le message envoyé par l'équipe Astro est clair : la compatibilité reste la priorité, plugins Vite et Rollup toujours pris en charge, ancien pipeline Markdown disponible en option, pendant que les fondations accélèrent en coulisses.

Notre recommandation pour les clients que nous accompagnons : testez la migration sur une branche dédiée avec l'outil @astrojs/upgrade, faites tourner votre build complet une première fois pour repérer les erreurs de balisage remontées par le nouveau compilateur, puis comparez vos temps de build avant et après. Sur un site de quelques dizaines de pages, l'opération se règle en une demi-journée. Sur un site de plusieurs milliers de pages, c'est là que le gain de build devient un argument business, pas seulement un confort de développeur.

Sources primaires

• Astro, « Astro 7.0 », billet officiel.
• Documentation officielle Astro, docs.astro.build.
• Sätteri, processeur Markdown/MDX d'Astro 7, satteri.bruits.org.