Les avantages du rendu dynamique sur le référencement
Ces dernières années, les frameworks JavaScript sont devenus de plus en plus populaires, en grande partie grâce à la flexibilité qu'ils offrent. Cependant, malgré ces progrès, lorsque les robots des moteurs de recherche visitent des sites Web basés sur des scripts tels que AngularJS, React, Vue.js ou jQuery, il est possible qu'ils ne "voient" pas le contenu comme le font réellement les navigateurs, ce qui peut entraîner des problèmes d'indexation, voire pire. Il existe cependant quelques moyens de faire en sorte que le site et les robots se parlent mieux, et notamment la technique de rendu dynamique qui semble offrir les meilleures réponses pour traduire le contenu et la structure du site dans la langue préférée des robots d'exploration.
Qu’est-ce que le rendu dynamique ou le rendu dynamique
Le rendu dynamique est un pré-rendu exclusif pour les robots des moteurs de recherche : alors que les visiteurs normaux du site reçoivent le contenu normal rendu côté client, les robots reçoivent une version HTML statique des pages, servie dans le rendu côté serveur.
Il s'agit donc d'un système qui permet une visualisation différente du site en fonction du type d'agent utilisateur qui effectue l'appel, en faisant la distinction entre la version normale du site côté client pour les utilisateurs et celle conçue spécifiquement pour les Googlebots, Bingbots et autres bots, qui peuvent alors accéder, scanner et indexer le contenu sans exécuter de JavaScript.
L'histoire du rendu dynamique
Le concept de rendu dynamique a été officiellement introduit par Google en 2018, même si de nombreux sites adoptaient déjà des techniques similaires par le biais de solutions autoproduites ou en utilisant des logiciels tiers : lors de la conférence Google I/O 2018, précisément, John Mueller a défini le rendu dynamique comme " le principe consistant à envoyer du contenu rendu normal côté client aux utilisateurs et à envoyer du contenu entièrement rendu côté serveur aux moteurs de recherche ".
Par la suite, Bing a également commencé à suggérer cette pratique, prouvant ainsi que le rendu dynamique peut être une solution utile à un problème "historique" tel que le rendu et, en particulier, l'exécution de certains frameworks JavaScript.
Bien que les moteurs de recherche tels que Google et Bing puissent traiter le JavaScript, ils sont en fait limités lorsqu'ils tentent de le faire à grande échelle ; de plus, le robot d'exploration HTML de Google n'est pas toujours capable de traiter le JavaScript, et Googlebot peut donc mettre une telle page construite dans une file d'attente, en attendant que les ressources de rendu soient disponibles pour rendre la page dans son intégralité - et cela est également vrai pour Bingbot.
Comment fonctionne le rendu dynamique
Le rendu dynamique supprime ces limitations, puisqu'il permet aux robots des moteurs de recherche d'accéder au contenu sans avoir à le rendre, surtout lorsqu'il s'agit de sites web de grande taille, car le traitement du JavaScript à grande échelle reste limité par la réduction du nombre de requêtes HTTP.
Les différences avec le rendu côté client
Lors d'un récent exposé au SMX Next, Nati Elimelech (responsable technique du référencement chez Wix) a donné un aperçu du fonctionnement de JavaScript pour le rendu côté client, côté serveur et dynamique, en soulignant certains aspects intéressants rapportés dans cet article de Search Engine Land.
La première étape consiste à comprendre ce qui se passe avec le rendu côté client : lorsqu'un utilisateur clique sur un lien, son navigateur envoie des requêtes au serveur sur lequel le site est hébergé. Dans le cas des frameworks JavaScript, ce serveur répond avec quelque chose de légèrement différent, car il fournit un squelette HTML, c'est-à-dire "juste le HTML de base, mais avec beaucoup de JavaScript, indiquant en gros au navigateur d'exécuter JavaScript pour obtenir tout le HTML important". Le navigateur produit ensuite le HTML affiché, c'est-à-dire le HTML utilisé pour construire la page de la manière dont l'utilisateur final la voit réellement.
Selon M. Elimelech, ce processus rappelle le montage d'un meuble Ikea, car le serveur dit essentiellement au navigateur : "Voici toutes les pièces, voici les instructions, construisez la page", transférant ainsi tout le travail difficile au navigateur plutôt qu'au serveur.
Le rendu côté client peut être excellent pour les utilisateurs, mais il existe des cas où un client n'exécute pas JavaScript et où l'agent utilisateur ne peut donc pas obtenir l'intégralité du contenu de la page : lorsque cela arrive à Googlebot ou à un crawler de moteur de recherche, la situation est évidemment dangereuse pour le référencement, car elle peut empêcher la visibilité de la page dans les SERP.
Les caractéristiques du rendu côté serveur
Pour les clients qui n'exécutent pas JavaScript, il est possible d'utiliser le rendu côté serveur, qui déplace l'exécution de "tout ce JavaScript" vers le serveur ; toutes les ressources sont demandées côté serveur, et le navigateur de l'utilisateur et le robot du moteur de recherche n'ont pas besoin d'exécuter JavaScript pour obtenir le rendu complet du HTML. Par conséquent, le rendu côté serveur peut être plus rapide et moins gourmand en ressources pour les navigateurs.
En utilisant la même analogie que dans l'exemple précédent, Elimelech explique que "le rendu côté serveur est comme fournir aux invités une vraie chaise sur laquelle ils peuvent s'asseoir au lieu de pièces à assembler", et lorsque nous effectuons un rendu côté serveur, nous rendons essentiellement le HTML visible à toutes sortes de bots et de clients, qui seront en mesure de voir "le HTML rendu final" indépendamment des capacités JavaScript.
Comprendre le fonctionnement du rendu dynamique
En ce sens, le rendu dynamique représente "le meilleur des deux mondes" décrits ci-dessus, selon M. Elimelech, car il permet la "transition entre le contenu rendu côté client et le contenu pré-rendu pour des agents utilisateurs spécifiques", comme l'explique également ce diagramme.
Dans ce cas, le navigateur de l'utilisateur exécute JavaScript pour que le HTML s'affiche, mais il bénéficie toujours des avantages du rendu côté client, qui inclut souvent une augmentation perçue de la vitesse. En revanche, lorsque le client est un robot, le rendu côté serveur est utilisé pour servir le HTML entièrement rendu et "voir tout ce qui doit être vu".
Ainsi, les propriétaires de sites sont toujours en mesure de proposer leur contenu, quelles que soient les capacités JavaScript du client. Comme il y a deux flux, ils peuvent également les optimiser individuellement pour mieux servir les utilisateurs ou les robots sans affecter l'autre.
Quels sites ont besoin d'un rendu dynamique
C'est Google lui-même qui décrit quels types de sites "doivent utiliser le rendu dynamique", ce qui est utile pour le contenu public indexable généré avec JavaScript qui change rapidement, ou pour le contenu utilisant des fonctionnalités JavaScript non prises en charge par les robots d'exploration qui sont considérées comme importantes.
Aujourd'hui, les frameworks JavaScript permettent un développement rapide et offrent une meilleure expérience utilisateur car ils offrent de meilleures performances et des fonctionnalités avancées que les frameworks traditionnels, non JavaScript, ne peuvent pas réaliser. Il n'est donc pas surprenant que les très grands sites Web ou les interfaces utilisateur complexes, avec une logique et des fonctionnalités généralement complexes, aient tendance à utiliser des frameworks JavaScript.
De manière plus générale, il est conseillé d'adopter le rendu dynamique si le site est de grande taille et publie du contenu à évolution rapide nécessitant une indexation rapide, comme un site de commerce électronique dont les stocks changent fréquemment ; bien sûr, si le site s'appuie sur des fonctionnalités JavaScript modernes pour générer une partie ou la totalité du contenu et que l'on cherche à assurer une indexation complète des pages, que les utilisateurs peuvent ensuite trouver dans les moteurs de recherche ; si le site s'appuie sur des médias sociaux et des applications de chat qui nécessitent un accès au contenu de la page.
Si nous avons encore des doutes sur la possibilité de mettre en œuvre le rendu dynamique - qui, il convient de le souligner, est une solution alternative pour les crawlers et non une obligation - nous pouvons alors analyser quelles sont les conditions de propriété par rapport à deux questions telles que le budget de crawl et le budget de rendu : si nous avons des problèmes avec ces facteurs, et donc si les robots des moteurs de recherche ne trouvent pas tout le contenu pertinent, le recours au rendu dynamique peut en effet être une solution optimale et plus rapide que la mise en œuvre du rendu côté serveur.
L’importance du rendu dynamique pour le référencement
Il ressort déjà clairement de ce qui a été écrit que le rendu dynamique est essentiellement une solution de référencement JavaScript permettant aux moteurs de recherche de traiter correctement des pages qu'ils ne parviendraient pas à exécuter autrement.
En fait, les robots s'appuient sur des éléments HTML statiques, et non sur des interfaces graphiques évidentes pour les humains : avec le rendu dynamique, les pages côté client sont traduites, rendues entièrement accessibles et servies aux robots des moteurs de recherche dans leur format HTML statique préféré, afin qu'ils puissent immédiatement accéder au contenu, le comprendre et l'indexer pour le trouver dans les recherches.
Comme l'explique Google, le rendu dynamique nécessite que le serveur Web détecte les crawlers (par exemple, avec le contrôle de l'agent utilisateur) ; les demandes des crawlers sont dirigées vers un moteur de rendu, les demandes des utilisateurs sont traitées normalement. Si nécessaire, le moteur de rendu dynamique publie une version du contenu adaptée au robot d'exploration, par exemple une version HTML statique.
Historiquement, les sites Web basés sur JavaScript ont eu du mal à émerger dans la recherche parce qu'ils sont conviviaux mais pas adaptés aux robots ; cela peut également être dû au budget d'exploration limité du robot de recherche de Google et à la nature gourmande en ressources du rendu du contenu JS. En fait, lorsque les robots d'exploration des moteurs de recherche rencontrent un contenu JavaScript lourd, ils doivent souvent l'indexer en plusieurs vagues d'exploration, et ce processus fragmenté entraîne l'absence d'éléments tels que les métadonnées et les balises canoniques, qui sont essentiels à une indexation correcte.
Le rendu dynamique ne crée pas de problèmes de cloaking
La mise en œuvre de cette solution ne pose d'ailleurs aucun problème de compréhension à Google : pendant longtemps, les référenceurs ont craint que le fait de fournir deux pages fondamentalement différentes aux utilisateurs et aux robots ne relève de la définition même du cloaking, une tactique black hat bien connue exposée à des pénalités, mais les orientations officielles du moteur de recherche de Mountain View nous rassurent sur ce point,
"De manière générale, Googlebot ne considère pas le rendu dynamique comme du cloaking", même s'il génère un contenu similaire, peut-on lire dans le document ; de même, la génération de pages d'erreur n'est pas évaluée comme du cloaking, que Googlebot considère comme n'importe quelle autre page d'erreur.
Il en va différemment de l'utilisation du rendu dynamique pour montrer un contenu complètement différent aux utilisateurs et aux robots d'exploration, par exemple "si un site web montre une page sur les chats aux utilisateurs et une page sur les chiens aux robots d'exploration", car cela peut être considéré comme du cloaking.
Mais au-delà de ce dernier exemple, délibérément forcé, il s'agit dans d'autres circonstances de fournir à Google des données similaires sur une page de la manière dont il le souhaite, c'est-à-dire dans un format qu'il peut scanner et indexer rapidement, facilement et à moindre coût.
Comment mettre en œuvre le rendu dynamique
La mise en œuvre autonome du rendu dynamique peut s'avérer difficile, longue et gourmande en ressources, mais elle est néanmoins possible, comme l'explique le guide de Google avec les directives générales à suivre.
Tout d'abord, il est possible d'adopter cette solution pour toutes les pages ou pour des pages individuelles, mais chaque configuration est spécifique et varie en fonction de la mise en œuvre.
Afin d'assurer une approche pratique, Google a mis en place un codelab qui permet de mettre en œuvre le rendu dynamique avec Rendertron, une solution open source basée sur Chromium headless.
- Installez et configurez un moteur de rendu dynamique pour transformer le contenu en code HTML statique, plus facile à utiliser pour les robots d'exploration. Les moteurs de rendu dynamiques les plus courants sont Puppeteer et Rendertrone I.
- Choisissez les agents utilisateurs que vous souhaitez recevoir le code HTML statique et reportez-vous aux détails de la configuration spécifique pour savoir comment mettre à jour ou ajouter des agents utilisateurs. Voici un exemple de liste d'agents utilisateurs courants dans le middleware de Rendertron :
export const botUserAgents = [
"googlebot",
"bingbot",
"linkedinbot",
'mediapartners-google',
] ;
3. Si le pré-rendu ralentit le serveur ou si vous constatez un nombre élevé de demandes de pré-rendu, envisagez de mettre en place un cache pour le contenu de pré-rendu ou vérifiez que les demandes proviennent de robots d'exploration légitimes.
4. Déterminer si les agents utilisateurs demandent un contenu mobile ou de bureau. Utilisez la publication dynamique pour fournir la version de bureau ou mobile appropriée. Il s'agit d'un exemple de la manière dont une configuration peut déterminer si un agent utilisateur demande un contenu de bureau ou mobile :
isPrerenderedUA = userAgent.matches(botUserAgents)
isMobileUA = userAgent.matches(['mobile', 'android'])
if (!isPrerenderedUA) {
} else {
servePreRendered(isMobileUA)
}
Dans cet exemple, utilisez if (!isPrerenderedUA) {…} pour publier le contenu affiché côté client. Utilisez else { servePreRendered(isMobileUA)} pour publier la version mobile si nécessaire.
5. Configurez votre serveur pour fournir du HTML statique aux robots d'exploration sélectionnés. Il existe de nombreuses façons de le faire, en fonction des technologies dont vous disposez ; voici quelques exemples :
- Transférer les demandes des crawlers vers le moteur de rendu dynamique.
- Effectuez le pré-rendu dans le cadre de la procédure de déploiement et demandez au serveur de fournir le HTML statique aux robots d'exploration.
- Intégrez le rendu dynamique dans votre code serveur personnalisé.
- Fournir aux crawlers du contenu statique provenant d'un service de pré-rendu.
- Utilisez un middleware pour votre serveur (par exemple, le middleware rendertron).