Les défis posés par le JavaScript pour un crawler

Depuis son apparition dans les années 90, JavaScript est devenu un pilier du web moderne, permettant d’apporter dynamisme et interactivité aux pages des sites web. Cette évolution a entraîné l’essor des moteurs JavaScript, des navigateurs et des runtimes permettant d’exécuter ce langage en dehors du navigateur.

Toutefois, cette omniprésence de JavaScript représente un défi pour le SEO et, en particulier, les robots d’indexation (crawlers). Les moteurs de recherche doivent être capables d’analyser et d’indexer correctement les sites dont le contenu des pages repose sur l’exécution de scripts. Or, le rendu JavaScript est coûteux en ressources et n’est pas toujours parfaitement pris en charge par les crawlers. Lors du crawl d’un site, il est crucial de suivre tous les liens/urls générés dynamiquement par le code JS. Certains sites chargent en effet du contenu uniquement après l’exécution de scripts, modifiant ainsi les urls accessibles aux robots.

Dans cet article, nous explorerons l’évolution des moteurs JavaScript, leur rôle dans le référencement naturel, ainsi que les solutions disponibles pour récupérer un DOM post-exécution JavaScript de manière efficace.

Table of Contents

Historique des navigateurs et des moteurs JavaScript

Le web a évolué rapidement depuis ses débuts dans les années 90, et avec lui, les navigateurs et leurs moteurs JavaScript. Voici un bref aperçu de cette évolution :

1994 : Netscape Navigator (Mosaic Netscape) et la naissance de JavaScript et de SpiderMonkey | A la naissance des premiers navigateurs, les pages web manquent encore cruellement de dynamisme et d’interactivité. Pour Netscape, il est alors primordial de conserver cette position dominante (avec près de 80% des parts de marché) face à un Microsoft qui veut lui aussi conquérir le web. En 1995, pour le compte de Netscape, Brendan Eich crée Mocha, qui sera ensuite renommé LiveScript et enfin JavaScript. C’est également la naissance du moteur SpiderMonkey, écrit en C à l’origine puis réécrit en C/C++ par la suite, encore utilisé aujourd’hui par Firefox.
1996 : JScript (Microsoft) | Microsoft réplique avec JScript, une version alternative de JavaScript pour Internet Explorer 3, entraînant alors une fragmentation des standards. Cette rivalité aura un impact majeur sur la façon dont les sites sont développés et rendus par les navigateurs. Microsoft s’apprête alors à détenir plus de 90% des parts de marché en 2000.
2000 : Konqueror et l’introduction de KHTML et KJS (KDE) | Le navigateur Konqueror, développé par le projet KDE, introduit KHTML et KJS, qui donneront naissance à WebKit et JavaScriptCore, encore utilisés aujourd’hui.
2000 : Chakra (ancien) (Microsoft) | Moteur JavaScript d’Internet Explorer 9 à 11, différent de celui de Edge.
2002 : Safari et JavaScriptCore (Apple) | Apple lance Safari en basant son moteur de rendu sur un fork de KHTML, baptisé WebKit, et utilise JavaScriptCore dérivé, lui aussi, de KJS. Rappelons tout de même, qu’avant Safari, MacOS embarquait une version spécifique d’Internet Explorer que Microsoft délaissait au fil des années jusqu’à son arrêt en 2003.
2008 : Chrome et l’ère de V8 | Google révolutionne le web avec V8, un moteur optimisé pour la rapidité et la compilation Just-In-Time (JIT). Chrome est basé sur WebKit, lui-même basé sur KHTML, mais a évolué en créant son propre fork appelé Blink. Grâce à sa rapidité, V8 permet à Chrome d’exécuter JavaScript plus efficacement et de mieux supporter le crawldes robots d’indexation.
2008 : SquirrelFish (SquirrelFish Extreme aka Nitro) (Apple) | Évolution de JavaScriptCore, optimisé pour Safari.
2010+ : Montée en puissance des moteurs JavaScript | Microsoft développe une nouvelle itération de Chakra pour Edge, tandis que Mozilla améliore SpiderMonkey.

L’optimisation des moteurs JavaScript a conduit à l’essor de runtimes comme Node.js qui permettent à JavaScript de toucher même l’univers backend.

L’essor des runtimes JavaScript

