Le rendu côté serveur (SSR) est une fonctionalité incontournable du développement d’applications web performantes. Le SSR est au coeur de toute une génération de frameworks, dont Next.js a été le pionnier.
Avant le SSR, on ne developpait en React quasiment que des Single Page Applications (SPA), qui reposent massivement sur du JavaScript côté client, exécuté dans le navigateur.
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 relativement complexe à maîtriser pour parler du rendu serveur. Nous consacrons un jour entier à ce concept dans notre formation Next.js !
Voici une méga-synthèse qui vous aidera à y voir plus clair :
- D’un point de vue théorique, si vous voulez briller pendant vos entretiens d’embauche pour un poste de développeur web fullstack
- D’un point de vue pratique, si vous voulez optimiser vos applications Next.js en choisissant le bon mécanisme de rendu serveur
Méga-synthèse du rendu côté serveur - terminologie
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 recombiler |
| Incrémental | 1ère requête | Il faut recompiler |
| 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, par opposition à un rendu dans le navigateur de l’utilisateur, côté client.
Donc le rendu statique, qui se produit sur votre propre serveur de développement ou de production est techniquement aussi du SSR !
Illustration d’un data center : le rendu SSR et le rendu SSG vont tout deux être réalisés ici, mais pas au même moment.
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”, quand le HTML est produit à partir de votre code Next.js et React. Pour le “lieu de rendu”, l’endroit où le calcul est effectué, cela 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. En pratique, comment choisir le mécanisme de rendu serveur le plus approprié dans une application Next.js ?
Méga-synthèse du rendu côté serveur - en pratique
Voici comment activer chaque mécanisme de rendu serveur dans Next, du SSR au SSG
| Moment de rendu | Ce qui l’active | Usage |
|---|---|---|
| Compilation/build (SSG) | 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 |
| Revalidation à la demande | revalidatePath/revalidateTag | Force la mise à jour d’un rendu statique après un changement |
| Requête dynamique (SSR) | 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 :
- je vais utiliser un rendu build-time pour les 10 produits phares, un rendu incrémental à la première requête pour les 99 990 autres produits.
- je vais mettre en place une revalidation quotidienne, au cas où les informations des produits changent.
- je peux aussi mettre en place une revalidation à la demande en connectant un CMS : le produit se met à jour dès que quelqu’un change sa description en base de données.
- pour la page panier de l’utilisateur courant, je vais utiliser un rendu dynamique.
Capture d’écran de l’application Next.js Commerce, un bon candidat pour un rendu statique avec revalidation !
Rendu statique ou rendu dynamique : lequel choisir par défaut ?
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.
Zoom sur la revalidation
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 système de mise en cache va beaucoup évoluer dans la prochaine version de Next.js (version 16) pour remplacer les fonctions cache et unstable_cache, qui sont trop complexes. Vous pouvez déjà tester la directive “use cache” dans Next 15 en activant la fonctionnalité expérimentale !
En résumé : plusieurs techniques pour le rendu serveur dans Next.js
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 !
