Le rendu côté serveur expliqué sans jargon, avec ses cas d'usage

La question de savoir où une page est fabriquée revient dans toutes les discussions techniques, avec un vocabulaire qui décourage les personnes chargées de décider. Derrière les acronymes, la question est simple : le serveur envoie t il une page complète, que le navigateur n'a plus qu'à afficher, ou envoie t il un document presque vide accompagné d'un programme chargé de le remplir. Les deux approches existent depuis longtemps, elles ont chacune leurs usages, et le choix a des conséquences concrètes sur le référencement, sur la vitesse perçue et sur le coût de développement. Le problème est que la décision est souvent prise par des personnes qui maîtrisent la technique, pour des raisons techniques, alors qu'elle engage des enjeux commerciaux que ces personnes ne portent pas. Nous reprenons donc le sujet depuis le début, en écartant le vocabulaire spécialisé chaque fois qu'il est possible de s'en passer.

Ce qui se passe réellement

Comprendre la séquence d'affichage suffit à saisir l'essentiel du sujet, sans avoir besoin de connaître les cadres applicatifs ni leur vocabulaire. La chronologie d'affichage d'une page est détaillée dans notre article sur le rendu critique et son analyse à partir du code source.

La page produite par le serveur

Le navigateur demande une adresse, le serveur construit la page complète en allant chercher les contenus, et il renvoie un document HTML contenant tout le texte. Le navigateur affiche ce texte immédiatement, puis charge les styles et les éventuels scripts. C'est le fonctionnement historique du web et celui de la plupart des systèmes de gestion de contenu. Le texte est présent dès la première réponse, ce qui a des conséquences importantes. Tout ce qui lit la page sans exécuter de programme, moteurs de recherche compris, y trouve immédiatement le contenu. Le travail du serveur est plus lourd, puisqu'il assemble la page à chaque demande, mais ce coût se maîtrise très bien.

La page produite par le navigateur

Le serveur renvoie un document presque vide, contenant essentiellement un conteneur et un lien vers un programme. Le navigateur télécharge ce programme, l'exécute, celui ci demande les contenus au serveur par une seconde requête, puis construit la page. L'affichage n'intervient qu'à la fin de cette chaîne, ce qui allonge le délai avant que quoi que ce soit ne devienne visible. Cette approche s'est répandue avec les applications web et elle a été étendue à des sites qui n'en avaient pas besoin. Le serveur travaille alors très peu, ce qui a longtemps été présenté comme un avantage, mais le travail a simplement été déplacé sur l'appareil du visiteur. Or cet appareil est souvent un téléphone de milieu de gamme sur un réseau moyen.

La combinaison des deux

Une troisième voie produit la page côté serveur, comme dans le premier cas, puis laisse le programme prendre le relais pour les interactions ultérieures. Le visiteur obtient un affichage immédiat et une navigation fluide ensuite. C'est ce que proposent aujourd'hui la plupart des cadres applicatifs modernes et c'est le compromis retenu par la majorité des projets sérieux. Elle demande que le même code puisse s'exécuter des deux côtés, ce qui constitue sa principale contrainte technique. Elle suppose aussi un environnement serveur capable d'exécuter ce code, ce qui exclut les hébergements les plus simples. Le gain est réel lorsque le site combine des pages à référencer et des espaces réellement interactifs.

La génération à l'avance

Une quatrième approche produit toutes les pages une fois pour toutes, au moment de la publication, et les sert comme de simples fichiers. Le serveur n'a alors plus rien à calculer et la réponse est quasi instantanée. Cette méthode convient parfaitement aux contenus qui changent peu et elle devient contraignante dès que les pages dépendent du visiteur. C'est souvent la solution la plus rapide et la moins coûteuse à héberger. Les fichiers peuvent être distribués depuis un réseau de diffusion, au plus près du visiteur, sans aucune logique à exécuter. La contrepartie est la republication complète ou partielle à chaque modification, qui prend de quelques secondes à plusieurs minutes selon la taille du site.

Le rôle du cache

Un site produit côté serveur peut mettre en cache ses pages, ce qui le rapproche du comportement d'un site généré à l'avance. Cette nuance est essentielle : un site dynamique correctement mis en cache répond aussi vite qu'un site statique dans la quasi totalité des cas. Beaucoup de discussions sur le rendu portent en réalité sur l'absence de cache. Vérifier ce point avant de conclure à un problème d'architecture évite des chantiers inutiles. Un site jugé lent parce qu'il interroge une base de données à chaque affichage devient rapide dès que les pages sont conservées quelques minutes. Le contrôle est simple : mesurer le temps de réponse du serveur avec puis sans cache actif.

