Un site de contenu a une seule mission : charger vite, être trouvé, et rester debout. Une page rendue dans le navigateur rend ces trois choses plus difficiles que nécessaire. Elle arrive comme une coquille vide, puis le JavaScript va chercher le contenu et le dessine. Les robots de recherche et des réseaux voient d'abord la coquille. Un visiteur sur un appareil lent attend l'exécution avant qu'un seul mot n'apparaisse. Et toute la page dépend d'un code client qui s'exécute correctement, sur chaque appareil, à chaque fois. Pour un site vitrine, cela fait beaucoup de mécanique pour bien peu.
Prérendre au build, servir du HTML simple
L'alternative, c'est de faire le travail une fois, en amont. Au build, chaque route est rendue en un document HTML complet et servie depuis un réseau de diffusion. Le navigateur reçoit une page finie, pas une liste d'instructions pour l'assembler. Les robots reçoivent des mots, pas un conteneur vide. Le premier affichage devient fonction du réseau, pas de la vitesse à laquelle un appareil exécute votre JavaScript.
Ce à quoi vous renoncez, et pourquoi c'est rarement grave
La diffusion statique renonce au rendu par requête : la page est figée jusqu'au prochain build. Pour du contenu, ce n'est pas une vraie perte. Une page vitrine change quand quelqu'un publie, pas à chaque visite, et un rebuild à la publication suffit. Les vraies exceptions, données en direct et personnalisation par utilisateur, ne sont en général que de petites parties d'une page. Elles ont leur place dans des îlots interactifs isolés, pas comme prétexte à rendre tout le site dans le navigateur.
Ce que vous gagnez
Les gains sont ce qui compte vraiment pour une organisation. Du HTML explorable, pour que le contenu soit indexé et cité. Un premier affichage rapide, parce qu'il n'y a plus de runtime entre le visiteur et les mots. Des pages qui se mettent en cache au edge, ce qui réduit le coût et absorbe les pics de trafic. Et bien moins de façons d'échouer : un document statique ne lève pas d'erreur d'exécution sur un appareil que vous n'avez jamais testé. Moins de pièces mobiles n'est pas une limite ici. C'est l'objectif.
La page la plus fiable est celle qui est déjà rendue.
Le statique d'abord est le bon défaut pour tout contenu qui évolue à un rythme humain. Gardez le rendu navigateur pour ce qui est vraiment par requête, et contenez-le quand vous y avez recours. Pour tout le reste, livrez la page finie.