Pourquoi nous développons désormais avec Astro

Nous avons longtemps livré nos projets web avec Nuxt, et nous en avons dit du bien — notamment dans notre article sur le SSR et le SEO. Depuis 2026, Astro est notre stack par défaut pour les sites de contenu. Ce n'est pas un effet de mode : c'est le résultat d'un constat répété sur nos propres recettes de performance. Voici le raisonnement complet, limites comprises.

Le vrai problème n'était pas le rendu, mais le JavaScript

Le Server-Side Rendering a réglé un problème réel : celui du contenu invisible pour Googlebot. Sur ce point, Nuxt fait très bien son travail — les pages arrivent en HTML complet, l'indexation est immédiate. Ce n'est pas ce qui nous a fait changer.

Ce qui nous a fait changer, c'est ce qui se passe après le premier rendu. Un meta-framework classique renvoie du HTML, puis expédie l'intégralité du framework au navigateur pour « reprendre la main » sur cette page — c'est l'hydratation. Sur une application métier, c'est indispensable. Sur une page de contenu qui contient un menu déroulant et un formulaire, on paie le prix fort pour trois interactions.

Ce coût se voit précisément là où c'est le plus difficile à rattraper : le temps de parsing et d'exécution du bundle génère des tâches longues sur le thread principal, ce qui dégrade l'INP, et retarde la stabilisation de la page, ce qui dégrade le LCP. Nous détaillons ces métriques dans notre guide des Core Web Vitals.

Ce que change l'architecture en îlots

Astro inverse la logique par défaut. Une page part en HTML statique, sans runtime client. Chaque composant interactif est déclaré explicitement comme un îlot, avec sa propre stratégie de chargement :

• client:load — hydraté immédiatement (barre de recherche critique)
• client:idle — hydraté quand le navigateur est disponible (menu secondaire)
• client:visible — hydraté à l'apparition dans le viewport (carrousel en bas de page)
• client:media — hydraté seulement si une media query correspond (menu mobile)

Le point important n'est pas la syntaxe, c'est le défaut. Avec un meta-framework classique, l'interactivité globale est acquise et il faut travailler pour la réduire — code-splitting, lazy-loading, analyse de bundle. Avec Astro, l'interactivité coûte quelque chose, donc on la demande là où elle sert. Le budget JavaScript devient une décision explicite au lieu d'un héritage à optimiser.

Ce que nous avons perdu au passage

Annoncer uniquement les gains ne serait pas honnête. La bascule a un coût réel, et il vaut mieux le connaître avant de signer un devis.

• Le state management partagé — Pinia, côté Nuxt, offrait un magasin global confortable. Sur Astro, deux îlots qui doivent partager un état passent par nanostores ou par le DOM. C'est plus verbeux, et c'est le signal qu'il faut se demander si la page relève encore d'Astro.
• La maturité de l'écosystème — moins de modules prêts à l'emploi que dans l'écosystème Nuxt, où beaucoup de besoins courants sont couverts par un simple ajout de module.
• Le confort de la navigation SPA — les View Transitions comblent une bonne partie de l'écart, mais ce n'est pas exactement le même modèle.
• La montée en compétence — le framework s'apprend vite, mais raisonner en îlots demande de désapprendre l'habitude de tout rendre interactif par réflexe.

Quand nous ne choisissons pas Astro

Astro est un framework de contenu. Ce n'est pas une critique, c'est sa définition — et c'est ce qui le rend efficace. Nous ne le proposons pas quand le projet présente l'un de ces signes :

• Un état client partagé sur l'ensemble de l'écran (back-office, ERP, CRM interne)
• Du temps réel : tableau de bord live, messagerie, édition collaborative
• Une interface où plus de la moitié des composants sont interactifs
• Une équipe déjà structurée autour d'Angular ou de React, avec une base de code conséquente

Dans ces cas, nous partons sur Angular pour le front et Node.js pour l'API. Le comparatif critère par critère est détaillé dans notre benchmark des frameworks web 2026.

Comment nous migrons un site existant

Une migration vers Astro n'est pas une réécriture. Astro monte les composants Vue, React et Svelte existants, ce qui permet d'avancer par paliers sans geler les évolutions du site. Notre procédure type :

1. Cartographier les URLs et les positions acquises — rien ne doit bouger côté SEO sans redirection 301 correspondante.
2. Basculer d'abord les pages de contenu — ce sont celles qui pèsent en trafic organique et celles où Astro apporte le plus.
3. Réutiliser les composants interactifs existants en îlots — on les porte tels quels avant d'envisager de les réécrire.
4. Mesurer avant et après sur données terrain — CrUX et Search Console, pas seulement Lighthouse en local.
5. Traiter les sections applicatives en dernier, ou les isoler sur une autre stack si elles ne relèvent pas d'Astro.

Ce site, azur-it.fr, est encore servi par sa stack précédente : la bascule est en cours et sera documentée ici. Nous préférons le dire plutôt que d'afficher une vitrine qui ne correspondrait pas à la réalité du dépôt.

Faut-il migrer votre site ?

Pas systématiquement. Un site qui tient déjà ses Core Web Vitals au vert et qui ne bouge plus n'a rien à gagner à une migration. En revanche, la question mérite d'être posée si vous cochez plusieurs de ces cases : INP dans le rouge sur mobile dans la Search Console, refonte déjà budgétée, site éditorial avec beaucoup de pages, ou dépendance à un bundle JavaScript devenu difficile à réduire.

Le bon réflexe est de partir de la mesure, pas du framework. Notre checklist SEO technique permet de situer le problème avant d'envisager une bascule.

Questions fréquentes