Astro : un site de contenu qui n’envoie aucun JavaScript par défaut.

Ce qu'Astro change, en une phrase

Sur un framework React, une page statique reste un arbre React rendu au build, puis réhydraté dans le navigateur parce que le runtime doit reprendre la main quelque part. Le runtime est donc présent partout, y compris sur une page de texte qui ne contient aucune interaction.

Astro fait l'inverse : la page est un template rendu au build, aucun JavaScript n'est expédié par défaut, et le JavaScript n'existe que dans les îlots que vous marquez explicitement comme interactifs. C'est le modèle décrit par la documentation officielle d'Astro sur l'architecture en îlots.

Sur un site de 40 pages dont 38 sont du contenu, la différence est de l'ordre de 166 Ko de JavaScript compressé par page. C'est le chiffre que nous avons mesuré en navigateur sur notre propre site, pas une estimation d'éditeur.

Ce qui est acquis, et ce qui ne l'est pas

C'est le point sur lequel la plupart des discours Astro dérapent. Le gain est certain en octets. Il est incertain en Core Web Vitals, et nous préférons vous le dire avant de vous vendre une migration.

Sur notre propre site, ce qui pesait sur le LCP mobile n'était pas le JavaScript mais le retard d'affichage, 86 à 96 % du LCP, c'est-à-dire le CSS et les polices. Ces deux éléments sont identiques dans les deux frameworks.

Un audit avant décision évite exactement ce genre d'erreur d'attribution. C'est ce que nous faisons dans l'audit gratuit de votre site, parce qu'un chiffre de poids ne dit rien de ce que vos visiteurs attendent réellement à l'écran.

Le piège qui annule le gain principal

Un site a presque toujours un header interactif : megamenu, tiroir mobile, piège de focus au clavier. Ce composant est présent sur toutes les pages. Si vous le gardez en React avec une directive d'hydratation, React et son moteur de rendu repartent sur chaque page, et le gain d'Astro tombe à zéro.

La condition du gain n'est donc pas de choisir Astro. C'est d'écrire le shell du site sans framework d'interface. Corollaire utile à connaître avant de signer une migration : ce travail est faisable en restant sur votre framework actuel, et il délivre alors le même gain sans réécrire vos pages.

Astro ou Next.js : le critère que nous appliquons

Pour un site de contenu, Astro est notre défaut. Nous basculons sur Next.js seulement si au moins deux des conditions suivantes sont vraies. Une seule ne suffit pas : un formulaire de contact, une négociation de contenu pour les agents IA ou trois routes API sont parfaitement à leur place dans des endpoints Astro.

• Votre outil de conversion est une vraie application : moteur de scoring, espace d'administration, file d'attente, stockage, webhooks. Ce n'est plus une vitrine avec un formulaire.
• Vous réutilisez lourdement React : design system existant, bibliothèque de composants, interface à état partagé sur beaucoup de pages. Porter tout cela coûte plus cher que la taxe de bundle économisée.
• Vous avez besoin de Server Components, de streaming ou de rendu partiel prérendu. Astro n'a pas d'équivalent.
• Vous servez du contenu dynamique à forte cardinalité avec une revalidation agressive. C'est faisable en Astro, mais plus direct en Next.

Si votre projet ressemble davantage à un site institutionnel sur-mesure avec des intégrations lourdes qu'à un site de contenu, la réponse penchera vers Next. Si vous cherchez surtout un site corporate crédible et facile à faire vivre, Astro fait très bien le travail.

Ce qui porte tel quel, et ce qui se réécrit

Nous avons vérifié cette table contre la documentation officielle d'Astro 7 le 30 juillet 2026. Elle sert de base de chiffrage quand une migration est envisagée.

Quatre points décident du chiffrage. Tous les quatre sont documentés par l'éditeur, et méritent d'être lus avant de signer quoi que ce soit.

• Les collections de contenu : chaque entrée doit porter un identifiant unique, donc des données classées par slug se remappent.
• Le routage internationalisé : le repli fonctionne par route, pas par champ. Un merge champ par champ reste à écrire.
• Le middleware : il ne s'exécute pas sur une page prérendue tant qu'une option d'adaptateur ne l'active pas.
• Les actions serveur : elles ne peuvent pas s'exécuter sur une page prérendue, donc les formulaires passent par des endpoints.

Notre propre arbitrage, et pourquoi nous avons dit non

En juillet 2026, nous avons audité notre propre site pour décider s'il devait passer sur Astro. Verdict : non. Deux conditions de bascule vers Next étaient remplies, notre outil d'audit est une vraie application avec moteur de scoring et back-office à jeton.

Et surtout, nos pages sont déjà prérendues à 100 %. Astro n'aurait pas changé le modèle de rendu, seulement l'outil de build.

Nous racontons ce cas parce qu'il dit quelque chose d'utile sur la façon dont nous travaillons : l'arbitrage se fait sur des mesures, et il peut conclure contre la technologie à la mode. Si vous voulez le détail de la démarche avant de nous confier un projet, notre approche le décrit étape par étape.

Sortir de WordPress vers un site prérendu

C'est le cas de figure le plus fréquent. Un WordPress qui a accumulé des extensions, dont le back-office fait peur à l'équipe, et dont les pages mettent trois secondes à s'afficher. Astro règle la partie technique, à condition de traiter le sujet dans le bon ordre. Le détail de la démarche, les postes qui pèsent dans le chiffrage et ce que vous perdez en quittant WordPress sont traités sur la page migrer un site WordPress vers Astro.

• Inventaire des URLs existantes et de leurs positions, avant toute décision de structure
• Plan de redirections 301 écrit et validé avant la bascule, pas constaté après la chute
• Reprise des contenus dans des collections typées, avec les métadonnées et le maillage interne
• Reconstruction du shell sans framework d'interface, condition du gain réel
• Recette de non-régression : titres, descriptions, données structurées, sitemap, hreflang

Si votre équipe tient à un back-office familier et que la performance n'est pas votre problème principal, une refonte WordPress bien menée reste souvent le bon choix. Nous le disons quand c'est le cas.