Pourquoi le rendu côté serveur

Le rendu côté serveur (SSR) exécute votre application Angular sur le serveur afin de produire du HTML entièrement rendu pour chaque requête. Le navigateur reçoit immédiatement un balisage utile au lieu d’une coquille vide.

Une application entièrement rendue côté client (CSR) fournit un fichier index.html presque vide ainsi que du JavaScript. Les utilisateurs et les robots d’exploration voient une page blanche jusqu’à ce que le paquet soit téléchargé, analysé et exécuté. Le SSR comble cette lacune du premier affichage.

De nombreux robots d’exploration et robots d’aperçu des liens lisent le HTML initial. Avec le SSR, le titre, les balises meta et le contenu de la page sont présents dans la réponse, ce qui améliore l’indexation et les aperçus enrichis sur les réseaux sociaux.

Comme le serveur envoie du HTML rendu, le navigateur affiche le contenu plus tôt. Cela améliore le First Contentful Paint (FCP) et la vitesse perçue, en particulier sur les réseaux ou les appareils lents.

Le SSR peut améliorer le Largest Contentful Paint (LCP) en fournissant le contenu principal dans le HTML initial plutôt qu’après l’exécution du JavaScript. De bons indicateurs améliorent à la fois l’expérience utilisateur et le classement dans les résultats de recherche.

Lorsqu’une personne partage un lien, les plateformes récupèrent l’URL et lisent les balises meta Open Graph et Twitter dans le HTML. Le SSR garantit que ces balises correspondent à la page réelle et produit ainsi des cartes d’aperçu exactes.

Après avoir fourni le HTML, la même application démarre côté client et prend en charge l’interactivité. Ce processus s’appelle l’hydratation ; Angular moderne réutilise le HTML du serveur au lieu de le générer à nouveau.

Le SSR ajoute des coûts et de la complexité côté serveur : un environnement d’exécution Node, la gestion du code réservé au serveur ou au navigateur, ainsi que le rendu au moment de la requête. Évaluez ces éléments par rapport aux gains de référencement et de performances pour votre application.

Les pages publiques riches en contenu et sensibles au référencement (sites marketing, blogs et catalogues de commerce en ligne) en bénéficient le plus. Les tableaux de bord internes protégés par une connexion tirent souvent peu d’avantages du SSR.

Pour les routes principalement statiques, le prérendu (SSG) génère le HTML au moment de la compilation et offre des avantages similaires à ceux du SSR sans serveur actif. Angular prend en charge simultanément le SSR et le prérendu.

Angular moderne fournit un SSR officiel via @angular/ssr, avec le générateur d’application, l’hydratation complète du DOM et des modes de rendu propres à chaque route. Le SSR est ainsi bien plus simple qu’avec les anciennes configurations Angular Universal.

Vérifiez votre compréhension de l’importance du SSR.

Vous avez appris pourquoi le SSR est important : du HTML réel dès la première requête améliore le référencement, les aperçus sur les réseaux sociaux, le FCP et le LCP. Il ajoute un coût côté serveur, convient aux pages publiques riches en contenu, complète le prérendu et Angular moderne le prend directement en charge via @angular/ssr.