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'
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'
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 une première peinture rapide, une première peinture 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 plusieurs CDN pour tirer parti de la mise en cache périphérique.
Les solutions de rendu statique sont de toutes formes et tailles. Des outils comme Gatsby sont conçus pour donner aux développeurs l'impression que leur application est rendue dynamiquement plutôt que générée lors d'une étape de construction. D'autres comme Jekyll et Metalsmith embrassent leur nature statique, offrant une approche davantage axée sur les modèles.
L'un des inconvénients du rendu statique est que des fichiers HTML individuels doivent être générés pour chaque URL possible. Cela peut être difficile, voire impossible, lorsque vous ne pouvez pas prédire ce que seront ces URL à l'avance, ou pour les sites avec un grand nombre de pages uniques.
Les utilisateurs de React peuvent être familiarisés avec Gatsby, l'exportation statique Next.js ou Navi - tous ces éléments facilitent la création à l'aide de composants. Cependant, il est important de comprendre la différence entre le rendu statique et le prérendu: les pages rendues statiques sont interactives sans qu'il soit nécessaire d'exécuter beaucoup de JS côté client, tandis que le prérendu améliore la première peinture ou la première peinture contentieuse d'une application à page unique qui doit être démarrée sur le client pour que les pages soient vraiment interactives.
Si vous ne savez pas si une solution donnée est un rendu statique ou un pré-rendu, essayez ce test: désactivez JavaScript et chargez les pages Web créées. Pour les pages rendues statiquement, la plupart des fonctionnalités existeront toujours sans l'activation de JavaScript. Pour les pages pré-rendues, il peut toujours y avoir des fonctionnalités de base comme des liens, mais la plupart de la page sera inerte.
Un autre test utile consiste à ralentir votre réseau à l'aide de Chrome DevTools et à observer combien de JavaScript a été téléchargé avant qu'une page ne devienne interactive. Le prérendu nécessite généralement plus de JavaScript pour devenir interactif, et ce JavaScript a tendance à être plus complexe que l'approche d'amélioration progressive utilisée par le rendu statique.
‘Server-Side’ VS ‘Static’
Le rendu du serveur n'est pas une solution miracle - sa nature dynamique peut entraîner des frais généraux de calcul importants. De nombreuses solutions de rendu de serveur ne sont pas vidées tôt, peuvent retarder le TTFB ou doubler les données envoyées (par exemple, l'état en ligne utilisé par JS sur le client). Dans React, renderToString () peut être lent car il est synchrone et monothread. Obtenir le «bon» rendu du serveur peut impliquer de trouver ou de créer une solution pour la mise en cache des composants, la gestion de la consommation de mémoire, l’application de techniques de mémorisation et bien d’autres problèmes. Vous traitez / reconstruisez généralement la même application plusieurs fois - une fois sur le client et une fois sur le serveur. Ce n'est pas parce que le rendu du serveur peut faire apparaître quelque chose plus tôt que vous avez moins de travail à faire.
Le rendu du serveur produit du HTML à la demande pour chaque URL, mais peut être plus lent que la simple diffusion de contenu rendu statique. Si vous pouvez ajouter les étapes supplémentaires, le rendu du serveur + la mise en cache HTML peuvent réduire considérablement le temps de rendu du serveur. L'avantage du rendu du serveur est la possibilité d'extraire plus de données «en direct» et de répondre à un ensemble de requêtes plus complet que ce qui est possible avec le rendu statique. Les pages nécessitant une personnalisation sont un exemple concret du type de requête qui ne fonctionnerait pas bien avec le rendu statique.
Le rendu du serveur peut également présenter des décisions intéressantes lors de la construction d'une PWA. Est-il préférable d'utiliser la mise en cache du service worker sur une page entière ou simplement de restituer des éléments de contenu individuels sur le serveur?
‘Rehydration’
‘Prerendering’
Performance et expériences utilisateurs
‘Time to First Byte’
‘First Paint’
‘First Contentful Paint’
‘Time To Interactive’
Sources
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