Le rendu côté serveur, expliqué simplement (Next & Nuxt)
SSR, SSG, hydratation… Les mots font peur, l'idée est simple. Démystifions le rendu serveur.
Quand ton navigateur charge une application React ou Vue classique en mode SPA, il reçoit un fichier HTML presque vide et un gros bundle JS. Le contenu n'apparaît qu'une fois le JS exécuté. Résultat : une page blanche à l'ouverture, un score Lighthouse catastrophique, et un référencement inexistant.
C'est le problème que résolvent Next.js et Nuxt, les meta-frameworks de référence pour React et Vue.
Comment fonctionne le SSR
Avec le Server-Side Rendering, le serveur génère le HTML complet de la page avant de l'envoyer au navigateur. L'utilisateur voit le contenu immédiatement. Le JS arrive ensuite et "hydrate" la page pour la rendre interactive.
// Ce composant tourne sur le serveur — pas de bundle JS côté client
export default async function HomePage() {
const articles = await db.articles.findMany({ orderBy: { date: 'desc' } })
return (
<main>
{articles.map(a => <ArticleCard key={a.id} article={a} />)}
</main>
)
}SSR vs SSG vs ISR
SSR (Server-Side Rendering) — HTML généré à chaque requête. Parfait pour les données fraîches.
SSG (Static Site Generation) — HTML généré au build. Ultra rapide, idéal pour les blogs.
ISR (Incremental Static Regeneration) — SSG avec revalidation périodique. Le meilleur des deux mondes.
Pour un blog de dev, SSG avec ISR est le choix évident : performances maximales, contenu toujours à jour.
Next.js et Nuxt gèrent tout ça avec de simples options de configuration. La complexité est abstraite ; à toi de choisir la stratégie adaptée à chaque page.