Astro : le framework qui n'envoie pas de JavaScript par défaut

La plupart des frameworks web modernes partent du principe qu'une page est une application. Ils envoient au navigateur le code nécessaire pour la reconstruire, puis la font vivre. C'est logique pour une messagerie ou un tableau de bord. Ça l'est beaucoup moins pour un site de contenu, où le visiteur lit et repart.

Astro part de l'hypothèse inverse : par défaut, aucun JavaScript n'est envoyé au navigateur.

L'architecture en îlots

Le principe tient en une phrase : la page est livrée en HTML fini, et seuls les morceaux réellement interactifs reçoivent du JavaScript.

Chaque composant interactif (une barre de recherche, un panier, un formulaire) est marqué individuellement par une directive qui décide du moment de son activation :

• client:load active le composant immédiatement au chargement
• client:idle attend que le navigateur n'ait plus rien d'urgent à faire
• client:visible attend que le composant entre dans l'écran

Le reste de la page (titres, textes, images, navigation) reste du HTML pur. Sur un article de blog avec un simple menu déroulant, cela signifie qu'on envoie le code de ce menu, et rien d'autre.

C'est ce qu'on appelle l'architecture en îlots : des zones interactives isolées dans un océan de HTML statique.

Astro 7 : la réécriture en Rust

Astro 7.0 est sorti le 22 juin 2026, et la version courante au moment où nous écrivons est la 7.3, publiée le 3 septembre.

La nouveauté principale n'est pas visible par les visiteurs : elle concerne le temps de construction du site. Le compilateur a été entièrement réécrit en Rust, remplaçant la version en Go, et le projet est passé à Vite 8 avec le bundler Rolldown, lui aussi écrit en Rust.

L'équipe annonce des compilations 15 à 61 % plus rapides, avec ces mesures sur des sites réels :

Pourquoi est-ce que ça compte pour vous, qui ne compilez rien ? Parce qu'un site statique doit être reconstruit à chaque publication. Sur un site de documentation de plusieurs milliers de pages, passer de six minutes à quatre change le rythme de travail d'une équipe éditoriale.

Astro 7 a aussi stabilisé le cache de routes, auparavant expérimental, avec une prise en charge des hébergeurs Netlify, Vercel et Cloudflare.

Qui l'utilise

C'est souvent la question qui tranche, et la réponse est publique : le site officiel affiche Google, Microsoft, Visa, Porsche, OpenAI, Cloudflare, Unilever, NBC News, The Guardian, Michelin, Netlify, Proton et Webflow parmi ses utilisateurs.

Ce ne sont pas des sites applicatifs. Ce sont des sites de documentation, de marque et de contenu, exactement le terrain pour lequel l'outil est conçu.

À quoi ça ne sert pas

Un article honnête doit dire où l'outil s'arrête.

Une application. Si chaque visiteur voit des données qui lui sont propres (un compte, un panier persistant, un tableau de bord), l'essentiel de votre interface sera interactif. Vous vous retrouverez à écrire une application dans un outil pensé pour ne pas en faire une, et un framework applicatif sera plus direct.

Un site que vous éditez vous-même sans développeur. Astro seul ne fournit aucune interface d'administration. Il faut lui en adjoindre une, et ce choix compte autant que le framework.

Un site qui n'a pas de problème. Si votre site actuel se charge vite et que vous le mettez à jour sans difficulté, changer de socle ne vous apportera rien de mesurable.

Ce qu'il faut retenir

Astro résout un problème précis : les sites de contenu alourdis par du JavaScript qui ne leur sert pas. Il le résout bien, et sa maturité n'est plus en question : deux versions majeures en six mois, un compilateur réécrit, et des entreprises qui l'exploitent à grande échelle.

Ce n'est pas un choix par défaut pour autant. La bonne question n'est jamais « quel framework ? » mais « qu'est-ce que ce site doit faire, et qui devra le faire vivre ? ». La réponse technique vient après.