Le vocabulaire qui embrouille

Les termes employés désignent souvent des variantes proches, ce qui donne l'impression d'un domaine plus complexe qu'il ne l'est. Rendu serveur, rendu client, hydratation, génération statique, rendu à la demande : cinq expressions pour décrire des combinaisons de deux idées simples. Se ramener systématiquement à la question de savoir qui produit le texte, et quand, clarifie n'importe quelle discussion. C'est la seule chose à retenir pour décider. Le reste relève du choix d'outil, qui vient après et qui se discute avec les personnes qui écriront le code. Poser la question dans ces termes permet à un dirigeant de participer utilement à un arbitrage technique.

Ce que cela change concrètement

Les conséquences se mesurent dans quelques domaines précis, dont l'importance relative dépend entièrement du type de site. Un site vitrine et une application métier ne donnent pas le même poids aux mêmes critères, et c'est précisément pour cela qu'aucune réponse générale n'existe. Passer en revue chacun de ces domaines pour son propre projet suffit généralement à faire apparaître la bonne décision.

La découverte par les moteurs

Un moteur exécute aujourd'hui le JavaScript, ce qui signifie qu'un site produit côté navigateur finit par être indexé. Cette exécution intervient dans un second temps, parfois plusieurs jours après la première lecture, ce qui retarde la prise en compte des contenus. Sur un site publiant régulièrement, ce décalage se paie en visibilité, particulièrement sur des sujets d'actualité où l'antériorité compte. Le phénomène reste invisible tant qu'on ne compare pas les dates de publication et les dates d'apparition dans les résultats. Les liens produits par script posent en outre des questions particulières, développées dans notre article sur les liens JavaScript que Google suit et ceux qu'il ignore.

Le délai avant affichage

Une page produite côté serveur affiche son texte dès la première réponse, soit quelques centaines de millisecondes sur une connexion correcte. Une page produite côté navigateur ajoute le téléchargement du programme, son exécution et une seconde requête, soit plusieurs secondes sur une connexion mobile modeste. Cet écart se mesure directement dans les indicateurs d'expérience et il se voit à l'œil nu lorsqu'on ouvre les deux pages côte à côte. Il pèse davantage sur les appareils anciens, dont la capacité de calcul limite l'exécution. Le téléchargement du programme est rarement le point bloquant : c'est son interprétation par le processeur qui coûte le plus cher. Un appareil de trois ou quatre ans peut mettre deux à trois fois plus de temps qu'un modèle récent sur la même page.

Le comportement sans script

Une part faible mais réelle des visites se déroule sans JavaScript fonctionnel : réseau instable, script bloqué, erreur de chargement. Une page produite côté serveur reste lisible dans ces conditions, une page produite côté navigateur affiche une zone vide. Ce cas ne concerne que quelques pour cent des visites et il concerne cent pour cent des visiteurs lorsqu'un script tiers échoue. C'est un argument de robustesse plutôt que de volume. Une page produite côté serveur se dégrade progressivement : sans script, elle perd des fonctions mais reste lisible. Une page produite côté navigateur ne se dégrade pas, elle disparaît.

Le partage sur les réseaux

Les outils qui produisent un aperçu lors d'un partage lisent le document initial sans exécuter le programme. Une page produite côté navigateur ne leur montre ni titre, ni description, ni image, ce qui produit des partages vides. Ce comportement surprend et il est parfaitement logique. Il constitue souvent l'argument qui fait basculer une décision, l'effet étant immédiatement visible. Il suffit de coller l'adresse d'une page dans une conversation pour constater si l'aperçu se construit. Les messageries professionnelles se comportent de la même manière, ce qui touche aussi la diffusion interne des contenus.

Le coût de développement

Un site produit côté serveur emploie une technologie unique et il se développe plus vite. Un site produit côté navigateur suppose deux couches, une interface et une interface de données, ce qui double la surface de code. La combinaison des deux ajoute encore une complexité de configuration et une charge de maintenance qui se prolonge sur toute la vie du site. Ce coût doit entrer dans la décision au même titre que les considérations techniques. Il se manifeste aussi au recrutement, puisque les profils capables de tenir une pile complète sont plus rares et plus chers. Sur un budget contraint, cette différence détermine ce qui pourra réellement être livré.

