Astro

Qu’est-ce qu’Astro ?

Astro est un framework web axé sur le contenu conçu autour d’un pari simple : la plupart des pages n’ont pas besoin de beaucoup de JavaScript. Par défaut, il rend les pages en HTML, n’envoie aucun JavaScript côté client sauf si vous le demandez, et vous permet d’ajouter des composants interactifs uniquement là où c’est nécessaire.

Cette architecture rend Astro exceptionnellement performant pour les types de sites qui constituent une grande partie du web : blogs, documentations, pages marketing, portfolios et produits riches en contenu. Astro n’est pas anti-JavaScript — il est pro-modération. Vous obtenez l’interactivité dont vous avez besoin, et rien de plus.

Composants .astro

Un composant Astro est un fichier composé d’un script frontmatter, d’un template et de styles optionnels dont la portée est limitée au composant.

---
// src/components/Card.astro
interface Props {
  title: string;
  href: string;
}

const { title, href } = Astro.props;
---

<a class="card" href={href}>
  <h3>{title}</h3>
  <slot />
</a>

<style>
  .card {
    display: block;
    border-radius: 1rem;
    padding: 1.5rem;
  }
</style>

Le frontmatter est exécuté sur le serveur lors du build ou à chaque requête. Le template est du HTML avec des expressions de type JSX, et le <slot /> permet à un parent de passer des enfants. Par défaut, les styles sont scoped au composant. Comme le composant s’exécute sur le serveur, vous pouvez interroger des bases de données, lire des fichiers et appeler des API directement dans le frontmatter.

Routage basé sur les fichiers

Les fichiers dans src/pages deviennent des routes, et les segments dynamiques utilisent des crochets.

src/pages/
├── index.astro            # /
├── about.astro            # /about
├── blog/
│   ├── index.astro        # /blog
│   └── [slug].astro       # /blog/:slug
└── rss.xml.js             # /rss.xml

Pour les routes dynamiques, vous exportez getStaticPaths pour déclarer les pages à générer, ou utilisez le SSR pour un rendu à la demande.

Collections de contenu

Les collections de contenu sont la réponse d’Astro pour la gestion du contenu structuré. Vous définissez un schéma, et chaque entrée markdown ou JSON est validée lors de la phase de build.

// src/content.config.ts
import { defineCollection, z } from "astro:content";

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    publishedAt: z.coerce.date(),
    tags: z.array(z.string()).default([]),
  }),
});

export const collections = { blog };

---
// src/pages/blog/index.astro
import { getCollection } from "astro:content";

const posts = (await getCollection("blog"))
  .sort((a, b) => b.data.publishedAt.valueOf() - a.data.publishedAt.valueOf());
---

<ul>
  {posts.map((post) => (
    <li>
      <a href={`/blog/${post.id}`}>{post.data.title}</a>
    </li>
  ))}
</ul>

Vous bénéficiez ainsi de la sécurité du typage, de la validation et d’un moyen simple d’interroger votre contenu sans avoir besoin d’une base de données. Pour un site comprenant des centaines d’articles ou de pages de documentation, c’est une amélioration considérable de l’expérience de développement.

L’architecture en îles (islands architecture)

C’est la fonctionnalité phare d’Astro. Une page est composée de HTML statique, et tous les composants interactifs sont des îles qui s’hydratent indépendamment. Vous contrôlez le moment où chaque île se charge grâce à une directive client.

---
import Counter from "../components/Counter.jsx";
import Comments from "../components/Comments.jsx";
---

<Counter client:load />
<Comments client:visible />

Les directives sont les suivantes :

• client:load hydrate immédiatement — pour l’interactivité critique située au-dessus de la ligne de flottaison (above-the-fold).
• client:idle hydrate dès que le navigateur est disponible.
• client:visible hydrate lorsque le composant apparaît à l’écran lors du défilement.
• client:only ignore le rendu serveur et s’exécute uniquement dans le navigateur.
• client:media hydrate lorsqu’une media query est satisfaite.

Choisir la directive la moins gourmande possible tout en restant fonctionnelle permet de garder la page rapide. La plupart des pages de contenu n’en ont besoin d’aucune.

Utilisez votre propre bibliothèque d’UI

Astro peut rendre des composants React, Vue, Svelte, Solid et Preact — au sein d’un même projet.

---
import ReactChart from "../components/Chart.jsx";
import VueForm from "../components/Form.vue";
---

<ReactChart client:load data={data} />
<VueForm client:visible />

Chaque framework est une intégration optionnelle. Vous pouvez utiliser React pour une île et Svelte pour une autre, ou vous passer totalement de framework. Cette flexibilité signifie que vous n’êtes jamais bloqué, et que vous pouvez adopter une bibliothèque uniquement là où elle apporte une réelle valeur ajoutée.

SSR et adaptateurs

Astro est statique par défaut, mais il peut effectuer le rendu à la demande. Ajoutez un adaptateur pour votre plateforme et configurez vos routes pour le rendu côté serveur.

// astro.config.mjs
import { defineConfig } from "astro/config";
import node from "@astrojs/node";

export default defineConfig({
  output: "server",
  adapter: node({ mode: "standalone" }),
});

Les points de terminaison API se trouvent dans src/pages/api et exportent des méthodes HTTP, tandis que les server islands vous permettent de rendre des fragments dynamiques à l’intérieur de pages autrement statiques. Cela rend Astro idéal pour les sites hybrides : un blog statique avec un tableau de bord dynamique, ou un site marketing avec des sections personnalisées.

Bonnes pratiques

• Privilégiez les composants .astro par défaut ; n’ajoutez des composants de framework que pour l’interactivité.
• Utilisez la directive client la moins gourmande possible qui réponde à vos besoins.
• Conservez le contenu dans des collections avec un schéma plutôt que dans du markdown libre.
• Encapsulez vos styles avec des blocs <style> de composants ou l’outil CSS de votre choix.
• Générez les pages statiques au moment du build et réservez le SSR pour les routes dynamiques.
• Utilisez des layouts pour les structures communes et les métadonnées.
• Optimisez les images avec les composants d’image intégrés.

Erreurs courantes

• Ajouter du client:load partout et perdre ainsi l’avantage du “zero-JavaScript”.
• Utiliser un framework UI alors qu’un composant .astro suffirait.
• Oublier de définir un schéma et perdre la sécurité du typage dans les collections.
• Supposer qu’Astro ne permet pas de créer des applications dynamiques et négliger le SSR.
• Mélanger trop de frameworks UI et alourdir le projet sans raison.
• Utiliser le fetching côté client pour du contenu qui pourrait être rendu au moment du build.

Et après ?

Astro est le choix pragmatique pour les sites riches en contenu qui nécessitent tout de même quelques zones d’interactivité. Consolidez vos bases en HTML et CSS, puis comparez ce modèle avec Next.js, Nuxt et SvelteKit. Enfin, créez un petit blog avec une collection de contenu et une île interactive pour constater par vous-même les compromis.