La plupart des frameworks partent du JavaScript et demandent d’en retirer. Astro part du HTML statique et demande d’en ajouter. Cette inversion fondamentale est ce qui le rend particulièrement adapté aux sites orientés contenu, où la performance n’est pas une fonctionnalité parmi d’autres mais la fonctionnalité centrale.
Islands Architecture : interactif là où ça compte
Astro a popularisé le concept d’islands, où une page est principalement du HTML statique avec des poches isolées d’interactivité. Chaque island s’hydrate indépendamment, ce qui signifie qu’un carrousel lourd en bas de page ne bloque pas l’interactivité du header.
---
import Header from '../components/Header.astro';
import ProductGallery from '../components/ProductGallery.tsx';
import Reviews from '../components/Reviews.tsx';
---
<Header />
<main>
<ProductGallery client:visible />
<Reviews client:idle />
</main>La directive client:visible retarde l’hydratation jusqu’à ce que le composant soit visible dans le viewport. client:idle attend que le navigateur soit inactif. Ce ne sont pas des optimisations ajoutées après coup. Ce sont des primitives de premier ordre intégrées au modèle de rendu du framework.
Server Islands : du dynamique sans le coût
Les server islands poussent le concept plus loin en différant le rendu côté serveur sans bloquer le reste de la page. Un avatar personnalisé, un widget de prix dépendant de la géolocalisation, ou tout composant nécessitant des données fraîches à chaque requête peut se rendre indépendamment.
---
import UserGreeting from '../components/UserGreeting.astro';
import Stats from '../components/Stats.astro';
---
<UserGreeting server:defer>
<p slot="fallback">Chargement...</p>
</UserGreeting>
<Stats server:defer />La page est envoyée instantanément avec un contenu de substitution. Chaque server island arrive en streaming à mesure que ses données deviennent disponibles. Pas de JavaScript côté client, pas de décalage de mise en page, pas de spinners de chargement envahissant tout l’écran.
Content Collections : du contenu typé à grande échelle
Astro traite le contenu comme une couche de données de premier ordre. Les content collections valident vos fichiers Markdown, MDX ou JSON contre un schéma au moment du build, détectant les erreurs de frontmatter avant qu’elles n’atteignent la production.
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
type: 'content',
schema: z.object({
title: z.string(),
date: z.coerce.date(),
tags: z.array(z.string()).max(4),
draft: z.boolean().default(false),
}),
});
export const collections = { blog };L’interrogation des collections retourne des données entièrement typées. Pas de validation à l’exécution, pas de types any qui fuient dans vos templates. Si un article de blog manque un champ requis, le build échoue avec une erreur claire pointant vers le fichier exact.
---
import { getCollection } from 'astro:content';
const posts = await getCollection('blog', ({ data }) => !data.draft);
---
{posts.map(post => (
<article>
<h2>{post.data.title}</h2>
<time>{post.data.date.toLocaleDateString()}</time>
</article>
))}Agnostique en framework : utilisez ce que vous connaissez
Astro ne force pas l’adoption d’une seule librairie UI. React, Vue, Svelte, Solid, Preact et Lit fonctionnent tous comme des citoyens de premier ordre au sein du même projet. Un site marketing peut utiliser des composants Astro pour les sections statiques et intégrer un formulaire React ou une animation Svelte là où l’interactivité est nécessaire.
---
import ReactForm from '../components/ContactForm.tsx';
import SvelteAnimation from '../components/Hero.svelte';
---
<SvelteAnimation client:load />
<section>
<h2>Contactez-nous</h2>
<ReactForm client:visible />
</section>Ce n’est pas un gadget. Les équipes avec des expertises variées peuvent contribuer sans réécrire les composants existants. Les chemins de migration deviennent incrémentaux plutôt que tout-ou-rien.
View Transitions : l’expérience SPA, la réalité MPA
Le ClientRouter d’Astro apporte des transitions de page fluides aux applications multi-pages sans la complexité d’un routeur côté client. Les pages sont toujours rendues sur le serveur, les URLs fonctionnent toujours sans JavaScript, mais la navigation semble instantanée.
---
import { ClientRouter } from 'astro:transitions';
---
<html>
<head>
<ClientRouter />
</head>
<body>
<slot />
</body>
</html>L’API native View Transitions du navigateur gère l’animation. Astro fournit le fallback pour les navigateurs qui ne la supportent pas encore. Le résultat est un gain de performance perçu sans aucun impact sur la taille du bundle.
Quand Astro est le bon choix
Astro excelle pour les blogs, les sites de documentation, les pages marketing, les portfolios et les vitrines e-commerce où la majeure partie de la page est du contenu. Il ne cherche pas à remplacer Next.js pour les applications hautement interactives avec un état client complexe. Cette distinction est une force, pas une limitation. En réduisant son périmètre, Astro offre des performances que les frameworks généralistes ne peuvent égaler sans un effort d’optimisation conséquent.
Le zéro JavaScript par défaut n’est pas une posture anti-JavaScript. C’est une question d’intentionnalité sur chaque kilooctet envoyé au navigateur. Dans un web où le poids médian des pages ne cesse d’augmenter, cette intentionnalité est exactement ce dont les sites orientés contenu ont besoin.