Avec du Client-Side Rendering, le chargement initial de notre application se fait en deux temps :

Le bundle correspond à tous les fichiers Html, Javascript et CSS de notre application Angular.

Le bundle est principalement constitué de fichier Javascript car lors du build de notre application, le build transforme tous nos fichiers Typescript et HTML en fichiers Javascript (à l'exception du fichier index.html).

Ce n’est qu’une fois le bundle totalement chargé par le navigateur, que celui-ci exécute le Javascript qui permet de générer la page de l’application.

C’est à ce moment-là que nous allons afficher nos composants Angular à l’utilisateur. Et si nos composants ont besoin de données provenant d’API c’est maintenant que nous allons les charger.

Avec le Client-Side Rendering nous devons d’abord charger le bundle de notre application. Pour cela nous chargeons d’abord le Squelette HTML de notre application qui va nous permettre de charger les autres fichiers du bundle (Javascript et CSS).

Ce n’est qu’une fois les fichiers du bundle chargés, que le rendement de nos pages commencent, c’est ce qu’on appelle le Client-Side Rendering.

Voici le fonctionnement du Client-Side Rendering avec une image :

Le Client Side Rendering est très facile à mettre en place, car activé par défaut sur tous les frameworks modernes de Single Page Application. Néanmoins, il possède deux inconvénients majeurs.

Le premier inconvénient concerne les applications qui ont pour but d’être bien référencées sur les moteurs de recherche. Le problème est que nous envoyons un document HTML vide aux robots et ce document par lui-même est incompréhensible pour les robots.

Le deuxième inconvénient majeur, qui concerne à la fois les applications publiques référençables et les applications privées (Dashboard d’un SAAS, applications internes à une entreprise…), c’est que le temps de chargement initial de notre application est dégradé avec le Client Side Rendering.

Angular permet de mettre en place le Server Side Rendering avec leur librairie nommée Angular Universal, renommée Angular SSR à partir de la version 17 (Le fonctionnement est exactement le même).

Une fois que l’on a installé Angular Universal ou Angular SSR sur notre projet. Lorsque le client arrive sur notre application, le serveur va rendre la page côté serveur (Server Side Rendering), puis l’envoyer au client.

La page rendue côté serveur, envoyée au client, est une page statique qui n’a pas les fonctionnalités d’une Single Page Application. Et il serait dommage de se priver des fonctionnalités des SPA modernes et de revenir aux pages statiques des années 2000.

Pour cela, Angular ne renvoie pas seulement une page statique, mais il fait une transition de la page statique à la Single Page Application en chargeant le bundle en arrière-plan, ce qui est invisible pour l’utilisateur.

Le Server-Side Rendering se déroule donc en deux parties :

Le Server Side Rendering possède deux avantages très importants pour notre application Angular.

Notre serveur renvoie maintenant une page complète aux robots des moteurs de recherche ou des réseaux sociaux.

Ces derniers pourront donc parcourir facilement notre page, cela permettra aux robots d’afficher un titre et une description professionnels dans les résultats de recherche. Mais aussi d’analyser le contenu de notre page pour la proposer de manière pertinente aux utilisateurs des moteurs de recherche.

De plus, cela nous permettra d’avoir des prévisualisations lorsque l’on va partager un lien de notre site sur un réseau social.

Ensuite, de par son fonctionnement, le Server Side Rendering fournit directement au client une page complète en HTML que le client peut afficher directement, sans devoir exécuter du Javascript !

Le Server Side Rendering a malgré tout des inconvénients.

Le premier inconvénient est que le Server Side Rendering a besoin d’un serveur pour fonctionner, ce qui nécessite une infrastructure différente qu’avec le Client Side Rendering. Ce serveur a aussi un coût plus élevé que les CDN qui sont généralement gratuits et qui suffisent pour du CSR.

Le deuxième inconvénient est une contrainte pour les développeurs. En effet, à partir du moment où le SSR est mis en place, notre application va s’exécuter dans deux contextes différents: Le Navigateur et Le Serveur.

Le développeur doit avoir une vision claire de ces deux contextes d’exécution car ils ont chacun des fonctionnalités qui leur sont propres. Par exemple, vous ne pouvez pas utiliser le localStorage côté serveur car c’est une fonctionnalité réservée à l’API du navigateur (Browser API).

C’est pourquoi il est important de faire attention en mettant en place le SSR, sous peine de facilement casser son application.

Ces inconvénients sont principalement des contraintes techniques ou de développement. Les avantages étant orientés résultats (SEO, Performances, Engagement utilisateur…), les avantages du SSR surpassent largement ses inconvénients pour nos projets d’applications web.

Pour conclure, malgré des contraintes techniques et d’infrastructures auxquelles il faut faire attention sous peine de casser notre application, le Server-Side Rendering est indispensable pour réaliser des applications Angular SEO-Friendly et pour obtenir des performances inégalées sur l’ensemble de nos applications Angular.