Next.js a débarqué dans nos vies comme ce pote un peu trop enthousiaste qui veut absolument vous présenter son nouveau framework préféré. « Regarde, il fait tout ! SSR, SSG, ISR… Tu n’as plus à choisir ! » Sauf que, comme souvent, quand quelque chose promet de tout faire, on finit par se demander si ça ne fait pas tout… à moitié.
SSR : le retour du serveur qui bosse (enfin)
Le Server-Side Rendering (SSR), c’est un peu le comeback des années 2000. À l’époque, PHP générait vos pages dynamiquement, et tout le monde était content. Puis est arrivé le règne du JavaScript côté client, avec ses spa qui chargeaient des coquilles vides avant de se remplir péniblement. Next.js a remis le serveur au centre du jeu : avec getServerSideProps, votre page est générée à la demande, avec des données fraîches à chaque requête.
L’avantage ? Pas de loading spinner qui tourne pendant 3 secondes parce que votre API met une éternité à répondre. Le serveur envoie une page déjà construite, et l’utilisateur voit quelque chose tout de suite. Le SEO adore, les réseaux sociaux aussi (parce que oui, Twitter et Facebook sont toujours incapables de rendre du JavaScript correctement).
Le revers de la médaille ? Si votre serveur est lent, votre page sera lente. Et si vous avez 10 000 requêtes simultanées, votre serveur va transpirer. Le SSR, c’est bien, mais ça coûte cher en ressources. À réserver aux pages qui ont vraiment besoin de données ultra-fraîches, comme un tableau de bord admin ou un fil d’actualités en temps réel.
SSG : la génération statique, ou l’art de tout préparer à l’avance
Le Static Site Generation (SSG), c’est la méthode préférée des puristes de la performance. Avec getStaticProps, Next.js génère vos pages à l’avance, au moment du build. Résultat : votre site est servi depuis un CDN, ultra-rapide, et votre serveur peut dormir tranquille.
C’est parfait pour les blogs, les sites vitrines, ou tout ce qui ne change pas toutes les 5 minutes. Le problème ? Si vos données évoluent, il faut rebuild le site. Et si vous avez 10 000 pages, ce build peut prendre… un certain temps. Sans compter que si vous voulez ajouter une nouvelle page, il faut tout regénérer. Bref, le SSG, c’est comme un bon vin : ça se bonifie avec le temps, mais ça ne supporte pas les changements de dernière minute.
Heureusement, Next.js a pensé à tout : entrez en scène, l’Incremental Static Regeneration (ISR).
ISR : le SSG qui se croit malin (et qui l’est, parfois)
L’Incremental Static Regeneration (ISR), c’est la réponse de Next.js à ceux qui trouvent le SSG trop rigide. Avec ISR, vous pouvez regénérer vos pages statiques… sans tout rebuild. Comment ? En définissant un revalidate dans getStaticProps. Par exemple, revalidate: 60 signifie que votre page sera regénérée toutes les 60 secondes si quelqu’un la demande.
export async function getStaticProps() {
const res = await fetch('https://api.example.com/data');
const data = await res.json();
return {
props: { data },
revalidate: 60, // Regénère la page toutes les 60 secondes
};
}
L’ISR, c’est un peu comme si vous aviez un SSG qui fait semblant d’être dynamique. Vous gardez les avantages du statique (performance, CDN), tout en ayant des données à peu près fraîches. Le tout sans surcharger votre serveur, puisque la regénération se fait en arrière-plan, et seulement si la page est demandée.
Mais attention, l’ISR n’est pas une solution magique. Si vos données changent toutes les 5 secondes, une regénération toutes les 60 secondes ne suffira pas. Et si personne ne visite votre page, elle ne sera jamais regénérée. Bref, l’ISR, c’est bien, mais ça ne remplace pas un vrai système de cache intelligent ou un SSR pour les cas critiques.
Alors, SSR, SSG ou ISR ? Le match des méthodes
Si vous voulez mon avis (et vous l’avez, puisque vous lisez cet article), voici comment choisir :
- SSR : pour les pages qui ont besoin de données ultra-fraîches, et où la performance serveur n’est pas un problème. Un tableau de bord admin, un fil d’actualités en temps réel, etc.
- SSG : pour les sites qui ne changent pas souvent, et où la performance est critique. Un blog, un site vitrine, une documentation technique.
- ISR : pour les sites qui ont besoin d’un peu de fraîcheur, sans vouloir tout rebuild à chaque changement. Un site e-commerce avec des produits qui changent occasionnellement, un portfolio avec des mises à jour régulières.
Et si vous hésitez encore, sachez que Next.js vous permet de mixer les méthodes. Vous pouvez avoir une page en SSR pour les données critiques, et le reste en SSG ou ISR. C’est ça, la vraie force de Next.js : il ne vous force pas à choisir. Il vous laisse juste le plaisir de vous demander quelle méthode est la moins pire pour votre cas d’usage.
En résumé, Next.js a démocratisé des concepts qui existaient déjà, mais en les rendant accessibles. SSR, SSG, ISR : trois outils pour trois besoins différents. À vous de jouer, sans vous laisser aveugler par la hype. Parce qu’au final, le meilleur framework, c’est celui qui résout vos problèmes… sans en créer de nouveaux.