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.
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 ?
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.
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 :
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 !
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 :
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 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 :
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 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 :
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).
En survolant les trois méthodes de rendering, j’ai rapidement compris que j’obtiendrai un site :
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 ?