Jason Miller (Preact) a popularisé le terme “Islands Architecture” en 2019. L’idée : au lieu d’hydrater toute la page en JavaScript (comme une SPA), on hydrate uniquement des “îlots” d’interactivité. Le reste de la page reste en HTML statique. Astro a fait de ce pattern son fondement, et les résultats parlent d’eux-mêmes : des sites avec des scores Lighthouse parfaits tout en ayant des composants interactifs.
JS économisé
-82%
de JavaScript transféré vs hydration classique (590KB → 105KB)
LCP amélioré
-65%
du Largest Contentful Paint (4.6s → 1.6s sur YouTube mobile)
Le Contexte
L'architecture qui change tout
🧠
Analogie
L’Islands Architecture, c’est comme construire une maison : les murs porteurs (HTML statique) sont montés en premier et ne bougent jamais. Les portes et fenêtres (composants interactifs) sont installées par la suite : elles bougent, s’ouvrent, se ferment, mais n’affectent pas la structure. Une SPA, c’est l’inverse : tout est mouvant dès le départ, même là où ça ne sert à rien.
📖
Quand l'utiliser
L’Islands Architecture est idéale pour les sites de contenu (blogs, docs, marketing) où 80% de la page est statique. Pour les applications 100% interactives (dashboards, SaaS), préférez un framework classique (React, Vue) : l’îlot ajoute de la complexité sans gain.
Concept visuel
┌─────────────────────────────────────────┐
│ Header : HTML statique │ ← Zéro JS
├─────────────────────────────────────────┤
│ Hero : HTML statique │ ← Zéro JS
├─────────────────────────────────────────┤
│ ┌─────────────────────────────────┐ │
│ │ React Counter (client:load) │ │ ← Îlot hydraté
│ │ const [count, setCount] = ... │ │ ← React chargé
│ └─────────────────────────────────┘ │
├─────────────────────────────────────────┤
│ ┌─────────────────────────────────┐ │
│ │ Gallery (client:visible) │ │ ← Îlot hydraté
│ │ images, lightbox... │ │ au scroll
│ └─────────────────────────────────┘ │
├─────────────────────────────────────────┤
│ Footer : HTML statique │ ← Zéro JS
└─────────────────────────────────────────┘Directives d’hydratation
client:load
Hydrate immédiatement au chargement de la page. Pour les composants visibles tout de suite et critiques pour l’interaction : navigation, recherche, panier.
client:visible
Hydrate au scroll quand le composant entre dans le viewport. Pour les sections hors écran au chargement : footer, galerie d’images, modales. Économie de JS maximale.
client:media
Hydrate uniquement à partir d’un breakpoint CSS : client:media="(min-width: 768px)". Pour les composants desktop uniquement : sidebar, tableaux complexes.
client:only
Hydrate côté client uniquement, sans SSR. Pour les composants qui dépendent exclusivement des API navigateur : WebGL, canvas, IndexedDB, WebRTC.
Exemple concret
---
import Header from '../components/Header.astro';
import Hero from '../components/Hero.astro';
import Search from '../components/Search.jsx';
import Gallery from '../components/Gallery.vue';
import Footer from '../components/Footer.astro';
---
<!-- HTML statique : zéro JS -->
<Header />
<Hero />
<!-- Hydraté immédiatement (visible tout de suite) -->
<Search client:load />
<!-- Hydraté au scroll (hors écran au départ) -->
<Gallery client:visible />
<!-- HTML statique : zéro JS -->
<Footer />Performance : avant vs après
SPA classique
❌ JS : 200-500 KB bundle
❌ Hydrate toute la page
❌ LCP : 2-4s
❌ TTI : 3-5s
SSR (Next/Nuxt)
⚠️ JS : 100-200 KB bundle
⚠️ Hydrate toute la page (hydration)
⚠️ LCP : 1.5-3s
✅ TTI : 2-4s (mais block)
Islands (Astro)
✅ JS : 0-50 KB (îlots uniquement)
✅ Hydrate seulement les îlots
✅ LCP : 0.8-1.5s
✅ TTI : 1-2s
SPA Classique
- ❌ Toute la page hydrate en JS
- ❌ Bundle monolithique (200-500 KB)
- ❌ LCP lent (2-4 secondes)
- ❌ Zéro HTML avant exécution JS
Islands Architecture
- ✅ Seulement les îlots hydratent
- ✅ Bundles atomiques (0-50 KB)
- ✅ LCP rapide (0.8-1.5 secondes)
- ✅ HTML complet dès le premier chargement
Quand créer un îlot ?
Analyse Technique : Initié
Décision : Créer une Island ?
Interactif ?
State client nécessaire ?
API browser requise ?
→ Island nécessaire
Tout composant n’a pas besoin d’être un îlot. Posez-vous ces questions :
- L’utilisateur interagit-il directement ? → Oui, le composant a besoin de clics, saisies, glisser-déposer → Îlot probable
- Le composant change-t-il après le render ? → Si c’est juste un affichage CSS (accordéon, tooltip en CSS), pas besoin d’îlot
- Le composant dépend-il de données externes ? → Si les données sont chargées côté client → Îlot nécessaire
- Peut-on le faire en HTML/CSS pur ? → 80% des composants “interactifs” peuvent être remplacés par du CSS (hover, focus, transitions)
Règle : commencez sans îlot, ajoutez-en uniquement quand l’interactivité le justifie.
Limites et pièges à éviter
Partage d'état entre îlots
Pas de props directes entre frameworks différents, seul le store (Zustand, Nano Stores, BroadcastChannel) agira comme médiateur.
Pas pour les dashboards
Les applications 100% interactives (SaaS, dashboards) perdent en simplicité. Chaque composant = un îlot = un bundle séparé.
Hydratation visible
Si les îlots sont nombreux, le lecteur voit des zones qui “apparaissent” au scroll. Impact UX sur les connexions lentes.
Debug plus complexe
Les erreurs JS sont dispersées entre îlots. Pas de stack trace unifié comme dans une SPA.
?
Composants Astro
Comment créer des composants Astro réutilisables avec les directives client et les slots ?
Bientôt disponible
En cours de rédaction
Cet article est en cours de rédaction. Inscrivez-vous à la newsletter pour être averti de sa publication.
Newsletter
Un récap par mois de ce qui a vraiment compté. Pas de spam, promis.
Alternatives à connaître
| Pattern | Quand l'utiliser | Exemple |
|---|---|---|
| Islands (Astro) | Sites de contenu, blogs, docs | Blog technique, landing page |
| Resumable (Qwik) | Apps interactives sans hydration | SaaS, dashboards |
| RSC (Next.js) | Apps React avec server components | E-commerce, apps complexes |
| MPA classique (Hugo, Jekyll) | Sites 100% statiques | Documentation, portfolio |
| SPA (React, Vue) | Apps 100% interactives | Gmail, Figma, Notion |
Des zones d'ombre ?
Puis-je utiliser plusieurs frameworks dans une même page ?
Oui, c'est l'un des avantages d'Astro. Vous pouvez avoir un composant React, un composant Vue et un composant Svelte sur la même page, chacun hydraté indépendamment. Chaque îlot est isolé : pas de conflit entre frameworks.
L'Islands Architecture est-elle réservée à Astro ?
Non. Le pattern Islands existe aussi dans Qwik (Resumable), Marko, et peut être implémenté manuellement avec n'importe quel framework. Mais Astro en fait son fondement avec l'API la plus simple.
Quel est l'impact SEO de l'Islands Architecture ?
Aucun impact négatif. Le HTML est livré complet dès le premier chargement (SSR). Google voit tout le contenu. Les îlots n'ajoutent que de l'interactivité : ils ne modifient pas le HTML de base.
Comment partager l'état entre deux îlots ?
Par le DOM ou par un store externe (Zustand, Nano Stores). Les îlots peuvent communiquer via des événements personnalisés, un attribut data- commun, ou un store qui agit comme médiateur. Évitez les props directes entre frameworks différents.
Checklist Islands
Adoption Islands Architecture
0/8Vos progrès sont sauvegardés localement sur votre appareil. Aucune donnée n'est collectée. La durée de conservation dépend de la durée de rétention des données de votre navigateur.
"
L’architecture Islands incarne la philosophie que j’applique chaque jour : n’envoyez que ce qui est nécessaire, au moment où ça l’est.
Gaëtan Solis
Fondateur, Bao-Link
Orfèvre Digital
Prêt à lancer votre projet ?
Je donne vie à vos idées en créant des sites web et applications intuitifs, esthétiques et fonctionnels.
Disponible
Articles Connexes
0+2
Brouillon
Connexe
Core Web Vitals : LCP, INP, CLS : les Métriques qui Comptent
Maîtrisez les Core Web Vitals : LCP, INP et CLS. Seuils, optimisation, outils de mesure et stratégie d'amélioration continue pour satisfaire Google et vos utilisateurs.
Brouillon
Connexe
Composants Astro
Maîtrisez les composants Astro (.astro) avec leurs slots, props et patterns. Créez des composants performants avec zero JavaScript par défaut.
Inspiration
Découvrez d'autres projets
Développement 21 juillet 2026
Bao-Link Documentation : De WordPress à un Écosystème Centré Utilisateur
Le projet Bao-Link raconte l'évolution du site et de ses outils: la création d'un premier site WordPress vitrine, puis le passage à Astro avec un site 100% sur mesure, sans template, centré sur le SEO et l'expérience utilisateur ainsi que les projets liés : diag-application et personas.
Astro WordPress # Migration
Voir le projet 
Développement 16 juillet 2026
ACM : Refonte E-commerce avec Astro, Express & WordPress
Étude de cas complète : migration d'un site e-commerce WordPress/WooCommerce vers une architecture Astro SSR + proxy Express, avec déploiement et optimisation SEO.
Astro Express WordPress
Voir le projet 
Développement 16 juillet 2026
Soair : La Transition Numérique Complète
Étude de cas complète : création d'un site WordPress professionnel puis migration vers Hugo pour des performances optimales et un SEO décuplé.
# Soair WordPress Hugo
Voir le projet 