JavaScript SEO

Server Side Rendering ou Client Side Rendering ?

javascript seo

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 classé dans les résultats de recherche par les 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, fondamentalement toutes les ressources de votre page sont hébergées sur le serveur. Ensuite, lorsque la page est demandée, le HTML est livré au navigateur et rendu, JS et CSS téléchargés, et le rendu final apparaît à l’utilisateur/lot.

Client Side Rendering (CSR)

Une méthode de rendu plus récente, qui repose sur l’exécution de JS côté client (navigateur) via un framework JavaScript. Essentiellement, le client demandera d’abord le code source qui contiendra très peu de HTML indexable, puis une deuxième demande sera faite pour le fichier.js contenant tout le HTML en JavaScript comme chaînes de caractères.

 

Les principales différences entre la SSR et la 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 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 la SSR et la 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.framework JS et Référencement naturel

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 de la SSR et de la 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.

JS et Référencement naturelPour 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.

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.