Rendu côté serveur : expliqué simplement.

Le rendu côté serveur, ou SSR (Server-Side Rendering), est une technique où un serveur web génère le HTML complet d'une page pour chaque requête entrante, avant de l'envoyer au navigateur. Le visiteur reçoit immédiatement une page entièrement formée, plutôt qu'une coquille HTML quasi vide qui ne se remplit qu'une fois le JavaScript téléchargé, exécuté et les données récupérées. C'est important à la fois pour les visiteurs sur connexion lente, qui voient un contenu significatif plus tôt, et pour les robots d'indexation, qui peuvent lire le contenu de la page sans avoir à exécuter de JavaScript au préalable.

Le SSR s'oppose au rendu côté client, où le serveur envoie un fichier HTML minimal et un bundle JavaScript qui construit le contenu réel de la page dans le navigateur après son chargement. La plupart des frameworks modernes prennent aujourd'hui en charge les deux modes, et de nombreux sites en production les combinent selon la page.

À chaque requête, le serveur exécute le code de l'application, récupère les données nécessaires à la page, puis rend le balisage obtenu sous forme de chaîne HTML avant de l'envoyer en réponse :

// gestionnaire de requête SSR simplifié
app.get('/produit/:id', async (req, res) => {
const produit = await fetchProduit(req.params.id);
const html = renderToString(<PageProduit produit={produit} />);
res.send(`<html><body>${html}</body></html>`);
});

Le navigateur charge ensuite un bundle JavaScript qui attache les gestionnaires d'événements à ce HTML existant, une étape appelée hydratation, pour que la page devienne interactive sans que le navigateur ait à reconstruire le balisage depuis zéro.

• SSR classique : le HTML est rendu à neuf sur le serveur à chaque requête.
• Génération de site statique : les pages sont rendues une seule fois au build et servies comme fichiers statiques, sans travail serveur par requête.
• Régénération statique incrémentale : les pages statiques sont régénérées en arrière-plan selon un calendrier ou à la demande, combinant la vitesse du statique avec un contenu plus frais.
• SSR en streaming : le serveur envoie le HTML par blocs au fur et à mesure qu'il est prêt, ce qui permet au navigateur de commencer le rendu avant que la page entière ait fini d'être générée.

• Mettre en cache le HTML rendu quand le contenu ne varie pas selon le visiteur, pour éviter de relancer le rendu complet à chaque requête.
• Garder aussi légère que possible la récupération de données nécessaire au rendu initial d'une page ; une requête base de données lente sur le serveur retarde toute la réponse.
• Faire correspondre exactement la sortie du rendu serveur et du rendu client, car un écart pendant l'hydratation provoque un scintillement visible ou des avertissements d'hydratation React.
• Envisager la génération de site statique plutôt qu'un SSR complet pour les pages dont le contenu change rarement, ce qui supprime entièrement le coût serveur par requête.
• Surveiller le temps de réponse du serveur sous charge : le SSR déplace le coût du rendu de l'appareil du visiteur vers le serveur, qui doit pouvoir suivre.

Les moteurs de recherche peuvent indexer des pages rendues côté client, mais le SSR supprime toute incertitude en livrant un HTML complet et indexable dès la première réponse, ce qui est particulièrement précieux pour les sites à fort contenu, les catalogues e-commerce et les blogs où le trafic de recherche organique compte. Le SSR tend aussi à améliorer la vitesse de chargement perçue par les visiteurs, puisqu'un contenu significatif apparaît avant même que le bundle JavaScript complet ait fini de se télécharger et de s'exécuter, ce qui profite aux métriques Core Web Vitals comme le Largest Contentful Paint.

Quand nous développons des applications web sur mesure, nous choisissons entre rendu côté serveur, génération statique et rendu côté client selon la fréquence de changement du contenu d'une page et le trafic de recherche organique qu'elle doit capter, plutôt que d'appliquer une seule approche à tous les projets. Voir notre service web apps pour savoir comment nous architecturons les applications et frameworks que nous développons pour nos clients.