Le glossaire classique SSG, SSR, ISR, souvent le premier réflexe pédagogique pour expliquer le rendu d’un site headless, s’arrête généralement à une question binaire : la page est-elle générée à l’avance ou à la demande ? Cette question ne suffit plus à décrire correctement ce qui se passe réellement sur un projet utilisant la partial hydration, une approche où la question pertinente n’est plus « quand » la page est générée, mais « quels fragments précis » de cette page nécessitent réellement du JavaScript côté client.
Ce texte s’appuie sur un projet réel, un site vitrine pour un cabinet d’architectes construit avec Astro et consommant WordPress headless via l’API REST, pour illustrer concrètement ce que change cette approche par rapport à une hydratation complète classique.
La page d’accueil décomposée en îlots
La page d’accueil du cabinet contenait sept zones distinctes : un en-tête de navigation, un diaporama de projets, une section « à propos » purement textuelle, un formulaire de contact rapide, une carte interactive des réalisations, une section témoignages avec carrousel, et un pied de page. Sur l’ancienne version du site, construite en React classique avec hydratation complète, l’intégralité de ces sept zones était hydratée au chargement, y compris la section « à propos », purement textuelle et strictement statique.
Avec Astro, chaque zone a été analysée individuellement pour déterminer si elle nécessitait réellement du JavaScript côté client, et si oui, à quel moment ce JavaScript devait être chargé :
| Zone | Stratégie retenue | Directive Astro |
|---|---|---|
| En-tête de navigation (menu mobile) | Interactif dès le chargement | client:load |
| Diaporama de projets | Interactif dès qu’il devient visible | client:visible |
| Section « à propos » | Aucun JavaScript nécessaire | aucune (HTML statique) |
| Formulaire de contact | Interactif dès qu’il devient visible | client:visible |
| Carte interactive des réalisations | Chargé uniquement en priorité basse | client:idle |
| Carrousel de témoignages | Interactif dès qu’il devient visible | client:visible |
| Pied de page | Aucun JavaScript nécessaire | aucune (HTML statique) |
Ce que ce découpage change concrètement
Le poids de JavaScript exécuté au chargement initial de la page est passé de 410 Ko sur l’ancienne version React à 33 Ko sur la nouvelle version Astro, une réduction de 92 %. Ce chiffre s’explique par le fait que la carte interactive, la bibliothèque la plus lourde du site (une dépendance de cartographie de plus de 180 Ko à elle seule), ne se charge désormais qu’après que le navigateur a fini de traiter les tâches jugées prioritaires, sans jamais bloquer l’affichage initial de la page.
---
// index.astro (extrait)
import CarteRealisations from '../components/CarteRealisations.jsx';
import Carrousel from '../components/Carrousel.jsx';
---
<CarteRealisations client:idle donnees={realisations} />
<Carrousel client:visible temoignages={temoignages} />Le compromis mesuré sur le formulaire de contact
Le choix de client:visible pour le formulaire de contact, situé en bas de page, a introduit un compromis assumé : sur un visiteur qui atteint directement cette section via une ancre de navigation, sans avoir fait défiler la page normalement, un très bref délai (mesuré à moins de 150 millisecondes sur un réseau mobile correct) sépare l’affichage visuel du formulaire de sa réelle interactivité. Ce délai, jugé imperceptible lors des tests utilisateurs menés en interne, aurait pu être évité avec client:load, au prix d’un JavaScript supplémentaire chargé systématiquement dès l’arrivée sur la page, même pour les visiteurs qui ne font jamais défiler jusqu’au formulaire.
Le vrai piège : penser le découpage après coup
La difficulté la plus sous-estimée sur ce projet n’a pas été technique mais méthodologique : découper une page déjà maquettée comme un tout monolithique en îlots indépendants demande de revenir sur des décisions de composition déjà prises. Un composant qui partage un état visuel avec son voisin (par exemple, un clic sur le diaporama qui devait mettre à jour la section témoignages) devient nettement plus complexe à gérer une fois ces deux zones traitées comme des îlots indépendants avec des stratégies de chargement différentes.
La leçon retenue par l’équipe a été d’impliquer les designers dès la phase de maquette dans cette réflexion de découpage, en identifiant explicitement, zone par zone, si une interaction visuelle dépend d’une autre zone de la page, avant même d’entamer le développement, plutôt que de découvrir ce couplage une fois le code déjà largement avancé.
- Identifier, pour chaque zone de la maquette, si elle nécessite réellement du JavaScript, et non par habitude de développement.
- Repérer les dépendances visuelles entre zones avant de les traiter comme des îlots totalement indépendants.
- Réserver la stratégie
client:loadaux seuls éléments dont l’interactivité immédiate est réellement critique pour l’expérience (menu de navigation, par exemple), et non par défaut.
La partial hydration ne se résume pas à un gain de performance automatique obtenu en changeant de framework ; c’est une discipline de découpage qui doit infuser la conception de la page bien avant la première ligne de code.
En résumé
Le glossaire SSG/SSR/ISR reste utile pour comprendre quand une page est générée, mais il ne répond plus à la question devenue centrale sur les projets modernes : quels fragments précis de cette page méritent réellement d’être interactifs, et à quel moment. La partial hydration déplace l’effort d’optimisation du serveur vers la conception même de l’interface, un changement de posture qui demande d’impliquer les designers bien plus tôt qu’auparavant dans les décisions techniques du projet.
