L'architecture en îlots d'Astro, expliquée en langage clair

La plupart des sites web modernes envoient une application JavaScript complète à votre navigateur, qui y construit la page. C’est puissant pour de vraies applications, mais excessif pour un site qui affiche surtout du contenu. L’architecture en îlots d’Astro est la réponse à cela : elle garde la page légère en limitant l’interaction à des îlots distincts. Cela paraît technique, mais l’idée est étonnamment simple.

L’idée en une phrase

Une page Astro est du HTML statique. Les parties qui ont besoin d’interaction, comme un carrousel, une barre de recherche ou un calculateur de prix, deviennent des îlots isolés avec leur propre JavaScript. Tout le reste demeure du simple HTML, sans JavaScript.

Pourquoi l’approche classique est-elle lente ?

Avec une single-page app classique, le navigateur doit d’abord télécharger et exécuter l’application entière avant que quoi que ce soit ne soit visible et utilisable. Cela coûte du temps et de la puissance de calcul, surtout sur un téléphone moyen. Vous payez le coût complet du JavaScript, même pour des pages qui n’ont presque aucune interaction.

Avec les îlots, le navigateur voit la page immédiatement sous forme de HTML. Les îlots se chargent ensuite, indépendamment les uns des autres. Un widget lourd en bas ne ralentit pas le bouton en haut, car chaque îlot fonctionne par lui-même.

Qu’est-ce qu’un island, précisément ?

Un island est un composant interactif délimité sur une page par ailleurs statique. Pensez à une barre de filtres dans un aperçu de produits, à un formulaire ou à un lecteur vidéo. Astro rend d’abord le HTML de ce composant (pour qu’il soit immédiatement visible), puis l’« hydrate » : le JavaScript associé se charge et le rend interactif. En dehors de ces îlots, il n’y a tout simplement aucun JavaScript de composant à charger.

Quand un island se charge-t-il ?

C’est la clé de la rapidité. Vous décidez par island quand il s’hydrate au moyen d’une directive. Ainsi, vous ne chargez rien trop tôt.

Directive	Quand cela se charge	Bon pour
client:load	Immédiatement, au chargement de la page	Ce qui doit être interactif tout de suite
client:idle	Dès que le navigateur n’a plus rien à faire	Widgets moins urgents
client:visible	Seulement lorsque le composant apparaît à l’écran	Tout ce qui est sous la ligne de flottaison
client:media	À une largeur d’écran donnée	Interaction spécifique au mobile
client:only	Uniquement dans le navigateur, sans HTML serveur	Composants qui ne peuvent pas être rendus à l’avance

Un widget de chat qui ne se charge que lorsqu’on fait défiler vers le bas ne coûte ainsi rien à l’ouverture de la page. C’est de l’interaction sans que le visiteur la paie dès la première impression.

Server islands

Outre les îlots interactifs dans le navigateur, il existe des server islands. Ceux-ci rendent une partie dynamique ou personnelle (par exemple un nom d’utilisateur connecté, un stock en direct ou une recommandation personnalisée) séparément sur le serveur, tandis que le reste de la page demeure statique et cachable. Vous combinez ainsi la rapidité du HTML statique avec du dynamisme exactement là où il le faut, sans rendre toute la page dynamique.

Apportez votre propre framework

Astro n’impose aucun choix de framework. Vous écrivez des composants en .astro, et vous pouvez utiliser React, Svelte, Vue ou Solid à leurs côtés pour les îlots, même mélangés dans un même projet. Astro retire le runtime là où vous n’en avez pas besoin, de sorte que les visiteurs ne reçoivent que du HTML et du CSS, sauf si l’interaction l’exige. Vous réutilisez donc des composants existants sans le prix en performance d’une application entièrement côté client.

Ce que cela signifie pour votre site

Le gain pratique est double. Votre site se charge plus vite, car il y a moins de JavaScript à traiter, ce qui aide directement les Core Web Vitals. Et votre site reste gérable, car l’interaction est proprement délimitée au lieu d’être entremêlée dans une grande application. Pour les sites axés sur le contenu, c’est presque toujours le meilleur compromis. Vous en lirez davantage sur les conséquences pour le référencement dans Core Web Vitals et SEO.

Idées reçues fréquentes

• « Les îlots, ça veut dire pas de JavaScript. » Faux : vous pouvez ajouter autant d’interaction que vous voulez, vous ne la payez que là où vous la placez.
• « C’est la même chose que le lazy loading. » Le lazy loading reporte le chargement d’une ressource ; les îlots, en plus, isolent l’interaction par composant, avec du HTML serveur en dessous.
• « Il faut choisir entre statique et dynamique. » Avec les server islands, ce n’est pas nécessaire : contenu principal statique et parties dynamiques cohabitent sur une même page.

Conclusion

L’architecture en îlots n’est pas une astuce, mais une autre norme : ne rien envoyer, sauf si c’est nécessaire. C’est précisément pourquoi un site Astro paraît léger, même avec beaucoup de contenu ou plusieurs éléments interactifs. Si vous voulez le voir à l’œuvre, consultez le calendrier des versions, qui est lui-même construit avec cette approche, ou lisez ce qu’est exactement Astro.