Apparu fin 2021 et gagnant rapidement en popularité au cours de l’année 2022, Astro adopte une philosophie qui tranche avec Next.js ou Nuxt : plutôt que d’envoyer un bundle JavaScript complet au navigateur pour hydrater l’intégralité de la page, Astro génère par défaut du HTML pur, sans aucun JavaScript, et ne charge des composants interactifs que là où c’est explicitement nécessaire. Cette approche, appelée islands architecture (architecture en îlots), séduit particulièrement les projets à dominante éditoriale, un profil qui correspond bien à de nombreux sites WordPress headless.
Ce tutoriel construit un blog headless avec Astro et l’API REST WordPress, pour évaluer concrètement ce que cette approche change par rapport à un frontend React ou Vue classique.
Le principe des composants .astro
Astro introduit son propre format de fichier, .astro, qui sépare clairement un bloc de script exécuté à la compilation (entre deux délimiteurs ---) du template HTML qui suit. C’est dans ce bloc de script qu’on récupère les données, comme on le ferait dans getStaticProps côté Next.js, mais de façon plus directe :
---
// src/pages/index.astro
const reponse = await fetch(
'https://exemple.fr/wp-json/wp/v2/posts?_embed&per_page=10'
);
const articles = await reponse.json();
---
<html lang="fr">
<body>
<ul>
{articles.map( ( article ) => (
<li>
<a href={`/articles/${article.slug}`}>
{article.title.rendered}
</a>
</li>
) )}
</ul>
</body>
</html>
Ce code s’exécute uniquement côté serveur, au moment du build (ou à la requête, selon le mode choisi). Aucune ligne de ce JavaScript n’est envoyée au navigateur : le résultat livré au visiteur est du HTML pur, déjà rendu.
Les pages dynamiques avec getStaticPaths
Astro reprend une convention proche de Next.js pour les routes dynamiques, avec sa propre fonction getStaticPaths :
---
// src/pages/articles/[slug].astro
export async function getStaticPaths() {
const reponse = await fetch(
'https://exemple.fr/wp-json/wp/v2/posts?_fields=slug&per_page=100'
);
const articles = await reponse.json();
return articles.map( ( article ) => ( {
params: { slug: article.slug },
} ) );
}
const { slug } = Astro.params;
const reponse = await fetch(
`https://exemple.fr/wp-json/wp/v2/posts?slug=${slug}&_embed`
);
const [ article ] = await reponse.json();
---
<html lang="fr">
<body>
<h1>{article.title.rendered}</h1>
<div set:html={article.content.rendered} />
</body>
</html>
La directive set:html joue le même rôle que dangerouslySetInnerHTML en React ou v-html en Vue : elle injecte le contenu HTML renvoyé par WordPress sans l’échapper.

Où l’architecture en îlots change vraiment la donne
Pour un blog essentiellement composé de texte et d’images, la quasi-totalité des pages n’a besoin d’aucune interactivité JavaScript. Astro tire parti de ce constat en n’envoyant, par défaut, strictement aucun script au navigateur. Si une page contient malgré tout un élément interactif, un carrousel d’images ou un formulaire de recherche par exemple, il suffit d’écrire ce composant avec React, Vue ou Svelte (Astro supporte plusieurs frameworks simultanément) et de l’hydrater explicitement avec une directive client :
<RechercheArticles client:visible />
La directive client:visible ne charge le JavaScript de ce composant que lorsqu’il entre dans le viewport, une granularité de contrôle qu’aucun des frameworks purement React ou Vue n’offre nativement à ce niveau de précision.
Astro contre Next.js pour un blog headless
- Un blog très majoritairement statique, sans interactivité poussée, tire un net avantage de poids de page avec Astro
- Un site avec des zones fortement interactives (tableau de bord, filtre dynamique complexe) reste plus naturel à construire avec un framework React ou Vue complet
- Astro permet de mélanger plusieurs frameworks UI sur un même projet, un atout si l’équipe est hétérogène, mais aussi une source de complexité si mal maîtrisé
Sur un site vitrine ou un blog à faible interactivité, le gain de performance d’Astro se voit dès les premiers tests Lighthouse, sans optimisation manuelle particulière. C’est un argument de poids pour tout projet où le contenu prime sur l’interactivité.
En résumé
Astro apporte une réponse convaincante à un problème réel des frameworks JavaScript classiques : envoyer du code inutile pour des pages qui n’en ont pas besoin. Pour un blog ou un site vitrine headless WordPress, où le contenu domine largement l’interactivité, c’est une option sérieuse à évaluer face à Next.js ou Nuxt, avec un gain de performance mesurable dès les premiers déploiements.