Les premiers runtimes JavaScript permettaient principalement l’intégration de scripting au sein d’applications plus complexes (le même usage qu’en faisaient donc les navigateurs à l’origine finalement) mais n’était pas réellement destiné à un autre usage. Au fil des améliorations apportées aux différents moteurs, et en particulier avec l’intégration du JIT dans V8, le JavaScript est devenu un language à part entière dont les capacités ne se limitaient plus à du simple scripting. Ayant toujours été le language le plus utilisé en matière de développement web, il est doté d’une communauté utilisateur particulièrement importante. Intégré à l’ensemble des plus gros navigateurs par défaut, il est bien plus simple à prendre en main et à utiliser que des alternatives comme Flash, Silverlight ou les applets Java. Toutes dépréciées au début des années 2020 au profit d‘HTML5, JavaScript, ou ses dérivés comme TypeScript, sont aujourd’hui les seuls languages utilisés côté utilisateur capables de manipuler dynamiquement le DOM d’une page d’un site web au sein d’un navigateur.

Voici un rapide aperçu des principaux moteurs JavaScript émergeant au fil des années:

1998 : Rhino (Mozilla) | Implémentation JavaScript en Java développée par Mozilla.
2009 : Node.js (Ryan Dahl) | Basé sur V8, il a transformé le développement backend en rendant JavaScript compétitif côté serveur.
2013 : Nashorn (Oracle, Java 8) | Moteur JS écrit en Java, intégré à JDK 8 comme successeur de Rhino (abandonné en 2021).
2014 : GraalJS (ex-GraalVM JavaScript) (Oracle, GraalVM) | Un moteur JavaScript moderne intégré à GraalVM, offrant des performances améliorées et une meilleure compatibilité avec ECMAScript moderne.
2017 : ChakraCore (Microsoft) | Version open-source de Chakra, utilisée en dehors des navigateurs (abandonnée en 2021).
2018 : Hermes (Facebook / Meta) | Moteur JS léger optimisé pour React Native.
2020 : Deno (Ryan Dahl) | Conçu par le créateur de Node.js, il est développé en Rust et apporte plus de sécurité et un meilleur support TypeScript.
2020 : QuickJS (Fabrice Bellard) | Moteur ultraléger en C, supportant ES2020 et permettant l’exécution de JS sur des systèmes embarqués.
2022 : Bun (Jarred Sumner) | Un runtime rapide développé en Zig basé sur JavaScriptCore, optimisé pour les performances.

Ces runtimes permettent d’interpréter du code JavaScript dans divers contextes, du backend aux applications embarquées.

SEO et la nécessité d’exécuter JavaScript hors navigateur

Le JavaScript joue un rôle crucial dans le rendu des pages web, mais il pose des défis pour le référencement. Bien que Googlebot, le crawler de Google, par exemple, soit désormais capable d’exécuter le JavaScript en utilisant une version de Chromium dédiée, cette opération, sous sa plus simple forme, est nécessairement plus longue (de l’ordre de 10x) et nécessite énormément de ressources en comparaison. De plus, le temps de rendering d’une telle page dépend en grande partie de son contenu (scripts, resources, …) et non d’une simple requête HTTP. Il faut donc bien garder à l’esprit que cette opération doit être “justifiée” du point de vue des crawlers, et qu’il s’agisse donc, d’une certaine manière, d’un site de “confiance”. Les sites/pages qui utilisent donc beaucoup trop de JavaScript ou dont le rendu est trop long ou trop gourmand en ressource devront nécessairement être pénalisés. Face à cette complexité, de nombreux robots d’indexation choisissent de ne pas ou peu exécuter le JavaScript des pages web indexées affectant leur visibilité dans les résultats de recherche.

Il existe néanmoins des solutions telles que SSR (Server-Side Rendering) ou le pre-rendering pour limiter cet effet. Permettre à un robot d’indexer son site, c’est donc aussi, quelque part, contribuer à améliorer l’expérience utilisateur de ce dernier. Il est néanmoins tout à fait possible de générer un site pré-rendu uniquement lors d’un crawl ; tant que le résultat est identique ou assimilé à ce qu’obtiendra un utilisateur après une exécution dynamique côté client.

Solutions pour récupérer un DOM post-exécution JavaScript

Il existe différentes manières d’exécuter du JS du point de vue d’un crawler, de la plus coûteuse à la moins précise:

