Astro : le framework pour des sites web ultra-rapides

Parmi les frameworks web modernes, Astro occupe une place à part. Là où la plupart des outils partent du principe qu’une page a besoin de JavaScript pour vivre, Astro fait l’inverse : par défaut, il n’envoie aucun JavaScript au navigateur. Le résultat, ce sont des sites qui se chargent quasi instantanément, sans sacrifier le confort de développement moderne. Ce guide explique le concept, les cas d’usage, un exemple concret et le déploiement.

Petite transparence avant de commencer : Coder Studio, le site que vous lisez, tourne lui-même sous Astro. Les exemples et retours qui suivent viennent donc en partie de notre propre expérience de production.

Le concept : zéro JavaScript par défaut

L’idée fondatrice d’Astro tient en une phrase : la plupart des pages web sont surtout du contenu, pas des applications interactives. Un article de blog, une documentation, une page produit n’ont pas besoin d’un moteur JavaScript complet chargé dans le navigateur pour afficher du texte et des images.

Astro génère donc du HTML statique au moment du build. Le visiteur reçoit une page HTML pure, prête à s’afficher, sans attendre qu’un bundle JavaScript se télécharge, se parse et s’exécute. C’est cette approche qui rend les sites Astro particulièrement rapides et bien notés sur les Core Web Vitals de Google.

L’architecture en îlots (islands)

Mais que faire quand une partie de la page a vraiment besoin d’interactivité — un carrousel, un formulaire dynamique, un compteur ? C’est là qu’intervient l’architecture en îlots (islands architecture).

Le principe : votre page reste du HTML statique, et vous « saupoudrez » de l’interactivité uniquement là où c’est nécessaire, sous forme d’îlots isolés. Chaque îlot charge son JavaScript indépendamment, et seulement lui. Le reste de la page ne paie pas ce coût.

---
import Compteur from '../components/Compteur.jsx';
---
<h1>Un article statique et rapide</h1>
<p>Ce texte est du HTML pur, zéro JavaScript.</p>

<!-- Seul cet îlot charge du JS, à la demande -->
<Compteur client:visible />

La directive client:visible indique à Astro de n’hydrater le composant (charger son JavaScript) que lorsqu’il devient visible à l’écran. D’autres directives existent : client:load (immédiat), client:idle (quand le navigateur est inactif). Vous contrôlez finement le coût de chaque interaction.

Autre atout : Astro est agnostique. Vous pouvez écrire vos îlots en React, Vue, Svelte ou Preact, au sein d’un même projet. Si vous hésitez encore entre bibliothèques, notre comparatif React vs Vue vous aidera à trancher selon vos besoins.

Les content collections

Pour un média comme le nôtre, la fonctionnalité la plus précieuse est sans doute les content collections. Elles permettent d’organiser du contenu Markdown (ou MDX) de façon structurée et typée.

Concrètement, vous définissez un schéma qui décrit les champs attendus dans le frontmatter de chaque fichier. Astro valide alors chaque article au build : un champ manquant ou mal typé casse la compilation avant la mise en ligne, plutôt que de produire une page cassée en production.

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

const articles = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
    description: z.string(),
  }),
});

export const collections = { articles };

Cette sécurité au moment du build est un vrai filet de sécurité éditorial quand on gère des dizaines d’articles.

Pour quels projets choisir Astro ?

Astro n’est pas la réponse à tout, et son équipe le reconnaît volontiers. Il brille sur les projets orientés contenu :

Blogs et magazines (comme Coder Studio).
Sites de documentation technique.
Sites vitrines et pages marketing.
E-commerce éditorial où le contenu prime.

En revanche, pour une application très interactive de bout en bout — un tableau de bord temps réel, un éditeur collaboratif, une messagerie — un framework applicatif complet comme React avec Next.js ou Vue sera souvent plus adapté. Astro peut le faire, mais ce n’est pas son terrain de prédilection.

Un exemple de structure de projet

Un projet Astro reste simple à appréhender. Voici l’ossature typique :

mon-site/
├── src/
│   ├── pages/        # chaque fichier = une route
│   │   └── index.astro
│   ├── components/   # composants réutilisables
│   ├── layouts/      # gabarits de page
│   └── content/      # content collections (Markdown)
├── public/           # fichiers statiques
└── astro.config.mjs

Le dossier src/pages/ fonctionne par routing basé sur les fichiers : src/pages/blog/article.astro devient automatiquement l’URL /blog/article/. Pas de configuration de routeur à écrire.

Déploiement

Comme Astro produit par défaut des fichiers statiques (HTML, CSS, JS minimal), le déploiement est particulièrement simple et économique. La commande de build est classique :

npm run build

Elle génère un dossier dist/ que vous pouvez héberger sur n’importe quelle plateforme statique : Cloudflare Pages, Netlify, Vercel, GitHub Pages, ou un simple serveur web. Coder Studio est déployé de cette manière, et l’empreinte serveur reste minime.

Astro propose aussi des adaptateurs pour un rendu à la demande (SSR) quand vous avez besoin de pages dynamiques côté serveur : Cloudflare, Node, Vercel, etc. Vous choisissez donc entre pur statique, hybride ou SSR selon les pages. Si vous visez l’edge, l’écosystème Cloudflare Workers s’intègre particulièrement bien avec Astro.

En résumé

Astro renverse une habitude bien ancrée : au lieu de charger du JavaScript partout puis d’essayer d’en retirer, il part de zéro JavaScript et n’en ajoute que là où c’est indispensable. Pour les sites de contenu, ce choix se traduit par des performances excellentes, un bon référencement et une expérience de développement agréable, avec la liberté d’utiliser vos composants préférés en îlots.

Si votre projet est avant tout du contenu à afficher vite et bien, Astro mérite très sérieusement votre attention. C’est le pari que nous avons fait pour ce média, et nous ne le regrettons pas.