Migrer de Next.js vers Astro : retour d'expérience
J'ai migré mon portfolio de Next.js vers Astro. Voici ce que j'ai appris sur les différences d'approche, les pièges à éviter et les gains concrets.
Après plusieurs mois avec Next.js pour mon portfolio, j’ai décidé de migrer vers Astro. Voici un retour honnête sur ce que ça change.
Pourquoi migrer ?
Next.js est un framework puissant, mais pour un site statique comme un portfolio, il embarque beaucoup de JavaScript inutile. Astro génère du HTML pur par défaut — le JavaScript n’est chargé que si nécessaire, via les islands.
Ce qui change vraiment
Le modèle de composants
Avec Next.js, tout est React. Avec Astro, les .astro sont des templates HTML avec un frontmatter TypeScript — aucune hydration par défaut.
---
// Ce code s'exécute côté serveur/build uniquement
const data = await fetch("...").then(r => r.json());
---
<ul>
{data.map(item => <li>{item.name}</li>)}
</ul>Les islands React
Pour les composants interactifs (menu burger, lightbox…), on garde React avec une directive :
<Navbar client:load pathname={Astro.url.pathname} />
<ProjectGallery client:load images={project.images} title={project.title} />next/link et next/image
<Link href="...">→<a href="..."><Image src="..." width={} height={} />→<img src="..." />
Pour les images, Astro a son propre composant <Image /> de astro:assets si vous voulez l’optimisation automatique.
Les gains
- Bundle JS réduit : les pages sans interactivité n’embarquent aucun JS React
- Build rapide : Vite + génération statique
- Content Collections : le blog typé avec Zod, natif dans Astro
Ce qu’on perd
- L’écosystème React pur (mais les islands compensent)
usePathname()— à remplacer par une prop passée depuis Astro
Conclusion
Pour un portfolio ou un site à contenu, Astro est un meilleur choix que Next.js. Le passage n’est pas si complexe si vos composants React ne dépendent pas trop de l’état global.