SPA vs SSR vs site statique : que choisir ?

Avant toute discussion de framework, la question utile est : à quel moment le HTML que voit l’utilisateur est-il réellement produit. Il y a trois réponses honnêtes, et le choix entre elles façonne la performance, le SEO, le coût d’hébergement et la complexité opérationnelle pour la vie du projet.

Le HTML peut être produit au build : chaque page est rendue une fois, au déploiement, dans des fichiers statiques posés sur un CDN. L’utilisateur reçoit le HTML à l’instant où sa requête arrive. Le coût, c’est que tout ce qui est dynamique doit être ajouté par-dessus.

Il peut être produit à la requête : chaque fois qu’un utilisateur appelle une URL, un serveur exécute du code, va chercher les données dont il a besoin, et rend la page. L’utilisateur reçoit du HTML frais à chaque requête. Le coût, c’est que le serveur doit être là, allumé et chaud, pour chaque vue.

Il peut être produit côté client : le serveur envoie une coquille HTML quasi vide avec un bundle JavaScript, le navigateur télécharge et exécute, et la page apparaît une fois le bundle exécuté. L’utilisateur a un premier rendu lent, puis une application très interactive. Le coût, c’est tout ce qui se passe entre l’arrivée et l’exécution.

La plupart des débats « SPA vs SSR vs statique » sont en fait sur celle de ces trois temporalités qui correspond au projet. Choisir le framework d’abord et rabattre le mode de rendu derrière est la manière dont les équipes paient des capacités dont elles n’avaient pas besoin, ou ratent des capacités dont elles avaient besoin. La version spécifique à un framework, appliquée à Next.js, est traitée dans l’article quand utiliser Next.js.

La génération de site statique produit chaque page au déploiement. La sortie, ce sont du HTML, du CSS, du JavaScript et des assets en fichiers plats, servis depuis un CDN sans serveur applicatif au milieu.

C’est le bon mode quand le contenu est largement le même pour chaque visiteur et change selon un rythme contrôlé par l’équipe (publier un article de blog, mettre à jour une page marketing, livrer une nouvelle description produit). Cela donne le premier rendu le plus rapide possible, l’hébergement le moins cher possible (une facture CDN, pas une facture Node), et le modèle opérationnel le plus simple possible (si le déploiement a marché, le site marche). Pour le SEO sur du contenu stable, rien ne fait mieux.

Les compromis sont tout aussi clairs. Tout ce qui dépend de données que l’équipe n’avait pas au moment du build doit arriver après le chargement de la page, via du JavaScript côté client ou un appel API. Si le jeu de données change souvent, les temps de build grossissent avec : un site de 50 pages se construit en quelques secondes, un catalogue de 50 000 pages en minutes ou plus. Et la personnalisation par visiteur (état connecté, contenu localisé) ne s’insère pas dans le modèle sans aide depuis le edge ou le client.

Le rendu côté serveur exécute du code applicatif pour chaque requête et renvoie un HTML complet. L’utilisateur reçoit une page entière au premier rendu, avec les données fraîches que la requête demandait : dernier stock, derniers prix, contenu filtré pour la région de l’utilisateur, son propre tableau de bord.

C’est le bon mode quand la fraîcheur ou le contexte par requête comptent au niveau du HTML, et quand le SEO doit toujours fonctionner. Un tableau de bord connecté rendu côté serveur donne un premier rendu rapide et une vraie URL que le moteur de recherche n’a jamais eu besoin de voir, de toute façon. Un hub de contenu multilingue rendu côté serveur livre le HTML de la bonne locale avant qu’aucun JavaScript ne tourne.

Les compromis sont opérationnels. Un serveur doit tourner. Il doit être assez chaud pour absorber les pics. La facture d’hébergement croît avec le trafic d’une manière qu’une facture CDN ne fait pas. Les stratégies de cache (cache au edge, cache de page complète avec revalidation, règles de cache par route) font partie de la conception, pas d’un problème à régler la semaine du lancement. Bien réglée, la stratégie de cache permet au SSR de passer à l’échelle ; mal réglée, le serveur de rendu devient le goulot d’étranglement de tout le site.

Une single-page application envoie une coquille HTML quasi vide et un bundle JavaScript au navigateur. Le navigateur télécharge le bundle, l’exécute, va chercher les données, et peint la page. Une fois ce coût initial passé, la navigation entre les routes est rapide parce qu’aucun rechargement complet n’est nécessaire.

