La phase de Rendering des moteurs de recherche, c’est quoi ?

Voici par exemple un test réalisé sur le passage de GoogleBot sur un site sur du contenu HTML (les lignes –PHP) et ensuite sur des ressources JS (-JS). On constate ainsi que Google explore bien plus le contenu HTML que les ressources associées :

Fig. 3. Un test réalisé pour SEO KEY sur le nombre de passage de Googlebot en  PHP (HTML) et en JS.

De même, Google ne conserve pas certains éléments lors de son exploration, notamment les cookies et les données locales. Google exclue aussi automatiquement toutes les URL accessibles via autorisations (c'est d'ailleurs pour cette raison que Google ne peut crawler ni indexer un site protégé par une autorisation htaccess/htpasswd).

D'ailleurs, Google le dit clairement : il ne peut pas lire 100% des composants, technologies, outils et langages web. Par exemple, on peut encore et toujours citer le format FLASH qu'il ne peut pas comprendre. Avec l'arrivée de la dernière version de Chromium pour le rendering, il sera capable d'interpréter bien plus de choses. Gardez bien en tête que certains éléments pourraient mal fonctionner pour le moteur de recherche, provoquant ainsi une perte potentielle au niveau du crawl et/ou du positionnement (source).

Google le dit d'ailleurs très bien : son crawl se fait en deux étapes : il va d'abord analyser le contenu HTML, puis il reviendra analyser les ressources lors d'une seconde vague de crawl lui permettant d'obtenir un rendu visuel du contenu :

Fig. 4. Une explication visuelle du crawl et du rendering (Source).

Comment Google évalue le rendering ?

Google va utiliser le rendu visuel d'un contenu pour plusieurs problématiques :