La richesse des interactions

C'est le seul domaine où le rendu côté navigateur l'emporte nettement. Une application où l'utilisateur manipule des données en continu, sans rechargement, offre une expérience qu'aucune page classique ne reproduit. Les bibliothèques modernes, dont les principes sont présentés dans notre article sur React.js, son fonctionnement et son rapport au SEO, ont été conçues pour ce besoin précis. Le reproche qui leur est fait ne porte pas sur elles mais sur leur emploi hors de leur terrain naturel. Utilisées là où elles servent, elles n'ont pas d'équivalent.

Quand le rendu serveur s'impose

Quelques situations rendent le choix évident, et les reconnaître évite de longues discussions. Dans ces cas, le débat ne porte plus sur une préférence technique mais sur un objectif que le site doit atteindre, ce qui tranche immédiatement. Nous les passons en revue afin que chacun puisse situer son propre projet.

Le contenu doit être trouvé

Dès que la visibilité dans les moteurs constitue un objectif commercial, produire le contenu côté serveur supprime une incertitude. Le rendu par le moteur fonctionne et il ajoute un délai et une dépendance dont on se passe volontiers. Sur un site dont le trafic vient majoritairement de la recherche, ce choix ne se discute pas vraiment. Il constitue le cas le plus fréquent sur les projets d'entreprise. Le raisonnement tient en une phrase : lorsque l'essentiel des visites dépend d'un mécanisme, on ne lui ajoute pas d'obstacle facultatif. La prudence coûte ici moins cher que la démonstration inverse.

Le volume de contenus est important

Un catalogue de plusieurs dizaines de milliers de pages exige une exploration efficace, ce que le rendu retarde. Le coût d'exécution du JavaScript conduit les moteurs à espacer leurs passages, ce qui pénalise proportionnellement les gros sites. C'est exactement l'inverse de ce dont on aurait besoin. Ce point à lui seul écarte le rendu côté navigateur sur les grands catalogues. Le budget d'exploration d'un site se répartit sur l'ensemble de ses adresses, et chaque page coûteuse en consomme une part disproportionnée. Sur un catalogue en évolution constante, les pages nouvelles attendent alors plus longtemps.

Le public est mal connecté

Un site destiné à un public rural, à des zones mal couvertes ou à des appareils anciens subit plus durement le coût d'exécution. La différence entre une page affichée en une seconde et une page affichée en six est alors décisive. Ce critère est souvent ignoré parce que les équipes de développement travaillent sur du matériel récent, sur une connexion filaire, dans des conditions qui n'ont rien de représentatif. Regarder la répartition réelle des appareils dans les statistiques tranche la question. Les outils de mesure permettent de simuler une connexion dégradée et un processeur ralenti, ce qui donne une image bien plus proche du terrain. L'écart entre les deux mesures surprend presque toujours.

Le partage compte

Sur un site dont la diffusion passe par les réseaux, l'aperçu au partage constitue un élément déterminant. Le produire correctement suppose un document initial complet. Cette contrainte peut être traitée par une génération dédiée pour les robots de partage, solution qui fonctionne et ajoute une complexité, ainsi qu'une dépendance supplémentaire à surveiller. Produire la page côté serveur règle le point sans détour. La règle générale reste valable : chaque contournement ajouté pour compenser un choix d'architecture devient une pièce à maintenir. Additionnés, ces contournements finissent par coûter plus que l'approche qu'ils évitaient.

L'équipe est réduite

Une structure disposant d'un développeur a intérêt à choisir la solution qui demande le moins de code et le moins de configuration. Un site produit côté serveur, appuyé sur un système de gestion de contenu éprouvé, est nettement plus rapide à construire et à maintenir. Cette considération pratique pèse davantage que les arguments techniques sur les petits projets. Elle est rarement énoncée et elle détermine souvent la réussite. Un site simple qui fonctionne vaut mieux qu'une architecture ambitieuse laissée inachevée faute de temps. Le départ de la seule personne qui maîtrisait la pile met par ailleurs le site en difficulté immédiate.

Le contenu change peu

