Le problème majeur des frameworks modernes est l’hydratation universelle. Envoyer l’intégralité d’un framework pour rendre un bouton interactif est un non-sens architectural. Astro résout ce problème par l’isolation.

Angle choisi : Pragmatique. Supprimer le JavaScript inutile est la seule optimisation qui compte.

L’Architecture en Îlots (Islands)

Le paradigme d’Astro est simple : le HTML est le citoyen de première classe. Le JavaScript est un invité, admis uniquement là où il est strictement nécessaire. Chaque composant interactif devient un “îlot” isolé dans une mer de HTML statique.

  • Avantage : Le chargement d’un îlot n’interfère pas avec le reste de la page.
  • Contrôle : Vous décidez exactement quand le script se charge (au scroll, à l’idle, ou jamais).

Static First, Dynamic on Demand

Le pré-rendu n’est pas une nouveauté, mais sa flexibilité dans Astro l’est. Pouvoir mixer de la génération statique (SSG) pour le contenu et du rendu serveur (SSR) pour les données transactionnelles au sein d’un même projet permet d’optimiser le TTFB (Time to First Byte) sans sacrifier la fonctionnalité.

Comparaison des Bundles

Un projet Astro typique affiche une réduction de 90% du JavaScript envoyé au client par rapport à une application Single Page (SPA) traditionnelle.

# Analyse de bundle (moyenne)
SPA Classique : 150kb (Framework) + 200kb (App) = 350kb
Astro : 0kb (Framework) + 5kb (Composant) = 5kb

Conclusion

Astro ne se contente pas d’être “rapide”. Il impose une discipline de développement qui empêche la régression de performance. C’est l’outil idéal pour les architectures où le contenu prime sur la décoration.