John Mueller recommande le dynamic rendering : chez Search Foresight, on n'approuve pas

Ecrit par
le

En mai dernier, à l’occasion du Google I/O, plusieurs personnes de chez Google ont introduit le concept de « dynamic rendering » comme solution pour les sites utilisant des frameworks javascript (Angular, React, Ember…). C’est clairement une solution poussée par John Mueller.
Cette semaine, Google a publié des recommandations plus détaillées sur le sujet.
Ce qui me donne l’occasion de vous dire ce que j’en pense, à savoir : ce n’est pas nouveau (à part le nom), c’est juste une béquille balourde et sans avenir, et il vaudrait mieux pousser l’hybrid rendering…
Pourquoi cette solution a-t’elle été introduite ?
De plus en plus de sites fonctionnent en laissant le navigateur exécuter un programme en javascript pour générer dynamiquement le HTML qui permettra d’afficher le contenu de la page à l’utilisateur.
Comme les bots de moteurs de recherche sont conçus pour aller chercher le contenu dans le HTML généré côté serveur, cette conception côté client est une catastrophe pour le référencement.
Seul Googlebot arrive à exécuter le javascript pour récupérer ce contenu, mais comme c’est lent, mal aisé, et plein de pièges, le résultat c’est que même avec Google concevoir son site en « Client Side Rendering » reste une très mauvaise idée.
Le « dynamic rendering », ce n’est pas nouveau
Si le terme est nouveau, le concept est ancien. Pour contourner le problème, l’idée c’est de générer deux codes :
• un pour les moteurs de recherche, généré côté serveur par un bout de programme appelé un serveur de prérendition
• un pour les utilisateurs, qui chargera et générera le contenu dans le navigateur de l’utilisateur
Jadis, on faisait cela avec des services comme Prerender.io, aujourd’hui avec Puppeteer et Rendertron, mais c’est toujours le même concept.
L’aiguillage entre les deux versions passe par une détection du user agent. En clair par un cloaking. Une technique théoriquement contraire aux guidelines, mais pas dans ce cas précis, puisque les mêmes contenus sont servis des deux côtés.

Ce qui est nouveau, c’est que Google donne un nom à cette technique, qu’il l’a recommande officiellement, et qu’il explique officiellement que dans ce cas, le cloaking est légitime.
Une solution balourde, et sans avenir
Cela parait magique, sauf que cela ne l’est pas :
• dans la pratique, la moindre erreur dans le système de détection des user agents, et c’est la catastrophe
• si le système tombe en panne, c’est aussi la catastrophe
• si les contenus servis ne sont pas strictement identiques, c’est du cloaking et les pénalités peuvent tomber
• si les contenus sont mis en cache, les contenus dynamiques deviennent statiques, s’ils ne sont pas mis en cache, cela peut être lent et peu performant
• il faut maintenir deux versions du site !
• les développeurs ne savent pas bien recetter ce genre de sites. Il faut un expert SEO bien calé en technique pour le faire
• Et à implémenter, ce n’est pas trivial
Bref, quitte à faire compliqué, autant chercher directement une solution plus sophistiquée mais plus adaptée. C’est à dire aller vers l’équivalent du site responsive vs le site mobile dans le domaine de la rendition : faire un hybrid rendering optimisé pour le SEO.
Pour nous, la bonne solution et la solution durable, c’est de faire de l’hybrid rendering optimisé SEO

La reco de John Mueller, fonctionnant grâce à un cloaking. Elle nécessite de maintenir deux applicatifs fonctionnant en parallèle

L’hybrid rendering appliqué au SEO, c’est simple :
• on continue de générer côté serveur un HTML très dépouillé, qui contient toutes les balises utiles pour le SEO (title, meta desc, rel next/prev, rel canonical etc…) et les contenus textuels indispensables, ainsi que les urls des images ou des ressources que vous voulez voir indexer
• le reste peut être généré côté client
Le principe de l’hybrid rendering. Les bots ont accès facilement à un contenu minimal, généré côté serveur. Côté client, une couche javascript supplémentaire permet des personnalisations, des interactions, et le chargement de contenus supplémentaires non essentiels. Notons que l’on peut faire cela avec ou sans des serveurs de prerendition.

C’est assez simple à faire avec les frameworks javascript modernes. En faisant cela on a le meilleur des demandes : de meilleures performances, des personnalisations poussées côté client, un référencement correct !
Si je désapprouve l’idée de pousser le dynamic rendering, c’est parce qu’elle va à l’encontre des efforts pédagogiques utiles qu’il faudrait faire auprès des développeurs pour qu’ils développent quelque chose de plus performant et plus élégant. Et qu’elle les incite à tomber dans la facilité (mais une facilité apparente, ceux qui ont essayé cette solution savent de quoi je parle).
La solution préconisée par Google fonctionne : vous pouvez l’utiliser. Mais nous vous conseillons de tester dès maintenant des solutions plus efficaces et plus durables, comme l’hybrid rendering optimisé SEO.
La documentation sur le dynamic rendering dans Google Developpers
La doc sur Puppeteer
Et sur Rendertron