Qu'est-ce que le Client-Side Rendering (CSR) ?

Le Client-Side Rendering (CSR) est une méthode de rendu web où le navigateur de l'utilisateur télécharge initialement une page HTML minimale et exécute des scripts JavaScript pour construire et afficher le contenu complet de la page. Le CSR permet d'améliorer l'interactivité et la réactivité de l'application en permettant des mises à jour dynamiques sans recharger complètement la page.

Pourquoi le CSR peut-il être problématique pour le référencement naturel (SEO) ?

Le CSR peut poser des problèmes pour le SEO car il nécessite l'exécution de JavaScript pour afficher le contenu de la page. Les moteurs de recherche comme Google doivent donc exécuter ce JavaScript pour voir et indexer le contenu. Ce processus peut être plus lent et susceptible d'erreurs, ce qui peut retarder l'indexation et potentiellement nuire au classement de la page dans les résultats de recherche. C'est donc l'opposé du SSR qui consiste à ce que l'exécution soit faite côté serveur, et que le Googlebot ou le navigateur de l'internaute reçoit un document HTML explicite et complet.

Dans quels cas le Client-Side Rendering (CSR) est-il préférable au Server-Side Rendering (SSR) ?

Le CSR est généralement préférable pour les applications web complexes de type SaaS (Software as a Service) où l'interactivité et la réactivité sont cruciales. Dans ces cas, le CSR permet une meilleure expérience utilisateur en permettant des mises à jour dynamiques et rapides de l'interface sans rechargement complet de la page. Cependant, pour les sites web visant à optimiser leur SEO, le SSR ou le pre-rendering sont souvent des choix plus efficaces.

Tout ce qu'il faut savoir au sujet du CSR en SEO

Résumer cet article avec :

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

Exemple du site Spirit Airlines sans désactivation du Javascript

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.

Exemple du site Spirit Airlines en désactivant le Javascript (ce que voit Google de prime abord)

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 :

Tout ce qu'il faut savoir au sujet du CSR en SEO

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

Questions fréquentes

Les articles en lien avec ce sujet

Plus d'articles SEO

La newsletter SEO pour les malins