Le Client-Side Rendering (CSR) est l’une des deux méthodes de rendering (que certains traduisent par “rendition” ou par affichage) qui existent sur l’internet, la deuxième méthode étant le SSR (Server-Side Rendering).
C’est un concept particulièrement important dans le référencement naturel et en particulier pour les professionnels qui travaillent sur du Javascript SEO.
Définition du Client-Side Rendering
Avant tout, il faut comprendre comment marche la navigation d’un internaute ou d’un crawler sur le web.
Lorsque vous, en tant qu’utilisateur, vous cliquez sur un lien pour accéder à une page et son contenu, de nombreuses étapes se succèdent.
- Votre navigateur envoie une requête au serveur sur lequel est localisé la ressource (la page quoi) ;
- Le serveur vérifie que votre user agent soit bien autorisé (cf. fichier robots.txt) ;
- S'il l’est, le serveur récupère l’ensemble des ressources attachées aux documents (le fichier HTML, la feuille de style CSS, et les autres ressources possibles notamment le Javascript).
Après cette étape, il y a deux “voies” possibles.
La voie du pre-rendering : c’est à dire que le serveur fait (ou a fait dans le cas du SSG) la “gymnastique” de compilation des fichiers et envoie directement à votre navigateur un fichier HTML complet et explicite.
Ou la voie du CSR : Dans ce cas particulier, le serveur envoie à votre navigateur l’ensemble des fichiers puis votre navigateur s’occupe d’exécuter le Javascript qui va permettre de modifier le DOM afin de rendre l’affichage et l’interactivité de la web app possible.
Pourquoi mentionner le DOM ? le Document Object Model (DOM) est une interface qui définit la structure d’une page web et précise la manière dont cette page peut être modifiée par des scripts externes (comme le CSS ou le JS). Vous le retrouvez notamment dans l’onglet “Éléments” de la console du navigateur Chrome.

Pourquoi le CSR est déconseillé en SEO
Pour reprendre l’explication plus haut, lorsqu’un crawler explore le web, il agit à peu de choses près comme un internaute visitant des pages web. Donc, le Googlebot envoie une requête à un serveur, et le serveur lui répond avec des fichiers.
Dans le cas du SSR, le Googlebot reçoit un fichier HTML complet et explicite. Il en extrait des liens internes et externes qu’il va ensuite explorer, puis passe le fichier html à son indexer qui va l’interpréter sans aucune difficulté.
Dans le cas du CSR, le Googlebot reçoit un fichier HTML avec peu de contenu car celui-ci nécessite l’exécution du Javascript pour être “rempli”. Pour ce faire, le Googlebot envoie les fichiers à une autre “brique” de l’indexer qu’on appelle le WRS (Web Rendering Service). Cependant, ce WRS a déjà une file d’attente de fichiers à compiler, donc cela prendra plusieurs heures voire plusieurs jours avant qu’il soit capable de compiler les fichiers. Mais ce n’est pas tout, il se peut que le WRS commette des erreurs dans sa manière de générer le DOM en exécutant votre Javascript, erreurs qui peuvent impacter ce que l’indexer perçoit de votre page.
Je vous mets ci-dessous un exemple qui concerne le site Américain Spirit Airlines.
Si vous accédez au site internet “normalement” en tant qu’internaute, voici ce que vous voyez

Maintenant, si vous désactivez le javascript de votre navigateur (en utilisant l’extension Chrome Web Developer par exemple), vous aurez une idée de ce que peut voir Google s’il n’exécute pas (ou très mal) le Javascript.

Et oui, c’est une page blanche. Notez comment le <app-root> reste vide dans ce second exemple. L’application n’a pas démarré puisque celle-ci requiert du Javascript et ainsi la page reste blanche.
Vous pouvez prendre une page produit sur le site de Nike et comparer la différence de contenu entre la version avec Javascript et celle sans et vous verrez qu’elle est incroyable.
Bref, vous l’aurez compris, le processus de découverte, d’exploration et d’indexation est plus lourd, plus long, et plus prône à générer des erreurs dans le cas du CSR.
L’alternative au CSR ? Le SSR !
En fait, c’est un abus de langage. La véritable alternative c’est le pre-rendering. Et parmi le pre-rendering, on retrouve des solutions telles que le SSR, le SSR avec réhydratation ou encore le SSG. Je vous invite à consulter mon article dédié SSR SEO : le guide complet pour les marketeurs et les développeurs.
En conclusion
Le CSR est une méthode de rendering très répandue sur l’internet et notamment pour des web apps de type SaaS.
Le problème du CSR se situe lorsqu’on utilise cette méthode pour des web apps (telles que des sites web, des blogs) qui ont vocation à se positionner sur des moteurs de recherche. En effet, aujourd’hui seuls Bing et Google sont capables de compiler du Javascript dans leur processus d’indexation, et même s’ils en sont capables j’observe des problèmes de performance SEO comparés à des sites avec du pre-rendering.
Donc oui au CSR pour de la web app type application SaaS, non au CSR si votre site web est développé dans un objectif d’acquisition de trafic via du SEO. Même si Google prétend être capable d’exécuter le Javascript, croyez-en mon expérience depuis 2017 en Javascript SEO.
N'hésitez pas à consulter mes autres articles sur le Javascript SEO :




Partagez votre avis, vos questions, vos recommandations ci-dessous