Chaque clic sur votre site web déclenche une chaîne d'événements. Lorsqu'un visiteur demande une page spécifique, le serveur de votre site web répond en livrant quelque chose que le navigateur peut afficher, généralement du HTML statique avec une déclaration doctype HTML qui définit la structure de la page (l'apparence, l'ergonomie et l'interface utilisateur).
Le rendu du contenu peut s'effectuer à deux endroits : côté client ou côté serveur. Dans le rendu côté client, l'ordinateur de l'utilisateur reçoit un fichier HTML minimal, et le navigateur du client (comme Google Chrome ou Safari) fait l'essentiel du travail, exécutant du JavaScript pour construire et afficher la page. Dans le rendu côté serveur, la page est entièrement assemblée sur le serveur avant d'être envoyée au navigateur, de sorte que l'utilisateur reçoit une page complète, prête à être affichée. Dans cet article, nous nous concentrerons sur cette dernière approche, le rendu de contenu côté serveur.
Qu'est-ce que le rendu côté serveur ?
Le rendu côté serveur (SSR) est un processus où un serveur web rassemble toutes les données nécessaires, la mise en page et les éléments d'interface utilisateur d'une page web, puis les assemble en un fichier HTML complet avant de l'envoyer au navigateur web de l'utilisateur. Le résultat est une page entièrement rendue qui est prête à être affichée. Cette approche permet des temps de chargement rapides avec des pages optimisées pour le SEO qui profitent à la fois aux visiteurs et aux robots des moteurs de recherche.
Par exemple, imaginez que vous gérez un site d'actualités. Lorsqu'un utilisateur clique sur un lien pour lire un article, un framework de rendu côté serveur récupère les données d'une base de données ou d'une API (en anglais), compile rapidement le contenu HTML pré-rendu (incluant la mise en page et les éléments d'interface utilisateur comme les titres, les signatures, la date de publication, les articles connexes, les menus de navigation et les espaces publicitaires), et le livre au navigateur de l'utilisateur. Le navigateur affiche ensuite la page entièrement rendue. Par la suite, le navigateur peut « hydrater » la page avec du contenu plus dynamique, comme charger les commentaires ou les votes positifs, en utilisant JavaScript pour rendre la page interactive.
Le SSR est particulièrement utile pour les sites qui dépendent fortement du trafic de recherche organique (puisque les pages pré-rendues sont plus faciles à explorer pour les moteurs de recherche) et qui comptent sur des vitesses de chargement rapides pour maintenir l'engagement des utilisateurs ; cela inclut les pages produits e-commerce. Et ce n'est pas comme si le SSR et le rendu côté client (CSR) étaient incompatibles, souvent, les deux sont utilisés à des fins spécifiques. Par exemple, une boutique e-commerce pourrait utiliser le SSR pour les pages produits mais utiliser le CSR pour le processus de commande.
Avantages du rendu côté serveur
- Premières impressions plus rapides
- Meilleures performances SEO
- Accessibilité améliorée
- Idéal pour le contenu dynamique
- Réduction de la charge JavaScript
Voici d'autres façons dont le rendu côté serveur peut améliorer les performances de votre site web :
Premières impressions plus rapides
Avec le rendu côté serveur, c'est le serveur web qui fait le gros du travail et délivre une page HTML entièrement construite directement au navigateur de l'utilisateur. Les visiteurs n'ont pas besoin d'attendre le téléchargement et l'exécution de JavaScript (comme c'est le cas avec le rendu côté client) avant de voir le contenu recherché.
Cette expérience, également appelée "first paint", peut s'avérer déterminante pour retenir les utilisateurs sur la page demandée. Un affichage rapide renforce leur confiance envers votre site et votre marque. C'est d'autant plus crucial pour les utilisateurs équipés d'appareils moins performants ou connectés sur des réseaux mobiles, où une page en rendu côté client (CSR) peut rester blanche pendant plusieurs secondes.
Meilleures performances SEO
La visibilité dans les moteurs de recherche est essentielle pour générer du trafic vers votre site, et le rendu côté serveur peut considérablement améliorer le classement de votre site. Les moteurs de recherche comme Google indexent votre contenu en lisant votre HTML avec leurs robots. Cela signifie qu'une page SSR est déjà dans le format idéal pour que Google puisse la lire et inclut des éléments comme les titres, les liens, le texte alternatif des images et les métadonnées, que Google utilise tous pour classer les sites web. Vous pouvez faciliter l'exploration de vos pages par Google avec le rendu côté client, mais cela peut nécessiter beaucoup de contournements supplémentaires et des outils tiers potentiellement coûteux.
Accessibilité améliorée
Le rendu côté serveur facilite la tâche aux personnes qui utilisent des lecteurs d'écran ou d'autres technologies d'assistance. Puisque le chargement initial de la page inclut le contenu HTML complet (plutôt qu'un modèle vide qui dépend de JavaScript pour se charger), les outils d'assistance peuvent immédiatement accéder et interpréter les informations. Mieux encore, si certains de vos utilisateurs ont JavaScript désactivé (ou utilisent des navigateurs plus anciens sans capacités JavaScript modernes), ils verront toujours une page fonctionnelle.
Avoir un site web plus accessible signifie également que vous pourrez vous conformer aux normes d'accessibilité comme les WCAG, particulièrement important si vous êtes dans un domaine réglementé comme l'éducation, le gouvernement ou les soins de santé.
Idéal pour le contenu dynamique
Si votre site web contient beaucoup de contenu qui change souvent, comme un blog ou un site d'actualités, le SSR est idéal. Vous pouvez combiner des données en temps réel via des API avec la livraison rapide offerte par le SSR. Cela vous donne la sensation de fraîcheur du rendu côté client tout en offrant des améliorations de vitesse et de SEO via le HTML rendu côté serveur. Les navigateurs de vos utilisateurs n'auront pas à faire tout le travail de récupération des données après le chargement de la page, ce qui la rend rapide et la maintient compatible avec les moteurs de recherche.
Réduction de la charge JavaScript
Alors que le rendu côté client s'appuie sur de nombreux bundles JavaScript, ceux-ci peuvent ralentir les utilisateurs mobiles et ceux sur des appareils plus anciens. Le SSR fait tout le gros travail avant le navigateur, donc JavaScript n'est pas nécessaire au départ. Cela profite également aux utilisateurs dans des zones avec des vitesses de réseau plus lentes ou des appareils plus limités, vous aidant à atteindre un public plus large et plus mondial.
Inconvénients du rendu côté serveur
- Temps jusqu'au premier octet (TTFB) plus long
- Infrastructure et déploiement plus complexes
- Charge serveur plus lourde
Les inconvénients du rendu côté serveur incluent :
Temps jusqu'au premier octet (TTFB) plus long
Le rendu côté serveur s'appuie sur le serveur web pour obtenir toutes les données nécessaires et rendre une page web HTML complète avant de pouvoir la livrer à l'utilisateur. Cela signifie qu'il pourrait y avoir un délai notable entre le moment où le navigateur demande la page et quand il commence finalement à recevoir ce contenu. C'est ce qu'on appelle le temps jusqu'au premier octet. Sans stratégies de mise en cache, cette latence peut se produire à chaque chargement de page, surtout pour les sites avec des besoins de récupération de données plus compliqués, menant à des goulots d'étranglement du serveur.
Infrastructure et déploiement plus complexes
Pour utiliser le rendu côté serveur, vous aurez besoin d'un environnement serveur en direct qui peut rendre les pages à la volée. Cela nécessite plus d'infrastructure et possiblement un support DevOps. Contrairement aux sites statiques, qui servent du HTML pré-construit avec des exigences minimales de base de données ou d'API, les sites SSR ont besoin d'un runtime comme Node.js et d'un hébergement qui supporte les fonctions serveur, comme Vercel, Netlify Edge ou Render. Gérer la disponibilité du serveur, l'évolutivité pour un trafic plus élevé, et traiter des problèmes comme les démarrages à froid peut ajouter de la complexité et peut nécessiter une équipe de développeurs dédiée.
Charge serveur plus lourde
Le rendu côté serveur nécessite beaucoup de ressources CPU de votre serveur web, car il rend les pages chaque fois qu'un utilisateur en demande une. À mesure que votre site reçoit plus de trafic, il aura besoin de plus en plus de ressources de calcul. Cela peut mener à des coûts d'hébergement plus élevés, des plantages potentiels du serveur dus à un trafic intense, et des temps de chargement plus lents à mesure que le serveur devient submergé.
Comment implémenter le rendu côté serveur
Le rendu côté serveur se déroule entièrement sur votre serveur web. Lorsqu'un utilisateur tape une URL ou clique sur un lien, le navigateur envoie une requête au serveur. Le serveur rassemble les données nécessaires, en puisant dans des sources externes ou des bases de données internes, et charge tous les éléments d'interface requis, comme les logos, les menus de navigation et autres composants de mise en page. Le serveur compile ensuite tout cela en une page HTML complète et la renvoie au navigateur de l'utilisateur. La page résultante est entièrement rendue et lisible immédiatement ; aucun chargement JavaScript requis (comme dans le rendu côté client).
Si vous êtes un entrepreneur cherchant à implémenter le rendu côté serveur sur votre site web, il y a quelques étapes que vous devrez suivre.
Sélectionner un framework SSR
D'abord, vous devrez choisir les bons outils de développement, ou frameworks de rendu côté serveur. Shopify Hydrogen (en anglais) est un framework basé sur React qui offre SSR, CSR et d'autres options. Next.js est un autre framework SSR assez bien documenté et largement adopté, mais SvelteKit, Nuxt.js, et Astro sont aussi souvent utilisés (en anglais).
Configurer votre stack de développement
C'est l'ensemble d'outils, frameworks, langages de programmation et services que vous utiliserez pour construire et faire fonctionner une application web avec rendu côté serveur. Cela peut inclure des frameworks front-end pour gérer l'interface utilisateur et le rendu côté serveur, ainsi que JavaScript côté client, et le langage de programmation (généralement JavaScript ou TypeScript).
Vous aurez également besoin d'un éditeur de code (comme VS Code, en anglais), d'une plateforme d'hébergement avec support SSR intégré comme Vercel ou Netlify (en anglais également), et d'un CMS, si vous servez votre propre contenu sur le web. Les exemples de CMS incluent Sanity, Contentful, ou l'open-source Strapi (en anglais).
Engager un développeur
Configurer un SSR peut être complexe. Vous pourriez vouloir engager un développeur web professionnel avec de l'expérience dans les frameworks côté serveur. Un professionnel expérimenté peut vous aider à choisir les bonnes technologies et optimiser les performances, ainsi que concevoir, construire et configurer le système back-end pour votre site.
Pensez à contacter des freelances via Upwork, Toptal et Gun.io. Vous pouvez aussi faire appel à une agence spécialisée dans Jamstack qui se spécialise dans la construction de sites web traitant JavaScript côté serveur, des API et du Markup, ou des agences qui travaillent avec des CMS headless (cela découple le back-end de contenu du front-end du site web).
FAQ - Qu’est-ce-que le rendu côté serveur ?
Ai-je besoin du rendu côté serveur, ou le côté client suffit-il ?
Cela dépend du type de site que vous construisez. Si vous voulez un chargement rapide, bien performer en optimisation pour les moteurs de recherche, ou servir du contenu dynamique frais, le SSR est une excellente solution. Les exemples de sites qui bénéficient du rendu côté serveur incluent : les vitrines avec des pages produits que vous voulez classer sur Google, les blogs ou sites de magazines, les sites marketing où une forte première impression est importante, et les pages avec du contenu fréquemment mis à jour. Pour les propriétaires de boutiques Shopify, utiliser le framework de commerce headless de Shopify, Hydrogen, permet une approche hybride qui utilise SSR et CSR.
Quel est l'inconvénient du rendu côté serveur ?
En fin de compte, le rendu côté serveur ajoute de la complexité à votre infrastructure de serveur web. Vous aurez besoin d'un serveur puissant pour générer dynamiquement les pages à la volée, ce qui peut signifier des temps de réponse quelque peu plus longs. Les sites de rendu côté serveur peuvent tomber en panne sous un trafic élevé, donc vous devrez planifier davantage autour de la mise en cache et de l'évolutivité.
Lequel est meilleur, SSR ou CSR ?
Les deux stratégies pour rendre les pages web ont des avantages et des inconvénients, et celle que vous choisissez sera basée sur les besoins du site que vous voulez créer. Utilisez le rendu côté serveur quand vous voulez vous concentrer sur le SEO, permettre des temps de chargement rapides pour des conversions rapides, ou servir des pages riches en contenu rapidement, ou si votre site présente des données qui changent fréquemment, comme un blog, un site e-commerce, ou un site d'avis. Utilisez le rendu côté client quand vous construisez une application web et non un site de contenu, quand le SEO est moins préoccupant (comme un tableau de bord utilisateur), et vous voulez un site avec moins de pièces mobiles et une configuration plus rapide pour les développeurs.





