Astro Islands : performance maximale avec hydratation partielle

Le web moderne souffre d’un paradoxe : les frameworks JavaScript ont rendu l’interactivité plus simple à construire, mais au prix d’un JavaScript massif chargé même pour des pages quasi-statiques. Astro résout ce problème avec le concept d’Islands Architecture.

Le problème du JavaScript par défaut

Dans une SPA React ou Vue classique, l’intégralité de l’arbre de composants est hydratée au chargement — même les éléments qui ne sont jamais interactifs (headers, texte, images). Le résultat : des bundles JavaScript de plusieurs centaines de ko pour des pages dont 80% du contenu est statique.

SPA classique :
┌─────────────────────────────────────┐
│  Header.jsx     → JS chargé ✓       │  Jamais interactif
│  Hero.jsx       → JS chargé ✓       │  Jamais interactif
│  BlogGrid.jsx   → JS chargé ✓       │  Liste statique
│  SearchBar.jsx  → JS chargé ✓       │  Interactif ← seul utile
│  Footer.jsx     → JS chargé ✓       │  Jamais interactif
└─────────────────────────────────────┘
  Total JS : ~400kb pour 1 composant utile

L’architecture Islands : JS seulement où c’est nécessaire

Astro inverse ce paradigme. Par défaut, zéro JavaScript est envoyé au navigateur. Chaque composant est rendu en HTML pur côté serveur. Seuls les composants explicitement marqués comme interactifs — les “îles” — reçoivent leur JavaScript.

Astro avec Islands :
┌─────────────────────────────────────┐
│  Header.astro   → HTML pur          │  0kb JS
│  Hero.astro     → HTML pur          │  0kb JS
│  BlogGrid.astro → HTML pur          │  0kb JS
│  <SearchBar client:load />          │  ~12kb JS ← île
│  Footer.astro   → HTML pur          │  0kb JS
└─────────────────────────────────────┘
  Total JS : ~12kb — gain de 97%

Les directives client: en détail

Astro expose cinq directives pour contrôler quand une île est hydratée :

client:load

Hydratation immédiate au chargement de la page. À réserver aux composants critiques visibles au-dessus de la ligne de flottaison.

<SearchBar client:load />

client:idle

Hydratation quand le navigateur est inactif (après le chargement critique). Parfait pour les composants secondaires.

<RecommendedPosts client:idle />

client:visible

Hydratation au moment où le composant entre dans le viewport. Idéal pour les composants bas de page.

<CommentSection client:visible />

client:media

Hydratation conditionnelle à une media query. Évite de charger du JS mobile sur desktop et vice versa.

<MobileNav client:media="(max-width: 768px)" />

client:only

Rendu uniquement côté client, sans SSR. Pour les composants qui dépendent du DOM ou de window.

<ThreeJsScene client:only="react" />

Ce boilerplate en pratique

Dans ce projet, vous pouvez observer les directives client en action dans MainLayout.astro :

<!-- Hydratation immédiate — critique pour l'UX -->
<SearchDrawer client:load />
<BlobHand client:load />

<!-- Conditionnel — seulement si showChatBar est vrai -->
{showChatBar && <ChatBar client:load />}

La BlobHand est hydratée immédiatement car elle est visible dès le premier render et l’utilisateur peut interagir avec elle instantanément.

L’impact sur le score Lighthouse

Un projet Astro bien configuré atteint naturellement des scores proches de 100/100 sur Lighthouse. Le secret : HTML pré-rendu + CSS critique inline + JavaScript minimal et différé. Ce boilerplate cible ces métriques par design — chaque île est un choix délibéré, pas une habitude.