Server-Side Rendering (SSR)

Comment fonctionne le SSR ?

Lorsqu'un utilisateur demande une page, le serveur execute le code de l'application, recupere les donnees necessaires (depuis une base de donnees ou une API REST), puis genere le HTML complet. Ce HTML est envoye au navigateur qui peut l'afficher immediatement, sans attendre le chargement de fichiers JavaScript volumineux.

Apres le premier affichage, le JavaScript client prend le relais pour rendre la page interactive. Ce processus, appele hydratation, permet de combiner les avantages du rendu serveur avec l'interactivite d'une application JavaScript moderne.

Contrairement au Static Site Generation (SSG) ou les pages sont generees au moment du build, le SSR genere le HTML a chaque requete. Cela le rend ideal pour les contenus dynamiques ou personnalises, comme les tableaux de bord ou les pages qui dependent de l'authentification de l'utilisateur.

Pourquoi utiliser le SSR ?

• -- Meilleur referencement naturel (SEO) grace au HTML pre-rendu
• -- Temps d'affichage initial (First Contentful Paint) reduit pour l'utilisateur
• -- Contenu toujours a jour car genere a chaque requete
• -- Ideal pour les pages dynamiques, personnalisees ou protegees
• -- Compatibilite parfaite avec les reseaux sociaux pour le partage (Open Graph)

SSR en pratique

Next.js est le framework de reference pour le SSR dans l'ecosysteme React. Avec son App Router, il offre un controle granulaire sur le rendu : on peut choisir page par page entre SSR, SSG ou un mode hybride. Deploye sur Vercel, un site Next.js en SSR offre des performances remarquables grace au edge rendering.

Pour une creation de site web, le choix entre SSR et SSG depend du contenu. Un blog ou un site vitrine profite davantage du SSG, tandis qu'une application web avec authentification necessite du SSR pour servir un contenu personnalise a chaque utilisateur.