5
minutes
Mis à jour le
21/1/2025


Share this post

Explorez les méthodes de rendering (CSR, SSR, SSG) et leur impact sur le SEO, la performance et l'expérience utilisateur. Découvrez comment les approches hybrides modernes, portées par Angular 19, révolutionnent le développement web pour allier dynamisme et référencement.

#
Angular
Léo Merran
Tech Lead

Dès mes débuts dans le web, je me suis toujours demandé comment le code que j'écrivais en Angular pouvait générer des barres de navigation, des boutons ou des modales sur les sites web. En tant que développeurs, nous connaissons les mots « client », « serveur » ou encore « API », mais par quelle magie interviennent-ils dans la génération de mon application ? En gagnant en expérience, j'ai appris les notions de bundle et de transpilation qui m'ont permis de comprendre que mon code était converti dans un langage moins « sexy », de plus bas niveau, pour que le navigateur puisse le lire et l'interpréter.

En parallèle de cela, j'ai commencé à m'intéresser au SEO, une notion avec une connotation marketing assez poussée qui me permettrait de mettre en avant mes applications sur internet. J'ai dès lors cherché des moyens de booster le référencement. Un seul objectif : que pouvais-je mettre en place en tant que développeur pour aider Google (ou tout autre navigateur) à mettre en avant mon site ?

Une notion clef : le rendering

Avant toute chose, revenons à l'origine de ce qui permet à l'utilisateur de voir l’application : le rendering. Si on cherche à construire une définition digeste, on pourrait dire « étape cruciale qui transforme des données et du code en une interface utilisateur visible et utilisable ». On comprend que sans cela... pas de site web ! Il y a donc une carte à jouer là-dessus, car c'est grâce à cela qu'on passe de notre code à l'interface utilisateur. Pour comprendre son impact sur le SEO, il faut comprendre comment ce dernier fonctionne.

Mieux comprendre le SEO

Si on se penche sur le fonctionnement du référencement Google, le robot va télécharger les pages en navigant sur les différents liens, parcourir le contenu et détecter toutes les mises à jour. Une fois ce processus abouti, il ajoute un index aux pages qui va permettre de les référencer et donc booster leur SEO. Plusieurs facteurs permettent d'obtenir un meilleur classement :

  • La pertinence du contenu ;
  • Le responsive (rendre l’application lisible aussi bien sur un ordinateur qu’un téléphone) ;
  • La vitesse de chargement ;
  • La sécurité ;
  • ...

L'un des freins majeurs pour le robot Google est le JavaScript bloquant, qu'on retrouve via des frameworks comme React ou Angular. En d'autres termes, le JavaScript généré par la transpilation est plus difficile à comprendre par le robot. La conséquence : aucune indexation sur ces pages !

Le CSR, l’ennemi du bot Google

Avec cette notion en main, on comprend que si vous avez un contenu dynamique (qui change suivant vos actions), vous pénaliserez le SEO de votre site. Depuis 2010 approximativement, avec l'avènement des frameworks JavaScript modernes comme AngularJS et React et les Single Page Applications (SPA), le Client Side Rendering (CSR) a vu le jour. Son objectif : permettre des applications réactives et interactives pour améliorer l'expérience utilisateur.

Mais allons plus profondément dans le fonctionnement du CSR. Il repose sur le principe suivant :

  1. Le chargement initial : lorsqu'un utilisateur accède à une page web, le serveur (le S3 CloudFront d’Amazon par exemple) ne renvoie qu'un fichier HTML minimal, accompagné d'un ou plusieurs fichiers JavaScript et CSS. Ce fichier HTML contient une structure de base et un élément racine (souvent une simple « div ») où l'application sera chargée.
  2. Exécution côté client : le navigateur exécute les fichiers JavaScript, qui gèrent la construction du DOM. Cela signifie que tout le contenu visible par l'utilisateur est généré dynamiquement par le JavaScript.
  3. Interactions utilisateur : une fois chargée, l'application est capable de réagir immédiatement aux actions de l'utilisateur (clics, saisie, navigation). Cela crée une expérience fluide et sans rechargement complet de la page.
  4. Récupération des données : les échanges de données entre le frontend et le backend sont gérés via des requêtes asynchrones (AJAX ou API REST/GraphQL). Le JavaScript met à jour le DOM avec les nouvelles données, sans recharger toute la page.

