VT2020-Website-Rendering-Types-Fiche

En tant que développeurs, nous sommes souvent confrontés à des décisions qui affecteront toute l'architecture de nos applications. L'une des principales décisions que les développeurs Web doivent prendre est de savoir où mettre en œuvre la logique et le rendu dans leur application. Cela peut être difficile, car il existe un certain nombre de façons différentes de créer un site Web.

Types de rendus

Il existe un certain nombre de façons différentes de créer un site Web. Nous allons les présenter ici et dans certains cas les comparer.

'Server-Side Rendering'

Server-Side Rendering

Le contenu HTML est à chaque fois renvoyé par le serveur.

Dans un premier temps, le JavaScript est rendu côté serveur et la réponse envoyée au navigateur contient directement tout le code HTML généré.
La page est donc visible dès la première requête au serveur mais elle n’est pas encore interactive.

Dans un second temps, le navigateur télécharge le JS puis l’exécute afin de rendre la page interactive.

'Client-Side Rendering'

Client-Side Rendering

Au chargement de la page, le serveur envoie une réponse HTML au navigateur qui contient littéralement très peu de code HTM ( à savoir un placeholder qui est un fichier ne contenant qu'une balise div contenant un id="root" ).

Dans cette réponse se trouvent aussi les scripts JavaScript à télécharger. Le navigateur commence donc à les télécharger. En attendant, la page ne contient pas plus de code HTML, c’est une page blanche. Une fois le JavaScript chargé, il est exécuté par le navigateur et génère le HTML qui va être affiché par le navigateur : la page est visible et intéractive.

Cela dit on relève problèmes majeurs avec ce procédé. Il est expliqué dans la partie suivant.

‘Server-Side’ VS 'Client-Side’

Voici donc les deux problèmes mageurs du rendu côté client (CSR) :

Problème n°1 : Pas de HTML donc des mauvais résultats SEO. Notre page ne contient au premier rendu qu’un placeholder. Les robots des moteurs de recherche ne lisent donc aucun contenu sur la page.

Cela signifie que Facebook, Twitter, Bing, Google, tous les moteurs de recherche ne peuvent donc pas décrire notre site web d’un point de vue SEO. En effet, les robots des résultats de recherche lisent très mal le JavaScript.

Ils rencontrent aussi des difficultés pour explorer les autres pages car le routing de l’application est en JavaScript. De plus, lire du JavaScript consomme beaucoup plus de ressources que de lire du HTML, les coûts sont donc plus élevés. C’est pourquoi les sites rendus côté client sont crawlés moins régulièrement. Indexer une SPA est donc soit impossible soit compliqué, et les performances SEO qui en résultent sont mauvaises.

Problème n°2 : Un temps de chargement initial élevé Comme nous l’avons dit, pendant que le navigateur télécharge puis exécute le JavaScript, l’utilisateur ne voit qu’une page blanche. Celle-ci peut être remplacée par une page de chargement. Toutefois, l’utilisateur ne voit rien d’autre et doit attendre la fin du téléchargement.

Ce phénomène peut prendre une dimension encore plus importante dans les cas où :

   • L’utilisateur a une connexion internet lente, en particulier sur mobile 
   • L’utilisateur utilise un appareil peu puissant, par exemple un appareil mobile d'ancienne génération. 
   • L’utilisateur utilise une vieille version peu performante d’un navigateur 

Dans un souci de délivrer une expérience optimisée pour tous les utilisateurs, sur tous les appareils et à tout moment, ce problème prend une dimension critique.

Cependant quelle que soit la vitesse du premier accès en rendu côté serveur (ssr), le reste de l'expérience peut être affecté. Chaque fois que l'utilisateur accède à une autre page du site Web, un nouveau fichier HTML est chargé. Cela génère une large utilisation du serveur, qui accumule des informations sur toutes les activités des utilisateurs.

La différence principale du rendu côté serveur d’un point de vue utilisateur est donc de réduire le phénomène de page blanche, en affichant immédiatement tout le contenu statique de la page. De plus, les requêtes effectuées côté serveur sont souvent plus stables et plus rapides.

‘Static Rendering’

Le rendu statique se produit au moment de la construction et offre un premier rendu rapide ( un premier rendu dit 'Contentful' et 'Time To Interactive' ) en supposant que la quantité de JS côté client est limitée. Contrairement au rendu de serveur, il parvient également à atteindre un temps de premier octet toujours rapide, car le HTML d'une page n'a pas besoin d'être généré à la volée. En règle générale, le rendu statique signifie la production d'un fichier HTML distinct pour chaque URL à l'avance. Les réponses HTML étant générées à l'avance, les rendus statiques peuvent être déployés sur

Sources

https://spanceptvideomarketing.com/client-side-rendering-vs-server-side-rendering-which-one-is-better/

https://developers.google.com/web/updates/2019/02/rendering-on-the-web

Veille Technologique 2020

• Année : VT2020
• Sujet : Website Rendering Types
• Slides :
• Auteur : Vernet Maxime