JavaScript SEO

Server Side Rendering ou Client Side Rendering ?

Qu’est-ce que le JavaScript SEO ?

Au fond, le référencement JavaScript est essentiellement la pratique consistant à s’assurer que le contenu d’une page (exécutée via JS) est correctement rendu, indexé et finalement positionné dans les pages de résultats des moteurs de recherche. Ceci est particulièrement pertinent en raison de la popularité croissante du rendu côté client et des sites Web construits sur des frameworks JavaScript. Avant de continuer, examinons les deux principaux types de rendu :

Server Side Rendering (SSR)

La méthode de rendu traditionnelle où, fondamentalement, toutes les ressources JS de votre page sont hébergées et exécutées par votre serveur. Ensuite, lorsque la page est demandée, l’HTML est livré au navigateur et rendu en amont, JS et CSS déjà exécutés. Le rendu final apparaît donc à l’utilisateur sans que le navigateur ait eu à exécuter de Script. L’avantage est que le client (moteur de recherche ou utilisateur) bénéficie d’un rendu direct et complet, mais cela consomme énormément de ressources serveur.

Client Side Rendering (CSR)

C’est une méthode de rendu plus récente, qui repose sur l’exécution de JS côté client (navigateur) via un framework JavaScript. En appelant un document HTML, le client ne recevra de la part du serveur, qu’un code succin et incomplet. C’est le navigateur qui va, dans un second temps télécharger les éléments JS afin reconstruire et rendre un doc HTML indexable comportant toutes les ressources, notamment textuelles. Le rendering est donc effectué par votre machine et non le serveur, ce qui a pour avantage de ne consommer que très peu de ressources serveur.

Les principales différences entre le SSR et le CSR ?

Le rendu côté serveur (SSR) peut être un peu plus rapide à la demande initiale, tout simplement parce qu’il ne nécessite pas autant de déplacements et d’aller-retour vers le serveur. Cependant, la performance ne s’arrête pas là, elle dépend aussi de quelques facteurs supplémentaires. Tout cela peut se traduire par des expériences utilisateur très variées :

La vitesse Internet de l’utilisateur qui fait la demande
Combien d’utilisateurs actifs accèdent au site à un moment donné ?
L’emplacement physique du serveur
L’optimisation des pages en termes de vitesse

Le rendu côté client (CSR), par contre, est plus lent à la demande initiale parce qu’il fait plusieurs allers-retours vers le serveur. Cependant, une fois ces demandes satisfaites, CSR offre une expérience fulgurante via le framework JS.

Voici une métaphore utile qui décrit la différence entre le SSR et le CSR :

« Avec le rendu côté serveur, chaque fois que vous voulez voir une nouvelle page web, vous devez aller la chercher, c’est comme si vous alliez au supermarché à chaque fois que vous voulez manger. Avec le rendu côté client, vous allez une fois au supermarché et passez 45 minutes à marcher pour acheter un tas de nourriture pour le mois. Puis, quand tu veux manger, tu ouvres le frigo. »

Adam Zerner

Avec la popularité croissante des frameworks JavaScript, tels que Angular, React et Vue.js, les développeurs peuvent désormais fournir des pages Web plus efficacement et fournir une expérience utilisateur incroyablement rapide pour démarrer. Cependant, s’il n’est pas planifié avec soin, ce bond en avant dans l’efficacité peut se faire à un prix SEO substantiel à l’heure actuelle.

Avant de continuer, prenons rapidement un peu de recul et couvrons la différence entre la façon dont JavaScript était généralement utilisé dans le passé et comment il a changé dans le présent.

Dans le passé, JS était principalement utilisé pour ajouter différents niveaux d’interaction à une page Web. Ceci a été réalisé en référençant des bibliothèques JS comme JQuery. Parce que le JS manipulait simplement le contenu HTML déjà présent dans le code source, il y avait peu de problèmes avec les moteurs de recherche pour découvrir et indexer le contenu. Cependant, avec certains des frameworks JS et CSR d’aujourd’hui, tout à coup, le code source d’une page Web est pratiquement vide et le contenu exclusivement rendu par l’exécution JS du côté client.