Ici, comme le contenu est chargé dynamiquement a posteriori, il y a souvent une page de chargement (ou écran blanc). Et ce fonctionnement réactif peut diminuer les performances sur les appareils moins puissants. En croisant ce processus avec le mode de fonctionnement du robot Google, on comprend facilement que le CSR est pénalisant pour les sites ayant un fort enjeu de SEO. Mais comme ce dernier est le plus répandu dans les frameworks modernes, on le retrouve un peu partout.

Le SSR, le SEO au détriment de la performance

Le parfait opposé du CSR est le Server Side Rendering (SSR). Au lieu de laisser le contenu se générer dans le fichier HTML vide grâce au JavaScript, le serveur va directement envoyer le fichier HTML généré. On se retrouve donc dès le début avec une version finale de notre fichier. Si nous regardons plus profondément son mode de fonctionnement, nous retrouvons ce principe :

  1. Requête initiale : lorsqu'un utilisateur accède à une URL, une requête est envoyée au serveur.
  2. Rendu côté serveur : le serveur exécute le code de l'application pour générer dynamiquement un fichier HTML complet avec tout le contenu nécessaire.
  3. Envoi au client : le fichier HTML prégénéré est renvoyé au navigateur, qui affiche rapidement le contenu. Le JavaScript se charge ensuite pour gérer uniquement les interactions utilisateur.

Derrière chaque action utilisateur changeant le contenu, une requête au serveur va se déclencher. Celui-ci recalculera la version actualisée du HTML pour la renvoyer au client. L'énorme avantage d'un point de vue SEO est que le contenu des pages est statique, donc l'indexation se fait efficacement. De plus, le fait que le client n'ait pas à gérer le rendu rend l'application plus adaptée à tout type d'appareil, car la charge est portée par le serveur, qui se retrouve alors nettement augmentée. Le principal frein à cette solution est qu'elle nécessite un coût plus élevé. Certains frameworks ont vu le jour comme Next.js (dérivé de React) ou Angular Universal (dérivé d'Angular).

Le SSG, la solution des sites vitrines

Le dernier système existant est le Static Site Generation (SSG). On sort un peu du cadre du rendering car ici, il n’y a pas de notion de transpilation à proprement parler, donc pas de code Javascript exécuté. Dès la phase de build, donc au lancement même de l’application, tous les fichiers vont être générés de façon statique. De ce fait, l’utilisateur navigera simplement d’une page à l’autre sans notion de dynamisme. Le principe se découpe de la sorte :

  1. Build statique : lors de la phase de construction, toutes les pages de l’application sont générées en fichiers HTML statiques ;
  2. Hébergement : ces fichiers statiques sont déployés sur un serveur ou un CDN, prêts à être livrés directement aux utilisateurs ;
  3. Requêtes utilisateur : lorsqu’un utilisateur accède à une page, le serveur renvoie simplement le fichier HTML prégénéré, sans traitement supplémentaire ;

Le gros avantage ici, on le comprendra, est que l’indexation est très simple. Il n’y a aucun chargement et aucun changement et donc un contenu analysable rapidement. D’un point de vue performance UX, on est sur la solution la plus optimisée.

Le problème majeur reste le contenu statique car on décorrèle totalement l’utilisateur du contenu affiché et son actualisation ne se fait qu’à chaque phase de build. Il faut donc redéployer une nouvelle version de l’application pour le changer (d'où son utilisation majeure pour de simples sites vitrines).

L’hybride : au service des performances

En survolant les trois méthodes de rendering, j’ai rapidement compris que j’obtiendrai un site :

  • dynamique et performance mais mal référencé (CSR) ;
  • dynamique et bien référencé mais avec des lenteurs (SSR) ;
  • rapide et bien référencé mais avec un contenu static (SSG) ;

Et dans mon objectif de fournir des produits dynamiques et avec un bon SEO… rien ne correspondait à mon besoin.

Ce système hybride, qui représente l’avenir du développement web, a été popularisé dès 2016 avec des frameworks comme Next.js (React) et Nuxt.js (Vue.js). Cependant, peu de frameworks avaient pleinement embrassé cette approche hybride jusqu’à récemment, et Angular n’offrait pas cette flexibilité avant ses versions 18 et 19.

Pour l’instant les frameworks les implémentent de façon très distincte. Si on se penche sur React, ce sera une définition au niveau des composants, permettant ainsi d’avoir une granularité très fine, là où Angular va poser cette définition au niveau des routes. L’avantage de ce dernier, de mon point de vue, est qu’il nous force à être rigoureux dans l’organisation même de notre architecture front et l’imbrication des composants entre eux.

À vous de jouer : êtes-vous prêt à combiner dynamisme et SEO dans vos projets ?

Quelques références