Com­pa­rai­son entre le client-side rendering, le server-side rendering et la gé­né­ra­tion de site statique

Chaque fois que vous visitez un site Web, votre na­vi­ga­teur doit assurer le rendu de cette page afin de pouvoir la présenter de manière at­trayante et fournir le degré d’in­te­rac­ti­vité que vous souhaitez. Selon l’approche de pro­gram­ma­tion adoptée pour le projet Web, les scripts dy­na­miques et le code statique peuvent toutefois être traités de façon très dif­fé­rente. Nous allons examiner pré­ci­sé­ment les trois approches es­sen­tielles : le server-side rendering, le client-side rendering ou la gé­né­ra­tion 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é­ve­lop­per des sites Web avec des éléments dy­na­miques et des ap­pli­ca­tions Web. Elle est basée sur l’uti­li­sa­tion de scripts, qui fonc­tion­nent sur le serveur Web en utilisant les langages de scripts ap­pro­priés lorsque vous demandez le contenu cor­res­pon­dant dans le na­vi­ga­teur. Toutes les ins­truc­tions HTML, CSS et Ja­vaS­cript sont chargées com­plè­te­ment dès la demande initiale.

Les langages de pro­gram­ma­tion pour le server-side rendering sont les suivants :

• Java
• Ruby
• ASP.NET
• Perl
• PHP
• Python
• Node.js ou Ja­vaS­cript

Le grand intérêt du SSR est que les pages Web sont pré­char­gées par le serveur. Du point de vue de l’uti­li­sa­teur, la demande est traitée quasiment sans délai, de sorte que la page appelée s’affiche très ra­pi­de­ment. Cette approche se traduit par une vitesse de char­ge­ment optimisée, notamment quand il s’agit de sites Web statiques. Le char­ge­ment de page rapide s’ac­com­pagne également d’un effet positif sur l’éva­lua­tion par les moteurs de recherche, car les robots peuvent capturer les pages plus fa­ci­le­ment ou plus ra­pi­de­ment grâce au server-side rendering.

Le server-side scripting exige que le serveur livre des pages HTML pré­char­gées pour chaque demande. Quand un client envoie con­ti­nuel­le­ment d’autres demandes au serveur Web pour envoyer des in­for­ma­tions ac­tua­li­sées à l’uti­li­sa­teur, cela se traduit par une sol­li­ci­ta­tion élevée de la capacité du serveur. Par con­sé­quent, le SSR ne convient pas aux sites Web qui pré­sen­tent un grand nombre de demandes ou qui né­ces­si­tent un grand nombre d’in­te­rac­tions avec les uti­li­sa­teurs. Pour de tels projets, le temps de réponse du serveur Web an­nu­le­rait l’avantage offert par le char­ge­ment de page optimisé.

Le langage de client-side scripting le plus important est Ja­vaS­cript.

Le CSR constitue une approche in­té­res­sante, en par­ti­cu­lier pour les projets Web pré­sen­tant beaucoup d’in­te­rac­tions avec les uti­li­sa­teurs. Si le processus de char­ge­ment initial du site Web est re­la­ti­ve­ment long, le rendu des pages suivantes en est d’autant plus rapide. L’ex­pé­rience uti­li­sa­teur est beaucoup plus avan­ta­geuse qu’avec le server-side rendering, car tous les scripts et les contenus ne doivent pas être chargés d’une seule reprise et en­tiè­re­ment à chaque appel d’une nouvelle page par l’uti­li­sa­teur.

Étant donné que les scripts sont exécutés dans le na­vi­ga­teur des uti­li­sa­teurs, l’uti­li­sa­teur a la pos­si­bi­lité de voir le code source con­trai­re­ment 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 con­di­tions requises pour le SEO ne sont pas remplies dans ce cas, en par­ti­cu­lier 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 Ja­vaS­cript par le na­vi­ga­teur. Ceci est gé­né­ra­le­ment le cas, mais dif­fé­rentes ex­ten­sions de na­vi­ga­teur dis­po­nibles 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 char­ge­ment.

Les gé­né­ra­teurs de site statique les plus po­pu­laires sont par exemple :

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

La gé­né­ra­tion de site statique abat ses atouts en par­ti­cu­lier dans les projets qui ont beaucoup de contenu qui ne change pas ré­gu­liè­re­ment. Les exemples typiques à ce sujet sont une page d’accueil per­son­nelle ou un blog qui a ty­pi­que­ment peu de contenu dynamique et qui profite des avantages de la vitesse su­pé­rieure de prérendu (c’est-à-dire le pré­char­ge­ment de page) offerts par un gé­né­ra­teur 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’ac­com­pagne pas uni­que­ment d’une série d’avantages : L’approche se présente comme étant ex­trê­me­ment peu pratique lorsqu’un projet Web est sujet à des chan­ge­ments réguliers, qu’ils soient de nature technique ou qu’ils touchent au contenu. Les pages statiques du projet Web doivent être à nouveau « pré­char­gées » à chaque mo­di­fi­ca­tion. Plus le projet est important, plus ce processus de cons­truc­tion prend du temps, ce qui explique pourquoi la gé­né­ra­tion de site statique ne convient pas aux sites Web com­por­tant un grand nombre de pages statiques.

Le server-side rendering offre une ex­cel­lente vitesse de char­ge­ment de page, qui est en revanche associée à la sol­li­ci­ta­tion élevée du serveur Web. Le client-side rendering fonc­tionne in­ver­se­ment et ménage le serveur en affichant la majeure partie de la page dans le na­vi­ga­teur, à condition que l’uti­li­sa­teur n’ait pas bloqué Ja­vaS­cript. La gé­né­ra­tion 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 in­te­rac­tif et soumis à des chan­ge­ments constants.

Ainsi, les trois stra­té­gies pour le rendu des projets Web ont toutes leurs avantages et in­con­vé­nients. Pesez le pour et le contre quant aux fonc­tion­na­li­tés cor­res­pon­dant le mieux à votre projet afin de trouver la meilleure approche pour votre ap­pli­ca­tion Web.