Dans le passé, JS était principalement utilisé pour ajouter différents niveaux d’interaction à une page Web. Ceci a été réalisé en référençant des bibliothèques JS comme JQuery. Parce que le JS manipulait simplement le contenu HTML déjà présent dans le code source, il y avait peu de problèmes avec les moteurs de recherche pour découvrir et indexer le contenu. Cependant, avec certains des frameworks JS et CSR d’aujourd’hui, tout à coup, le code source d’une page Web est pratiquement vide et le contenu exclusivement rendu par l’exécution JS du côté client.

Cela complique les choses pour les moteurs de recherche, mais Google est vraiment le seul moteur de recherche aujourd’hui qui est même un peu posé pour le gérer. Aucun des autres moteurs de recherche n’a les capacités de rendu JS employées par Google actuellement. Cela signifie que même si votre contenu CSR peut être indexé par Google, il n’est probablement pas indexé par d’autres moteurs de recherche.

Comment Google gère-t-il le JavaScript Rendering aujourd’hui ?

La première vague demande le code source, parcourt et indexe tout HTML et CSS présent, ajoute tout lien présent à la file d’attente et télécharge les codes de réponse des pages.

Sur un site rendu côté client cependant, il n’y a pratiquement rien que Google puisse indexer dans le code source pendant cette première vague.

La deuxième vague peut se produire quelques heures ou même quelques semaines plus tard, Google revient à la page lorsque des ressources supplémentaires sont disponibles pour rendre et indexer entièrement le contenu généré par JS.

Cela signifie que là où, comme dans SSR, il n’y a généralement pas de problème avec le délai de rendu de Google parce que le contenu est tout dans le code source et indexé pendant la première vague. Dans CSR, où le contenu indexable n’est révélé qu’au rendu, ce délai considérable peut signifier que le contenu peut ne pas être indexé ou apparaître dans les résultats de recherche pendant des jours, voire des semaines.

Pourquoi Google lutte-t-il avec le rendu JavaScript ?

Pourquoi Google a-t-il besoin d’un processus en deux étapes pour rendre les contenu en JavaScript ?

Il est important de se rappeler que le rendu JavaScript à l’échelle est très exigeant en ressources. Cela signifie une augmentation substantielle de la consommation d’électricité, de la puissance des processeurs, une réduction potentielle du taux de rampement et plus encore. Cela se traduit à son tour par une augmentation significative du coût monétaire.

JavaScript exige que le moteur de recherche passe plus de temps à faire du rendu, ce qui signifie des dépenses d’électricité supplémentaires, une demande accrue de CPU ainsi qu’un ralentissement spectaculaire du processus de rendu standard. Maintenant, imaginez chaque site sur le Web en utilisant la CSR directe et vous pouvez commencer à comprendre pourquoi le rendu JavaScript à une telle échelle peut être problématique pour les moteurs de recherche qui essaient de fonctionner efficacement.

Ce travail supplémentaire pour rendre JS n’est pas unique aux seuls moteurs de recherche cependant, vous pouvez également constater les effets de l’augmentation de la contrainte de rendu JS sur vos propres périphériques ainsi :

Pour les postes de travail des utilisateurs (ordinateurs de bureau, portables, mobiles, tablettes, etc.), les capacités de leur CPU peuvent être très différentes pour chaque type d’appareil, par exemple, le CPU d’un appareil mobile aura généralement plus de mal avec un site lourdement chargé en JS qu’avec un ordinateur de bureau.
Le JavaScript lourd peut consommer une grande quantité de CPU, de mémoire et même d’autonomie de batterie d’un appareil. Cela montre à quel point l’impact de JavaScript peut avoir un impact sur les performances, allant de Googlebot jusqu’à l’appareil mobile de l’utilisateur.
Par conséquent, c’est toujours une bonne idée de tester les pages en utilisant l’onglet « Performance » de Chrome Dev Tools pour tester la performance d’exécution. Ici, vous pouvez tester les performances de l’appareil via le « throttling » réseau, qui permet de simuler les différentes capacités CPU des appareils mobiles, les différentes vitesses Internet, et la façon dont vos pages sont traitées à ces spécifications.

Quelles sont les implications SEO du SSR et du CSR ?

Pour le rendu côté serveur (SSR), tout le contenu HTML est présent dans le code source, ce qui signifie que le moteur de recherche peut le demander, le parcourir et l’indexer immédiatement. Il en résulte un temps d’apparition plus rapide et un classement plus rapide dans les résultats de recherche.