C’est le bon mode pour les applications, pas pour les sites web. Un produit connecté (un CRM, un tableau de bord, un outil d’édition) où le SEO ne s’applique pas, où l’utilisateur va passer vingt minutes dans l’application, et où le coût du bundle initial est amorti sur une session longue. Une fois chargée, l’expérience est plus proche d’une application native que d’une page web.

Les compromis, ce sont tout ce qui se passe entre l’arrivée et l’exécution. Le premier rendu est lent, surtout sur de mauvaises connexions. Le SEO est difficile, parce que le crawler voit la coquille vide à moins que du travail supplémentaire ne soit fait. Le temps avant interactivité dépend de la taille du bundle, qui ne fait que grossir. Le routage dépend du JavaScript qui fonctionne, ce qui veut dire qu’un bundle cassé casse tout le site. Aucun de ces points n’est rédhibitoire pour les applications qui correspondent à la forme SPA ; ils le sont pour les sites web qui n’y correspondent pas.

Les formes pures ci-dessus sont utiles pour réfléchir, mais peu de projets réels s’y tiennent proprement. Un dispositif mature classique combine les trois, et c’est généralement la bonne réponse.

Les pages marketing sont statiques (rendues au build, servies depuis le CDN, rapides et peu coûteuses). Les pages de contenu avec données dynamiques sont rendues côté serveur (catalogues filtrables, hubs multilingues, pages localisées). L’application connectée derrière le mur de connexion est une SPA (ou s’en rapproche), parce que le SEO n’y a pas d’importance et que la session est assez longue pour amortir le coût du bundle.

Les frameworks modernes (Next.js, Remix, Astro, SvelteKit) sont conçus autour de cet hybride. La régénération statique incrémentale permet à un site statique de rafraîchir des pages individuelles selon un rythme sans tout reconstruire. L’architecture en îlots permet à des pages statiques de contenir de petits composants interactifs qui s’hydratent indépendamment. Les React Server Components poussent la frontière plus loin en décidant par composant s’il rend côté serveur ou côté client. La bonne nouvelle, c’est que le mode de rendu n’a plus besoin d’être choisi pour tout le site. La mauvaise, c’est que le choisir par page ou par composant demande plus de discipline de conception, pas moins.

Trois questions couvrent l’essentiel du choix en pratique.

La page doit-elle être indexable par les moteurs de recherche, avec un contenu qui dépend de données dynamiques ? Si oui, le rendu au build ou à la requête est le plancher. La SPA seule n’est pas la bonne réponse pour du contenu critique pour le SEO avec des données dynamiques, peu importe à quel point le contournement est astucieux.

Le contenu d’une URL donnée change-t-il pour chaque visiteur, ou selon un rythme prévisible ? Du contenu par visiteur (état connecté, personnalisation, résultats de recherche) appelle un rendu à la requête ou côté client. Du contenu à rythme prévisible (articles de blog, pages marketing, descriptions produits qui changent chaque semaine) appelle un rendu au build avec un rafraîchissement périodique.

Que fait réellement tourner l’équipe en production aujourd’hui ? L’hébergement statique sur un CDN est opérationnellement moins cher qu’un serveur Node, qui est opérationnellement moins cher qu’une SPA lourde côté navigateur avec une API séparée. Les décisions d’architecture qui ignorent le modèle opérationnel existant de l’équipe vieillissent mal. Le versant SEO technique et performance de ces décisions, dont la manière dont le mode de rendu interagit avec les Core Web Vitals, s’inscrit dans la discipline plus large de la performance technique.

SPA, SSR et génération statique ne sont pas des tendances en compétition. Ce sont trois réponses à la question de quand la page est produite, et les projets modernes utilisent couramment les trois dans un même codebase. L’erreur, c’est de traiter le mode de rendu comme une fonctionnalité de framework ; c’est une décision de projet qui doit guider le choix de framework, pas l’inverse. Choisissez le mode de rendu qui correspond au contenu, au SEO, à l’équipe et au modèle d’hébergement, et la plus grande partie du débat sur le framework devient plus simple.

Le contexte plus large, dont la manière dont les choix de rendu se relient à l’architecture, à la performance et à la stratégie de contenu, est rassemblé dans le cluster architecture web et plateformes. Et lorsque la question passe de « quel mode de rendu choisir » à « nous avons choisi, et il nous faut maintenant quelqu’un pour le livrer correctement, avec le SEO, les Core Web Vitals et le modèle d’hébergement qui correspondent », c’est exactement ce sur quoi mon accompagnement SEO technique et performance web est centré.