Comparaison entre le client-side rendering, le server-side rendering et la génération de site statique

Chaque fois que vous visitez un site Web, votre navigateur doit assurer le rendu de cette page afin de pouvoir la présenter de manière attrayante et fournir le degré d’interactivité que vous souhaitez. Selon l’approche de programmation adoptée pour le projet Web, les scripts dynamiques et le code statique peuvent toutefois être traités de façon très différente. Nous allons examiner précisément les trois approches essentielles : le server-side rendering, le client-side rendering ou la génération de site statique.

Le server-side rendering (« rendu côté serveur »), ou encore le server-side scripting (« script côté serveur »), est une technique utilisée pour développer des sites Web avec des éléments dynamiques et des applications Web. Elle est basée sur l’utilisation de scripts, qui fonctionnent sur le serveur Web en utilisant les langages de scripts appropriés lorsque vous demandez le contenu correspondant dans le navigateur. Toutes les instructions HTML, CSS et JavaScript sont chargées complètement dès la demande initiale.

Les langages de programmation pour le server-side rendering sont les suivants :

• Java
• Ruby
• ASP.NET
• Perl
• PHP
• Python
• Node.js ou JavaScript

Le grand intérêt du SSR est que les pages Web sont préchargées par le serveur. Du point de vue de l’utilisateur, la demande est traitée quasiment sans délai, de sorte que la page appelée s’affiche très rapidement. Cette approche se traduit par une vitesse de chargement optimisée, notamment quand il s’agit de sites Web statiques. Le chargement de page rapide s’accompagne également d’un effet positif sur l’évaluation par les moteurs de recherche, car les robots peuvent capturer les pages plus facilement ou plus rapidement grâce au server-side rendering.

Le server-side scripting exige que le serveur livre des pages HTML préchargées pour chaque demande. Quand un client envoie continuellement d’autres demandes au serveur Web pour envoyer des informations actualisées à l’utilisateur, cela se traduit par une sollicitation élevée de la capacité du serveur. Par conséquent, le SSR ne convient pas aux sites Web qui présentent un grand nombre de demandes ou qui nécessitent un grand nombre d’interactions avec les utilisateurs. Pour de tels projets, le temps de réponse du serveur Web annulerait l’avantage offert par le chargement de page optimisé.

Le langage de client-side scripting le plus important est JavaScript.

Le CSR constitue une approche intéressante, en particulier pour les projets Web présentant beaucoup d’interactions avec les utilisateurs. Si le processus de chargement initial du site Web est relativement long, le rendu des pages suivantes en est d’autant plus rapide. L’expérience utilisateur est beaucoup plus avantageuse qu’avec le server-side rendering, car tous les scripts et les contenus ne doivent pas être chargés d’une seule reprise et entièrement à chaque appel d’une nouvelle page par l’utilisateur.

Étant donné que les scripts sont exécutés dans le navigateur des utilisateurs, l’utilisateur a la possibilité de voir le code source contrairement aux scripts côté serveur.

L’accent mis sur le client-side scripting est associé à deux problèmes décisifs : d’une part, il est plus difficile pour les moteurs de recherche de capturer et d’indexer les pages. Les robots de Google sont en mesure de faire cela, mais les conditions requises pour le SEO ne sont pas remplies dans ce cas, en particulier parce que beaucoup d’autres moteurs de recherche ne sont souvent pas en mesure du tout d’indexer les pages rendues côté client.

D’autre part, le client-side scripting exige la prise en charge de JavaScript par le navigateur. Ceci est généralement le cas, mais différentes extensions de navigateur disponibles peuvent bloquer les scripts car les pop-ups et les outils de traçage qui sont basés sur le rendu côté client peuvent avoir un impact négatif sur les temps de chargement.

Les générateurs de site statique les plus populaires sont par exemple :

• Jekyll
• Hugo
• Next
• Gatsby
• Gridsome
• Nuxt
• Hexo
• Eleventy
• Jigsaw
• Vuepress

La génération de site statique abat ses atouts en particulier dans les projets qui ont beaucoup de contenu qui ne change pas régulièrement. Les exemples typiques à ce sujet sont une page d’accueil personnelle ou un blog qui a typiquement peu de contenu dynamique et qui profite des avantages de la vitesse supérieure de prérendu (c’est-à-dire le préchargement de page) offerts par un générateur de site statique. En outre, les projets SSG offrent peu de surfaces d’attaque car le risque potentiel est limité au simple clic lors de l’appel de la page par le client.

Le prérendu dans le cadre du SSG ne s’accompagne pas uniquement d’une série d’avantages : L’approche se présente comme étant extrêmement peu pratique lorsqu’un projet Web est sujet à des changements réguliers, qu’ils soient de nature technique ou qu’ils touchent au contenu. Les pages statiques du projet Web doivent être à nouveau « préchargées » à chaque modification. Plus le projet est important, plus ce processus de construction prend du temps, ce qui explique pourquoi la génération de site statique ne convient pas aux sites Web comportant un grand nombre de pages statiques.

Le server-side rendering offre une excellente vitesse de chargement de page, qui est en revanche associée à la sollicitation élevée du serveur Web. Le client-side rendering fonctionne inversement et ménage le serveur en affichant la majeure partie de la page dans le navigateur, à condition que l’utilisateur n’ait pas bloqué JavaScript. La génération de site statique protège à la fois le serveur et le client et garantit une livraison rapide du contenu à travers l’approche de prérendu, à moins qu’il ne s’agisse d’un contenu interactif et soumis à des changements constants.

Ainsi, les trois stratégies pour le rendu des projets Web ont toutes leurs avantages et inconvénients. Pesez le pour et le contre quant aux fonctionnalités correspondant le mieux à votre projet afin de trouver la meilleure approche pour votre application Web.