L'architecture Islands d'Astro : la fin du JavaScript inutile
Comment l'architecture Islands d'Astro révolutionne le développement web en n'envoyant du JavaScript que là où c'est strictement nécessaire.
Pourquoi les SPA traditionnelles posent-elles un problème de performance ?
Les Single Page Applications (SPA) ont dominé le développement web pendant une décennie. React, Vue, Angular — ces frameworks envoient un bundle JavaScript complet au navigateur, même pour afficher du contenu statique. Le résultat est mesurable et préoccupant :
- Bundle moyen d’un site React : 245 Ko de JS compressé (HTTP Archive, 2025)
- Time to Interactive moyen : 4.2 secondes sur mobile 4G
- Score Lighthouse Performance moyen : 62/100 pour les sites React
- 53% des visiteurs mobiles quittent un site qui met plus de 3 secondes à charger
Le paradoxe est flagrant : pour afficher un article de blog — du texte et des images — un SPA charge un framework JavaScript complet, un routeur, un state manager, et hydrate l’intégralité du DOM. C’est comme livrer un meuble IKEA monté dans un camion 38 tonnes.
Comment fonctionne l’architecture Islands ?
L’architecture Islands, popularisée par Astro (et conceptualisée par Katie Sylor-Miller chez Etsy en 2019), repose sur un concept simple mais puissant : une page web est principalement constituée de contenu statique (95% en moyenne) avec quelques zones interactives isolées.
Plutôt que d’hydrater toute la page avec un framework JavaScript, Astro ne charge du JS que pour ces “îles” d’interactivité. Le reste est du HTML pur, généré au build. Chaque île est :
- Indépendante : elle se charge sans affecter le reste de la page
- Lazy-loadable : elle peut être chargée à la demande (scroll, idle, media query)
- Framework-agnostique : React, Vue, Svelte ou Solid dans le même projet
Quelles sont les directives client: disponibles ?
Astro propose 5 directives pour contrôler finement quand et comment un composant est hydraté :
| Directive | Quand | Cas d’usage |
|---|---|---|
client:load | Immédiatement | Navigation, header interactif |
client:visible | Entrée dans le viewport | Compteurs, formulaires bas de page |
client:idle | Navigateur inactif | Analytics, widgets non-critiques |
client:media | Media query match | Composant mobile-only |
client:only | Jamais côté serveur | Composant qui nécessite le DOM |
Exemple concret : sur ce site, la page /demo utilise client:load pour le formulaire newsletter (interactif immédiatement) et client:visible pour le compteur (chargé au scroll). Le HTML autour ne charge aucun JavaScript.
Quels sont les résultats mesurables de l’architecture Islands ?
Les bénéfices de cette approche sont concrets et vérifiables :
| Métrique | SPA React | Astro Islands | Amélioration |
|---|---|---|---|
| JS envoyé | 245 Ko | 12 Ko | -95% |
| LCP | 2.8s | 0.4s | -86% |
| INP | 180ms | 0ms* | -100% |
| Lighthouse | 62/100 | 100/100 | +61% |
| Build time | 45s | 3s | -93% |
*0ms sur les pages sans Islands. Les pages avec Islands affichent un INP proportionnel à la complexité du composant.
Le Time to Interactive est drastiquement réduit, ce qui se traduit par un meilleur taux de conversion (+12% en moyenne selon une étude Vercel) et un meilleur référencement. C’est une approche pragmatique qui réconcilie performance et interactivité, sans compromis.
Vous pouvez vérifier par vous-même : faites View Source sur n’importe quelle page de ce site — vous verrez du HTML propre, sans bundle JS (sauf sur la page /demo qui contient les Islands React).