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 HTML.
( à savoir un placeholder qui est un fichier ne contenant qu'une balise div avec 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 ( moteurs de recherches ).
Notre page ne contient au premier rendu qu’un placeholder (fichier ne contenant qu'une balise div avec un id="root" ). 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.
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.
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ée.
Chaque fois que l'utilisateur accède à une autre page du site Web, un nouveau fichier HTML est chargée. Cela génère une large utilisation du serveur, qui accumule des informations sur toutes les activités des utilisateurs.
‘Static Rendering’
Le rendu statique se produit au moment de la construction et offre un premier rendu rapide, en supposant que la quantité de JavaScript côté client soit limitée.
Ce premier rendu est dit 'Contentful' et 'Time To Interactive'.
Contrairement au rendu côté 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.
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.
‘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 peuvent retarder le 'Time To First Byte' 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.
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?
Cela dépend une nouvelle fois du genre d'application que vous voulez développer.
‘Prerendering’
Le pré-rendu est un processus de préchargement de tous les éléments de la page en vue d'un robot d'exploration Web pour le voir.
Un service de pré-rendu interceptera une demande de page pour voir si l'agent utilisateur qui visualise votre site est un bot. Si c'est le cas, alors le middleware de pré-rendu enverra une version en cache de votre site à afficher avec tout ( JavaScript, images, etc ) qui sera rendu statiquement. Sinon, alors tout est chargé normalement.
Le pré-rendu n'est utilisé que pour optimiser l'expérience des bots uniquement.
'Static Rendering' VS 'Prerendering'
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 le premier rendu 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.
‘Rehydration’ ou 'Universal Rendering'
Souvent appelée rendu universel, cette approche tente de fluidifier les compromis entre le rendu côté client et le rendu serveur en faisant les deux.
Les demandes de navigation telles que les chargements de pages complètes ou les recharges sont gérées par un serveur qui rend l'application au format HTML, puis le JavaScript et les données utilisés pour le rendu sont incorporés dans le document résultant. Lorsqu'il est mis en œuvre avec soin, cela permet d'obtenir un premier rendu rapide, tout comme le rendu du serveur, puis «reprend» en effectuant un nouveau rendu sur le client en utilisant une technique appelée 'Rehydratation'. Il s'agit d'une nouvelle solution, mais elle peut présenter des inconvénients de performances considérables.
Le principal inconvénient de cette méthode est qu'il peut y avoir un impact négatif significatif sur 'Time To Interactive', même s'il améliore 'First Paint'.
Les pages SSR semblent souvent chargées et interactives de manière trompeuse, mais ne peuvent pas réellement répondre aux entrées tant que le JS côté client n'est pas exécuté et que les gestionnaires d'événements ont été attachés. Cela peut prendre quelques secondes, voire quelques minutes sur mobile.
Peut-être avez-vous vécu cela vous-même : pendant un certain temps après qu'il semble qu'une page se soit chargée, cliquer ou appuyer ne fait rien.
Un autre problème de cette méthode : une application pour le prix de deux..
Performance et expériences utilisateurs
‘Time to First Byte’
Souvent noté (TTFB), c'est le temps entre le clic sur un lien et le premier bit de contenu entrant.
‘First Paint’
Aussi noté (FP), c'est la première fois qu'un pixel devient visible pour l'utilisateur.
‘First Contentful Paint’
Noté (FCP), c'est le moment auquel le contenu demandé (corps de l'article, etc.) devient visible.
‘Time To Interactive’
Souvent noté (TTI), cela correspond au moment auquel une page devient interactive (événements câblés, etc.).
Sources
https://developers.google.com/web/updates/2019/02/rendering-on-the-web
Veille Technologique 2020
- Année : VT2020
- Sujet : Website Rendering Types
- Slides : Presentation
- Demo :
- Auteur : Vernet Maxime