1. Navigateurs headless classiques (Chrome, Firefox, WebKit)

Les solutions comme Puppeteer (Chrome) et Playwright (Chrome, Firefox, WebKit) permettent d’exécuter du JavaScript en utilisant une interface dédiée avec un vrai navigateur, offrant un rendu fidèle du DOM du point de vue des robots d’indexation. Bien que conçues, à l’origine, pour les tests automatiques d’interfaces utilisateurs avec, par exemple, le protocole WebDriver, les navigateurs mettent également à la disposition des développeur des interfaces dédiées comme Chrome DevTools Protocol (CDP) pour Chrome permettant de contrôler et tracer le rendu d’une page d’un site web. Bien que pratique, elles restent néanmoins peu adaptées au crawling.

Avantages :

Rendu identique à un navigateur standard.
Supporte toutes les API JS et Web.
Idéal pour le SEO et les tests d’interface.

Inconvénients :

Très gourmand en ressources.
Difficile à scaler sur des milliers de pages.

2. Navigateurs headless « light » (Splash, HtmlUnit, Lightpanda)

Des solutions plus légères comme HtmlUnit, Splash et Lightpanda offrent un compromis entre performance et précision du rendu.

Avantages :

Moins gourmand en ressources qu’un navigateur complet.
Peut exécuter du JavaScript tout en étant plus rapide.
Meilleur choix pour le scraping et le SEO à grande échelle.

Inconvénients :

Support JS partiel : certaines interactions complexes peuvent ne pas fonctionner.
Peut ne pas gérer toutes les API Web avancées.

3. Runtimes JS dédiés (JSDOM, Happy-DOM, Linkedom)

Pour des besoins plus légers, des simulateurs de DOM comme JSDOM, Happy-DOM et Linkedom permettent de manipuler des pages HTML sans navigateur.

Avantages :

Très rapide et léger.
Idéal pour extraire du contenu HTML et analyser des pages sans exécuter de JS complexe.
Parfait pour le SEO technique et les analyses HTML.

Inconvénients :

Ne supporte pas toutes les fonctionnalités Web (ex : WebGL, Canvas, interactions avancées).
Ne remplace pas un vrai navigateur pour des rendus interactifs.

Récapitulatif et recommandations

Solution	Précision du rendu	Consommation de ressources	Utilisation recommandée
Headless complet (Chrome, Firefox)	✅✅✅	🔴🔴🔴	Tests avancés, SEO précis
Headless light (Splash, HtmlUnit, Lightpanda)	✅✅	🟡🟡	Scraping, crawl scalable
Runtimes JS (JSDOM, Happy-DOM)	✅	🟢🟢🟢	Extraction rapide de données

Conclusion

Le choix d’une solution pour récupérer un DOM post-exécution JavaScript ne devrait pas être fait au hasard. La meilleure approche consiste d’abord à analyser les technologies utilisées sur une page pour comprendre ses besoins réels en matière de rendu.

En identifiant en amont les bibliothèques et frameworks JavaScript présents (React, Vue, Angular, etc.), ainsi que les prérequis nécessaires à leur exécution, il devient possible de sélectionner le moteur de rendu le plus adapté. Cette approche permet d’optimiser la consommation de ressources tout en garantissant un DOM final conforme à la réalité.

Plutôt que d’adopter une approche uniforme et coûteuse, il serait plus efficace de contextualiser chaque analyse en fonction des spécificités de la page, à l’image d’un processus optimisé où chaque tâche est exécutée avec les outils et les ressources strictement nécessaires. Un crawler pourrait alors être capable de déterminer a priori s’il peut se contenter d’une simple analyse HTML sans code à exécuter, s’il doit, à l’inverse, exécuter du JavaScript léger via un runtime comme JSDOM, ou s’il lui faut un navigateur headless plus lourd pour obtenir un rendu fiable. Dans un monde idéal, une page d’un site web pourrait alors, d’elle même, déclarer un ensemble de pré-requis ou une liste d’interfaces utilisées permettant de cibler de manière très précise le type de traitement à utiliser.

En adoptant une telle approche, on peut non seulement réduire le coût du crawl, mais aussi maximiser l’efficacité du référencement en ne sollicitant des ressources intensives que lorsque c’est réellement nécessaire. Cette approche permettrait sans doute également de réduire la complexité et augmenter les performances des navigateurs.