Le rendu côté serveur est une fonctionalité incontournable qui a déclenché l’émergence de toute une vague de nouveaux frameworks, dont Next.js.
Avant le SSR, on ne developpait en React quasiment que des Single Page Applications, qui reposent massivement sur du JavaScript côté client.
En effectuant le rendu du contenu sur le serveur avant de l’envoyer au client, le SSR permet des chargements de page initiaux plus rapide et une meilleure optimisation SEO.
Mais il y a plusieurs façons de faire du rendu côté serveur : au moment de la requête, au moment du build, et à encore plein d’autres moments.
Résultat, il y a tout un vocabulaire à maîtriser pour parler du rendu serveur.
Voici une méga-synthèse qui vous aidera à y voir plus clair :
Voici un résumé des approches les plus courantes, en fonction du moment où l’on génère le contenu de la page, et de la façon dont on actualise ce contenu.
| Data fetching & Rendu | Mise à jour | |
|---|---|---|
| Statique/export “SSG” | Build-time | Il faut rebuild |
| Incrémental | 1ère requête | Il faut rebuild |
| Revalidation | Build ou 1ère requête | Toutes les X secondes (si il y a des requêtes) |
| Revalidation à la demande | Build ou 1ère requête | Appel à revalidatePath ou revalidateTag |
| Dynamique “SSR” | Chaque requête | Chaque requête |
Notez que “SSR” signifie rendu côté serveur. Donc le rendu statique… techniquement c’est aussi du SSR !
Mais pour ne pas créer de confusions, la plupart des frameworks vont toujours parler de rendu statique ou SSG pour le rendu au build, et de SSR pour un rendu pour chaque requête HTTP d’un utilisateur.
En fait ce qui compte, c’est le “moment de rendu”. Pour le “lieu de rendu”, ça se passe côté serveur aussi bien pour le SSR que pour le SSG.
Très bien, mais cette synthèse est un peu abstraite. Comment choisir en pratique ?
| Moment de rendu | Ce qui l’active | Usage |
|---|---|---|
| Build-time | Défaut, option dynamic=force-static | Donnée identique pour tout le monde, change peu |
| 1ère requête | Paramètres non listés dans generateStaticPrams | Trop de pages à pré-générer au build |
| Revalidation | revalidate=60 | Données statiques, mais qui changent de temps en temps |
| On-demand Revalidation | revalidatePath/revalidateTag | Force la mise à jour d’un rendu statique après un changement |
| Request-time | Accéder à la requête via headers()/cookies(), faire un fetch avec {cache: 'no-store'}, dynamic=force-dynamic | Données personnalisées, ou fraîches |
Par exemple, pour un e-commerce :
Capture d’écran de l’application Next.js Commerce, un bon candidat pour un rendu statique avec revalidation !
Aujourd’hui, le rendu statique est utilisé par défaut dans Next.js.
Mais prochainement, le rendu dynamique risque de redevenir le mode par défaut dans les versions futures de Next.js (voir l’article “Our journey with caching” et l’annonce de Next.js 15 à ce sujet).
Les concepteurs de Next ont en effet constaté que le mode statique par défaut, bien que favorisant la performance, tendait à être plus confus pour les développeurs.
Il est en fait plus courant dans le développement web, avec ou sans Next, d’avoir un rendu dynamique par défaut, et de configurer explicitement le rendu statique.
La revalidation est une fonctionnalité relativement récente dans Next.js, par rapport aux rendus statiques et dynamiques qui sont plus connus.
Avec la revalidation, vous pouvez spécifier un intervalle de temps après lequel Next.js régénérera automatiquement la page en arrière-plan.
Cela garantit que votre contenu reste frais sans nécessiter un rebuild du site, et sans non plus avoir à passer sur un rendu pour chaque requête sur le site. On peut par exemple actualiser une page toutes les 10 minutes ou une fois par semaine, selon les besoins.
En plus de la revalidation basée sur une fréquence, Next.js prend également en charge la revalidation à la demande. Elle vous permet d’invalider programmatiquement le cache pour déclencher une mise à jour de la page via les fonctions revalidatePath ou revalidateTag.
Le rendu serveur se décline en plusieurs approches qui dépendent surtout du moment où l’on fait le rendu, et du moment où l’on actualise les données.
Le rendu statique et le rendu dynamique sont les plus connus. Mais il y a plein de solutions intermédiaires, par exemple la revalidation régulière des pages statiques.
Next.js permet d’utiliser librement chacune de ces approches pour s’adapter à toutes les situations : pages totalement statiques comme les mentions légales, pages qui changent peu comme des articles de blogs, pages très dynamiques contenant des données actualisées en temps réel, tout est possible !
Vous avez apprécié cette ressource ?
Découvrez toutes nos formations Next.js et Astro en présentiel ou en distanciel