Architecture en îlots : hydratation sélective

L'architecture en îlots, expression forgée par Jason Miller en 2020, considère une page web comme un HTML principalement statique contenant des « îlots » isolés d'interactivité. L'océan statique de HTML est envoyé tel quel au navigateur. Seuls les îlots interactifs téléchargent et exécutent du JavaScript, de sorte que le volume de JavaScript est proportionnel à l'interactivité réelle.

Chaque îlot est un composant hydraté indépendamment. Le serveur génère le HTML initial de l'îlot en même temps que le reste de la page. Lorsque le JavaScript de l'îlot est chargé, seul le sous-arbre de ce composant est hydraté. Le HTML qui entoure les îlots n'est jamais modifié par JavaScript : il est véritablement statique.

Sur une page d'article de blog utilisant l'architecture en îlots, le volume de JavaScript peut être de 5 ko pour un seul îlot de bouton J'aime. La même page construite comme une SPA React peut envoyer plus de 200 ko de JavaScript pour hydrater la page entière. L'approche par îlots rend le volume de JavaScript proportionnel à l'interactivité, et non à la taille de la page.

Astro, le principal cadre de développement de l'architecture en îlots, prend en charge les îlots construits avec différents cadres de développement sur une même page. Vous pouvez avoir un îlot React à côté d'un îlot Vue, lui-même à côté d'un îlot JavaScript natif. Chaque îlot est empaqueté séparément, de sorte que les utilisateurs ne téléchargent que le code du cadre utilisé par les îlots visibles.

La directive client:load hydrate l'îlot immédiatement au chargement de la page. Utilisez-la pour les îlots immédiatement visibles et interactifs, comme un menu de navigation ou une section d'accroche contenant un champ de recherche. Il s'agit de la stratégie d'hydratation la plus prioritaire.

La directive client:idle attend que le fil principal du navigateur soit inactif, une fois le contenu critique chargé, avant d'hydrater l'îlot. Elle convient parfaitement aux composants situés sous la ligne de flottaison ou aux interactions secondaires qui ne sont pas nécessaires immédiatement, comme une barre de partage sur les réseaux sociaux.

La directive client:visible utilise un observateur d'intersection pour hydrater l'îlot uniquement lorsqu'il entre dans la fenêtre d'affichage au cours du défilement. Elle convient parfaitement aux îlots situés loin dans la page, comme une section de commentaires ou un carrousel de produits associés, que la plupart des utilisateurs n'atteindront peut-être jamais. JavaScript n'est même pas chargé avant d'être nécessaire.

La directive client:only ignore entièrement le rendu côté serveur et génère l'îlot uniquement dans le navigateur. Elle est nécessaire pour les composants qui utilisent des API propres au navigateur (window, document) ou qui dépendent de l'état côté client au moment du montage. La contrepartie est l'absence de HTML généré par le serveur pour cet îlot.

L'architecture en îlots résout complètement le problème de l'hydratation en veillant à ce que JavaScript ne soit chargé et exécuté que pour les composants véritablement interactifs. Un article de blog doté d'un bouton J'aime n'hydrate que l'îlot de ce bouton : le texte de l'article de 1 200 mots, l'en-tête et le pied de page n'entraînent aucune exécution de JavaScript côté client.

Chaque îlot possède son propre état isolé. Les îlots ne peuvent pas partager directement l'état React, car ils constituent des arbres React distincts. C'est intentionnel : si deux composants doivent partager un état, ils doivent être regroupés dans un seul îlot. La communication entre îlots utilise des paramètres d'URL, des événements DOM ou des bibliothèques d'état légères.

Les sites passés d'une SPA React à l'architecture en îlots, comme le site de documentation d'Astro, font état d'améliorations spectaculaires : le volume de JavaScript diminue de 70 à 90 %, le TTI s'améliore de 2 à 4 secondes sur mobile et les scores de performance Lighthouse passent de 60 à plus de 90. Les gains sont les plus marqués sur les pages riches en contenu.

Quelle directive d’hydratation d’Astro hydrate un composant uniquement lorsqu’il entre dans la zone visible de l’écran ?

L’architecture en îlots conserve la majeure partie de la page sous forme de HTML statique et hydrate uniquement des composants interactifs isolés. Astro fournit plusieurs directives d’hydratation : client:load (immédiatement), client:idle (lorsque le navigateur est inactif), client:visible (lors du défilement) et client:only (rendu uniquement côté client). Chaque îlot est hydraté indépendamment, ce qui rend la quantité de JavaScript proportionnelle à l’interactivité plutôt qu’à la taille de la page.