• Tester la compatibilité mobile ;
• Vérifier les techniques de cloaking (afficher pour l'internaute un contenu différent de celui délivré à Google) ;
• Mesurer le temps de chargement.

Mobile

Ce point-là est sans doute le plus connu des référenceurs : Google va chercher à visualiser comme l'internaute vos contenus pour vérifier s'ils sont compatibles mobile ou non : éléments trop rapprochés, trop petits, fenêtre d'affichage mal configurée, etc.

L'outil de test mobile va d'ailleurs faire ce travail de rendering, c'est-à-dire crawler le contenu HTML puis générer le rendu visuel avec les ressources pour vérifier le bon affichage de la page sur des périphériques de petite taille. Dans cet utilitaire, le rendering est affiché après avoir testé un contenu avec l'onglet « Capture d'écran » :

Fig. 5. L'outil de test mobile de Google.

Cloaking

Cet autre intérêt du rendering est assez simple à comprendre : visualiser si le site ne masque pas du contenu à l'internaute tout en l'affichant à Google.

Google peut ainsi détecter certains tentatives de le tromper.

Temps de chargement

Enfin, Google utilise le rendering pour comprendre comment va s'afficher une page, et notamment sa vitesse.

Les ressources d'une page vont augmenter le temps de chargement total. Mais Google va décomposer ce dernier en plusieurs étapes, chacune ayant une importance différente sur la capacité du moteur de recherche à crawler le contenu, sur le ressenti utilisateur et sur le temps réel que mettra la page à être complétement chargée par le navigateur.

On peut ainsi noter différents critères (différentes étapes de chargement) :

• TTFB (Time to First Byte) : c'est le délai entre le clic de l'utilisateur et le temps nécessaire pour que le navigateur reçoive les premières données (c'est-à-dire le contenu HTML) ;
• FP (First Paint) : le temps au bout duquel l'utilisateur commence à voir s'afficher le premier pixel de contenu ;
• FCP (First Contentfull Paint) : le moment où le contenu demandé s'affiche réellement ;
• TTI (Time To Interactive) : le délai pour que l'internaute puisse commencer à interagir avec le contenu de la page.

En réalité, le rendu réel dépend de plusieurs étapes que le navigateur web doit réaliser :

• Le calcul de toutes les fonctions JavaScript (quelles règles vont s'appliquer et à quels éléments) ;
• Le calcul CSS (quelles règles vont s'appliquer et à quels éléments) ;
• Le Layout : le navigateur calcule l'emplacement et l'espace pris par chaque élément (c'est par exemple pour cela qu'une balise <img> doit indiquer sa taille pour ne pas forcer le navigateur à calculer cet aspect);
• Le Paint : Le navigateur va faire le rendu de chaque élément HTML de la page ;
• Le compositing : Le navigateur doit enfin calculer le rendu imbriqué (par exemple un menu « Fixed » qui passe par-dessus le contenu principal).

Cela sous-entend un élément simple : le poids et le nombre de ressources ont un impact sur le temps de chargement et sur le rendu, mais la complexité et le nombre de règles ou d'éléments CSS, JavaScript et HTML sont tout aussi importants (source).

Tester son rendu

Il faut donc s'assurer que le rendu réel de son site respecte certains critères :

• Une bonne compréhension par Google (Google voit exactement ce que verra l'internaute) ;
• Un temps de chargement rapide ;
• Une bonne compatibilité mobile.

Pour tester tout cela, il existe plusieurs méthodes.

Tout d'abord, regardez votre contenu « en cache ». Pour cela, rien de plus simple : faites une recherche Google sur le nom de votre contenu, puis cliquez sur le triangle à droite de l'URL :

Fig. 6. Le bouton en cache de Google.

Dans la Search Console de Google, vous pouvez aussi utiliser le bouton « Tester l'URL en direct ». En faisant cela, vous pouvez alors voir la capture d'écran s'afficher, ainsi que tous les autres problèmes techniques détectés sur la page.

Fig. 7. Le rendu en direct de l'URL dans la Search Console.

Nous en avons déjà parlé, mais vous pouvez aussi tester le rendering avec l'outil de compatibilité mobile de Google.

L'outil PageSpeed Insight est également une très bonne façon de tester le rendering. Là encore, on peut visualiser le rendu de la page mais aussi décomposer le temps de chargement selon les critères précédemment cités (TTFB, First Paint, etc.) : https://developers.google.com/speed/pagespeed/insights/?hl=fr

Fig. 8. Google Page Speed Insight permet de tester le rendering de son contenu.

Enfin, vous pouvez tout simplement utiliser Chromium, donc le navigateur Chrome, pour avoir le rendu visuel tel qu'utilisé actuellement par Googlebot.

JS Rendering

La montée en puissance de JavaScript

Le JavaScript prend une place de plus en plus importante dans les développements web, comme par exemple la montée en puissance de langages comme React ou encore Vue.js. Ces technologies, méthodes et librairies permettent de concevoir des sites et des applications web de façon différente, souvent de façon plus moderne, plus interactive ou encore plus réactive.

Le problème est que Google a beaucoup de mal parfois à interpréter le JavaScript. Il peut ainsi ne pas du tout le comprendre, ou alors l'analyser de façon partielle. Il est ainsi indispensable de pouvoir faire comprendre à Google tout contenu généré entièrement ou partiellement par ce langage web.

Lorsque l'on conçoit la quasi-totalité de son site en JS, il faut donc tester le rendu réel pour Google afin de s'assurer du crawl, de l'indexation puis du positionnement des différents contenus. Il existe ainsi deux façons de générer du contenu pour l'utilisateur (et le moteur de recherche) :

• Le Client Side Rendering ;
• Le Server Side Rendering.

Client Side Rendering

Dans ce cas de figure, l'internaute télécharge une ressource JavaScript qui va ensuite faire un appel au serveur pour générer le contenu final. Lors du téléchargement initial, le rendu de la page est vide et le contenu est injecté a postériori.

Fig. 9. Le fonctionnement du Client Side rendering.

Pour rappel dans l'image précédente et dans l'image suivante, le FCP est le premier rendu visuel du contenu tandis que le TTI est le moment où ce dernier est enfin interactif (c'est-à-dire utilisable par l'internaute).

La prinicpale problématique que cela pose est que lors du chargement initial, Google téléchargera un contenu quasiment vide. Il ne verra le contenu réel que plus tard lors de la seconde vague de crawl dont nous avons déjà parlé par rapport aux outils de test.

Server Side Rendering

Dans ce cas de figure, l'internaute fait un appel au serveur, et c'est ce dernier qui va générer grâce à JavaScript le rendu réel. Lors du TTFB, on est donc capable de télécharger d'ores et déjà le contenu réel, et non pas la librairie qui permettra de le générer.

Fig. 10. Le fonctionnement du Server Side Rendering (source).

Google Préconise fortement de faire du Server Side Rendering car cela lui permet de s'assurer de comprendre réellement le contenu, et de ne pas en avoir une version tronquée ou vide : « Server-rendering is often chosen for delivering a "complete looking" experience crawlers can interpret with ease » (source).

En d'autres termes, la solution de base est de faire faire le travail à votre serveur directement, et non pas au navigateur de l'internaute.

Dynamic Rendering

Il existe aussi une solution située entre les deux : avoir un site en JS (Client Side rendering ou Server Side Rendering) mais fournir une variante à Google. Dans ce cas de figure, il faut détecter la présence de GoogleBot et utiliser une solution qui va générer le rendu HTML pour le moteur de recherche.

Fig. 11. Le principe du Dynamic Rendering.

On peut le faire par exemple avec RenderTron : https://webmasters.googleblog.com/2019/01/dynamic-rendering-with-rendertron.html

Remarque importante : attention cependant aux outils servant à générer l'HTML pour les robots. Par exemple, dans sa dernière version, Rendertron a retiré GoogleBot de sa liste de robots par défaut à prendre en compte : https://github.com/GoogleChrome/rendertron/commit/30446bd7caae87de9fcd8c8263b588c350130852

En réalité, il existe plusieurs grands types de solutions pour faire du rendu JS de contenu :

• Créer un site classique et ne faire appel au JS que pour de l'amélioration continue (dans ce cas on revient vers un site classique mais parfaitement compréhensible par Google) ;
• Créer un snapshot HTML (une « capture d'écran ») : on génère un contenu HTML grâce au JS. Le rendu pour Google et l'utilisateur devient alors équivalent à un site statique. On utilise pour cela un serveur HeadLess, comme le fait la solution précédente RenderTron ;
• Utiliser une solution qui va faire un pré-rendu de vos contenus, comme Prerender.io (https://prerender.io/documentation) ou encore Brombone (https://www.brombone.com/).

Quel choix faire ?

D'un point de vue SEO, la seule chose importante est de pouvoir fournir le contenu HTML complet le plus rapidement possible à l'utilisateur, et donc aux robots des moteurs de recherche. Quelle que soit la solution choisie, vous DEVEZ tester le rendu final pour Google en utilisant les différentes méthodes de ce début d'article.

Entre du Server Side Rendering et du Client Side Rendering, il existe même des variantes, chacune ayant des atouts les unes par rapport aux autres à différents niveaux (temps de chargement, complexité, réactivité, etc.) :

Fig. 12. Les avantages et inconvénients des différentes générations de contenus en JS.

Dans la figure 12, SSR signifie Server Side Rendering et CSR Client Side Rendering : https://developers.google.com/web/updates/2019/02/rendering-on-the-web

Conclusion

Google s'améliore fortement depuis plusieurs mois pour mieux interpréter les sites qu'il va crawler : prise en compte de la compatibilité mobile, du temps de chargement et des dernières innovations avec l'utilisation de la dernière version de Chromium.

Malgré tout cela, Google peut vite se retrouver perdu lorsqu'il fait le rendering de votre contenu. Il peut parfois mal comprendre votre CSS ou votre JavaScript, lui donnant ainsi une vision tronquée et erronée de vos différentes URL.

Tant que possible, essayez de réduire votre dépendance au JavaScript, en fournissant un contenu HTML simple, rapide et compatible mobile. Et n'oubliez pas : testez, testez et testez encore !