Pourquoi SSR est plus pratique que SSG

Jun 30, 2024

Pourquoi SSR seul suffit

SSR (server-side rendering), fait référence au rendu de pages à la demande sur le serveur en temps d’exécution, puis leur transmission au frontend. SSG (server-side generation), fait référence à la compilation préalable de fichiers HTML statiques, et à leur transmission directe au frontend lors de la requête utilisateur.

Une fois les définitions clarifiées, il est facile de penser que SSR peut intégrer une logique dynamique, mais nécessite de faire fonctionner un serveur en permanence, tandis que SSG convient mieux au contenu statique et peut être placé sur un CDN. Le célèbre framework NextJS supporte à la fois SSR et SSG. Le nouveau venu Remix a complètement abandonné SSG, ils pensent qu’il y a suffisamment d’avantages à faire ainsi. Selon mon expérience, avec le support des CDN modernes, cela a effectivement du sens.

Des CDN modernes comme Cloudflare, Vercel supportent l’environnement serverless, déployer des programmes NodeJS est presque aussi pratique que déployer des fichiers statiques.
L’avantage de SSG n’est rien d’autre que de déployer directement des fichiers statiques sur le CDN, économisant les ressources serveur. Et SSR peut facilement mettre en cache le contenu sur le CDN en définissant un Cache-Control approprié. De cette façon, seul le premier appel exécutera le service SSR, presque identique aux fichiers statiques
Pas besoin de recompiler et redéployer à chaque modification de contenu statique
Une fois qu’on abandonne la pensée de NextJS qui distingue SSG et SSR, la charge mentale est considérablement réduite. La configuration du cache dépend entièrement des standards HTML comme Cache-Control, pas besoin d’apprendre une interface supplémentaire. Le débogage des problèmes de cache est aussi beaucoup plus pratique, quand le navigateur met en cache une requête qui ne devrait pas l’être, vous n’avez qu’à regarder votre Response écrite.

Un exemple

En fait, le site officiel de Remix est un excellent exemple. Sa documentation est générée par SSR. Beaucoup penseraient que la documentation étant du texte statique, SSG ne serait-il pas le meilleur ? L’équipe Remix explique les raisons de cette approche.

Leur documentation est placée dans le repository source de Remix, pas directement écrite sur le site officiel. Les avantages de placer la documentation avec le code source sont :

Plus de référence lors de la lecture du code
Facile de modifier la documentation lors de la modification du code
Git enregistrera automatiquement les changements de documentation, liés à la version du code source

Le serveur du site officiel lit le repository source de Remix et génère les pages de documentation via SSR. Les avantages de cette approche sont :

Pas besoin de recompiler et redéployer tout le site à chaque modification de documentation
Peut directement obtenir la documentation d’une version spécifique de Remix depuis le repository source, et même obtenir la documentation la plus récente de la branche dev. De cette façon, le site officiel peut afficher la documentation correspondant à n’importe quelle version de Remix.

La documentation n’étant pas des données en temps réel, ils ont aussi fait quelques optimisations de cache :

Utilisation de lru-cache pour mettre en cache les résultats de documentation. Le cache est côté serveur, donc tous les clients en bénéficient.
- Timeout défini à 5 minutes
Définition de Cache-Control comme stale-while-revalidate. Cela permet aussi au CDN de mettre en cache
```
return json(
  { doc },
  {
    headers: {
      "Cache-Control": "max-age=300, stale-while-revalidate=604800",
    },
  }
);
```
De cette façon, une fois que la documentation a des modifications, le site officiel ne sera retardé que de 5 minutes maximum (max-age=300) pour l’affichage.