Une application Angular utilise par défaut le Client-Side Rendering (CSR) pour rendre ses pages. Mais il existe deux techniques qui apportent des avantages par rapport au CSR.
Avec Angular SSR (Angular Universal), nous avons la possibilité de rendre notre application avec du Server-Side Rendering (SSR), mais aussi avec du Static Site Generation (SSG) ou Prerendering.
Nous allons voir dans cet article la différence entre ces deux techniques et quand privilégier l’une ou l’autre.
Si vous préférez le format vidéo, voici la vidéo YouTube correspondante à cet article.
Les bénéfices de fournir des pages complètes
Avec le SSR ou le SSG, nous fournissons directement une page complète à l'utilisateur. Cela apporte beaucoup d’avantages notamment en termes d’expérience utilisateur, de performances et de SEO.
- Performances et Expérience Utilisateur: La page étant complète elle peut être affichée instantanément à l'utilisateur.
- SEO: La page étant complète, les robots comprennent directement la page et peuvent la parcourir pour facilement l’indexer et référencer notre site.
Pour comprendre en profondeur le fonctionnement du Server-Side Rendering et la différence avec le Client-Side Rendering, allez voir l'article Comprendre le Server Side Rendering avec Angular.
Fonctionnement du SSR et du SSG
La différence de fonctionnement entre le Server-Side Rendering et le Static Site Generation se trouve dans le moment où l'on génère nos pages.
Server-Side Rendering = à la demande
Le Server-Side Rendering permet de rendre nos pages côté serveur à chaque requête du client, à la demande.
Le rendement de la page se fait côté serveur à chaque requête du client
Lorsque le client veut accéder à notre site, celui-ci envoi une requête au serveur. Le serveur génère/rend la page sur le moment, puis l'envoi au client.
Static Site Generation = lors du build
Le Static Side Generation nous permet de générer nos pages lors du build de l'application lorsqu'on exécute la commande "ng build".
La page générée est ensuite réutilisée à chaque requête du client.
Le serveur renvoi une page déjà prérendue au client
Avantages et inconvénients des deux techniques
Maintenant comparons les avantages et les inconvénients entre ces deux techniques.
Avantages et inconvénients du SSR
Le Server-Side Rendering a des avantages et des inconvénients par rapport au Static Site Generation.
Les avantages :
- Avantage n°1 : Grâce au SSR notre serveur fournit toujours la dernière version d’une page (Exemple: si un article a été modifié sur un blog, l’utilisateur aura directement la nouvelle version sans rien faire).
- Avantage n°2 : En rendant les pages à la demande, notre serveur peut rendre des pages avec du contexte de l’utilisateur (Exemple: générer une page avec des informations spécifiques à l'utilisateur connecté).
Les inconvénients :
- Inconvénient n°1 : Générer une page à la demande nécessite une logique serveur, on ne peut donc pas héberger notre application sur un simple CDN, un serveur est nécessaire.
- Inconvénient n°2 : Le rendement des pages côté serveur peut prendre du temps, ce qui va dégrader légèrement le Time To First Byte (TTFB).
Avantages et inconvénients du SSG
Le Static Site Generation a aussi des avantages et des inconvénients par rapport au Server-Side Rendering.
Les avantages :
- Avantage n°1 : Nos pages étant prérendue au moment du build, si notre application possède 100% de ses pages en SSG, nous pouvons l’héberger sur un CDN.
- Avantage n°2 : Notre serveur ou le CDN fournissant directement la page prérendue, cela améliore le Time To First Byte (TTFB).
Les inconvénients :
- Inconvénient n°1 : Si une modification a lieu sur une de vos pages, vous devez relancer un build de l’application pour que les pages prérendues contiennent les modifications. Cela peut être fastidieux sur des sites avec des pages qui changent régulièrement.
- Inconvénient n°2 : Impossible d’avoir du contexte utilisateur, si vous avez une page qui contient des données spécifiques à l’utilisateur connecté, vous ne pourrez pas rendre cette page car lors du SSG vous ne possédez pas les informations de l’utilisateur.
Démonstration des avantages et inconvénients
Une image valant 1000 mots, voici des images pour bien assimiler les avantages et les inconvénients des deux techniques.
Contexte utilisateur
Avec le Server-Side Rendering nous pouvons générer une page contenant du contexte utilisateur.
Page rendue côté serveur avec du contexte utilisateur grâce au SSR (Impossible à réaliser avec du SSG)
Ci-dessus, nous voyons dans l'onglet Preview que la page générée possède plusieurs contexte utilisateur : Le bouton "Se déconnecter", le lien "Mes favoris" et les Articles favoris de l'utilisateur.
Générer une page avec du contexte utilisateur est impossible avec du SSG.
Time To First Byte
Avec le SSR nous rendons nos pages à chaque requête du client et ce rendement des pages peut prendre du temps.
Avec du Static Site Generation, la page étant déjà rendue, nous pouvons la fournir directement au client sans avoir un "temps de rendement".
Différence du temps de réponse du serveur entre le SSR (101ms) et le SSG (37ms)
Ci-dessus, nous voyons que la page rendue en SSG est renvoyée plus rapidement au client, en 37ms contre 101ms pour le SSR.
Mise à jour de la page
Démonstration avec le SSG ❌
Un des plus gros inconvénient du Static Site Generation est la nécessité de rebuild notre application si nous voulons appliquer des modifications à nos pages.
Avec du SSG, la page modifiée en base de données n'est pas mis à jour
Ci-dessus, nous voyons que le titre de la page n'est pas mis à jour malgré la modification du titre en base de données ❌
Démonstration avec le SSR ✅
Et le plus gros avantage du Server Side Rendering est qu'il fourni toujours des pages à jour au client.
Le SSR permet de toujours renvoyer une page à jour au client
Ci-dessus, nous voyons que le titre de la page est directement mis à jour après la modification du titre en base de données ✅
Lequel choisir entre le SSR et le SSG ?
Voyons maintenant quelle technique utiliser entre le SSR et le SSG.
SSR = Le choix qui fonctionne toujours
Le SSR rendant les pages à la demande, celui-ci est compatible avec l’ensemble de vos pages, qu’elles soient statiques ou dynamiques, qu’elles contiennent du contexte utilisateur ou non.
C'est le choix qui fonctionnera toujours et qui vous apportera tous les bénéfices de rendre vos pages côté serveur.
SSG = Site statique / site vitrine
Le SSG va être parfaitement adapté pour les sites qui possèdent uniquement du contenu statique, comme par exemple, le site vitrine d’un artisan avec des pages qui ne changent que très rarement.
Cela vous permettra d’héberger facilement votre site sur un CDN (généralement gratuit) plutôt que de payer pour un serveur.
SSR et SSG en même temps
Enfin, il faut savoir que nous pouvons utiliser les deux techniques sur nos projets. Nous pouvons avoir par exemple un site avec 80% de SSR pour les pages dynamiques et 20% de SSG pour des pages statiques.
Exemples de sites adaptés au SSR et au SSG
Voici des exemples concrets qui peuvent vous aider à choisir entre le SSR et le SSG pour vos projets.
- Ecommerce = SSR : Beaucoup de pages dynamiques, les produits et les pages étant modifiés régulièrement.
- Site Vitrine d'une entreprise = SSG : Les pages sont toutes statiques et réexécuter un ng build lors d'une rare modification n'est pas gênant.
- Dashboard avec des KPIs = SSR : Le dashboard doit afficher les dernières informations qui changent en temps réel.
- Blog = SSR et/ou SSG : Cela dépend si les pages changent régulièrement (Page d'accueil, page d'un article) et si il y'a du contexte utilisateur (Formulaire de connexion pour accéder à des articles privés ou en favoris).
- Réseau social = SSR : Les pages doivent afficher les derniers posts en temps réel.
Conclusion
Nous avons vu que le SSR et le SSG ont chacun leurs avantages et inconvénients.
Le Server-Side Rendering est le choix par défaut qui fonctionnera sur toutes vos applications et le Static Site Generation sera choisi seulement dans des cas précis.
Abonnez vous pour ne pas rater les nouveaux articles !
© Gaëtan Rouziès - Tous Droits Réservés