Sur une documentation, un site institutionnel ou un blog, la génération à l'avance produit le meilleur résultat possible pour un coût d'hébergement dérisoire. Aucune base de données n'est interrogée à l'affichage et la surface d'attaque se réduit considérablement. Cette approche mérite d'être considérée bien plus souvent qu'elle ne l'est. Elle suppose un processus de publication un peu différent, ce qui constitue son seul obstacle. Les rédacteurs travaillent alors dans une interface qui déclenche une republication, au lieu de modifier directement une page en ligne. L'attente de quelques minutes entre l'enregistrement et la mise en ligne demande une petite habitude, rien de plus.

Quand cela ne se justifie pas

Le rendu serveur n'est pas une réponse universelle et l'imposer partout produit des complications inutiles. Les situations qui suivent justifient pleinement l'approche inverse, ou rendent tout changement déraisonnable. Les reconnaître évite de lancer une refonte dont personne ne tirera bénéfice.

Une application derrière authentification

Un outil métier accessible après connexion n'a aucun besoin d'être indexé et il gagne à offrir une interface réactive. Le rendu côté navigateur y est parfaitement adapté et le rendu serveur n'apporterait qu'une contrainte. La question du référencement disparaît entièrement, ce qui simplifie l'arbitrage et recentre la discussion sur le confort d'utilisation. C'est le cas d'usage historique de ces bibliothèques. Les pages publiques de présentation du service peuvent parfaitement être traitées séparément, avec une approche différente. Rien n'oblige un site à retenir une seule architecture pour l'ensemble de ses adresses.

Une interface très interactive

Un configurateur, un tableau de bord ou un éditeur manipulent des données en continu. Recharger la page à chaque action serait absurde et le rendu côté navigateur s'impose naturellement. Un rendu serveur initial peut néanmoins être conservé pour l'affichage de départ, ce qui donne le meilleur des deux. Cette combinaison est aujourd'hui la configuration la plus courante sur ce type d'outil. Le visiteur voit la structure de l'interface pendant que le programme se charge, plutôt qu'un écran vide. Cette perception de rapidité compte autant que la mesure elle même.

Un site déjà rapide

Un site produit côté navigateur mais correctement optimisé, avec un programme léger et une réponse rapide, peut obtenir de bons indicateurs. Le refondre pour changer d'approche coûterait cher pour un gain marginal. La mesure doit précéder la décision, et elle conduit parfois à ne rien faire. C'est une conclusion parfaitement acceptable, et souvent la plus rentable. Le budget disponible produira davantage d'effet en contenus, en maillage ou en travail sur les pages qui convertissent. Une architecture correcte mais imparfaite ne justifie pas de mobiliser le budget d'une année entière.

Le coût de la migration

Passer un site existant d'une approche à l'autre représente une refonte technique complète, avec les risques associés. Ce chantier ne se justifie que si le gain attendu est important et mesuré. Sur un site dont le trafic ne vient pas de la recherche, il ne se justifie généralement pas. Cette évaluation doit être faite honnêtement plutôt que par principe. Un chiffrage sérieux comprend la refonte, la recette, la reprise des adresses et la période d'instabilité qui suit toute mise en ligne. Comparé au gain estimé, ce total conduit fréquemment à reporter le chantier ou à le traiter par étapes.

La complexité ajoutée

La combinaison des deux approches, séduisante sur le papier, ajoute une couche de configuration et une classe de problèmes propres, notamment les écarts entre ce que produit le serveur et ce que reconstruit le navigateur. Ces écarts se diagnostiquent difficilement. Sur une équipe qui découvre la technologie, cette complexité peut coûter plus qu'elle n'apporte. Commencer simple reste une bonne règle, quitte à faire évoluer l'architecture une fois les besoins réels connus. Les écarts entre les deux rendus se manifestent souvent sur des détails inattendus, comme le formatage des dates ou l'usage d'un contenu aléatoire. Ils apparaissent en production, rarement pendant les tests.

La mode comme argument

Le choix d'une architecture ne devrait jamais reposer sur ce qui se fait ailleurs ni sur ce qui figure sur un curriculum. Beaucoup de sites vitrines construits côté navigateur l'ont été pour cette raison, avec un coût de développement doublé et un référencement dégradé. Poser la question des objectifs avant celle des technologies évite cette dérive. C'est la recommandation la plus utile de tout l'article. Une bonne façon de procéder consiste à écrire en trois lignes ce que le site doit accomplir, puis à ne discuter d'outils qu'ensuite. Si personne n'est capable d'expliquer en langage courant pourquoi une architecture a été retenue, c'est généralement qu'elle ne l'a pas été pour de bonnes raisons.