Pour le rendu côté client (CSR), le HTML devant être indexé n’est révélé que lorsque le JS est entièrement rendu côté client. Ainsi, avec le système à deux vagues actuellement utilisé par Google, il peut s’écouler de quelques heures à une semaine avant que le contenu puisse être parcouru, indexé et commencé à être classé dans les résultats de recherche.

Ce délai ne tient pas compte non plus de l’existence d’une logique de hiérarchisation des priorités à l’œuvre du côté de Google. Si c’est le cas, dans certains cas, cela pourrait prendre encore plus de temps.

Quelle est la solution la plus SEO Friendly ?

Alors que Google travaille actuellement à la mise à jour de ses capacités de rendu JavaScript pour les futures versions de Chrome, cette vague chronologie n’aide pas les webmasters d’aujourd’hui qui luttent pour que leur contenu SSR ne soit pas indexé. Ceci ne tient pas compte non plus de tous les autres moteurs de recherche qui ne sont même pas à la hauteur des capacités de rendu JS actuelles de Google.

Il existe deux solutions principales à ce problème :

Pré-rendering JS :

Il s’agit essentiellement d’écouter et d’envoyer un snapshot HTML pur au robot du moteur de recherche lorsqu’il demande votre page. Ainsi, l’utilisateur peut toujours profiter des vitesses rapides fournies par CSR, tout en fournissant aux moteurs de recherche le contenu HTML nécessaire à l’indexation et au classement de vos pages.

Voici un retour d’expérience sur l’un de mes clients, doyouno.fr, qui en amont avez opté pour une solution full client side rendering, dans le cas d’une PWA (Progressive Web App). Nous étions confronté à un gros souci d’interprétation des contenus qui n’était pas rendu, ni valorisé au sein des pages. Le moteur ne voyait qu’un template vide si l’on en crois les rendus de test mobile, de micro-données, et le cache de Google. De fait aucune performance n’est possible sans une bonne compréhension des contenus dispensés via un framework Angular.

C’est alors nous décidons de déployer un pré-rendering à destination des moteurs. L’avantage étant de ne pas surcharger de serveur en exécutant tout les scripts JS coté serveur. En effet, le pre-rendering s’apparente (fortement) à du cloacking et va opérer une différence de traitement entre les divers user-agent(s) préalablement identifiés : Google Bot Mobile, Google Bot Desktop, Web User (Chrome, Mozzila)… on pourrait cependant croire que cette technique initialement Black-Hat serait d’office pénalisée, mais cette fois la guideline sort tout droit des tiroirs de Google.

En somme, nous allons servir une page rendue coté serveur à ces user-agent afin de leur donner toutes les infos nécessaire à une bonne indexabilité des pages sans qu’il n’aient à exécuter les scritp JS, de fait le moteur obtient d’office une version clean de la pages et est plus à même de crawler d’autres pages du site car il économise un temps de rendu précieux. Votre performance SEO en est donc améliorée.

JavaScript isomorphe :

Recommandée par Google, cette option consiste à ce que le client et les moteurs de recherche reçoivent une page pré-rendue de contenu HTML indexable à la charge initiale (agissant essentiellement comme SSR). Toutes les fonctionnalités de JS sont ensuite superposées afin d’offrir une performance rapide côté client. Il fonctionne aussi mieux pour les utilisateurs et les robots des moteurs de recherche, cependant, il y a quelques problèmes flagrants avec le rendu Isomorphic :

La mise en œuvre peut être délicate, et de nombreux développeurs ont du mal à l’accepter. Elle peut également être très coûteuse étant donné les ressources nécessaires à une mise en œuvre réussie. Des recherches approfondies devraient être menées pour déterminer la meilleure façon d’exécuter la SSR avec votre cadre de travail de l’EM.

Conclusion

Il est clair que l’utilisation de JavaScript pour améliorer l’interactivité, l’expérience utilisateur et le rendu des pages Web ne fait que croître. C’est donc à nous, en tant que SEOs, de mieux communiquer ces considérations avec nos développeurs lorsque nous abordons de nouveaux projets.

Google, et les moteurs de recherche en général, continueront à améliorer leur capacité à rendre les pages JS à l’échelle. Cependant, cela révélera sans aucun doute de nouveaux obstacles à surmonter à mesure que les techniques de développement continuent à progresser. Les idées couvertes dans cet article sont conçues pour vous donner un aperçu du JavaScript SEO et les problématiques qu’il engendre.