Jeu de données

Pour faire suite à l’article “ Influence des frameworks JavaScript sur le crawling web”, nous travaillons continuellement à améliorer notre crawler afin de mieux prendre en compte les pages affichant dynamiquement des informations.

Cependant, le coût d’un crawl avec exécution de JavaScript est bien plus élevé que sans. Il n’est donc pas possible de l’exécuter sur toutes les pages. Il est essentiel de cibler au mieux les URL à soumettre au module d’exécution JS.

Notre objectif est donc de créer une base qualifiée d’URL pour lesquelles nous savons si l’exécution de JavaScript est nécessaire ou non afin de récupérer les données.

Table of Contents

Étapes de sélection des URL

Pour définir une liste d’URL à qualifier, nous avons suivi plusieurs étapes.

Filtrage initial des URL Nous avons commencé avec une liste de 2 800 000 URL. Malheureusement, ces données étant un peu anciennes, beaucoup étaient encore en HTTP. En ne conservant que les URL en HTTPS, nous réduisons la liste à 300 000 URL.
Élimination des URL non pertinentes Une forte proportion des URL correspondait à des pages d’accueil (home pages), ce qui n’est pas représentatif de notre crawl global. Nous avons donc séparé les home pages des autres URL afin d’établir un ratio dans la sélection finale.Nous avons également exclu les URL de plateformes comme YouTube, Twitter et Facebook, que nous ne souhaitons pas crawler.
Diversification et limitation par domaine Après ces filtres, nous avons obtenu 100 000 URL non home. Pour assurer une diversité maximale des sites explorés, nous avons limité à 3 URL par domaine. Cette contrainte réduit notre liste à 38 747 URL.
Vérification de l’existence des pages Comme notre liste initiale datait un peu, nous avons testé ses URL afin de ne conserver que celles renvoyant un code HTTP 200 sur une requête GET.
- Jusqu’à présent, nous avons testé 13 208 URL.
- Parmi elles, 10 086 répondent bien avec un code 200.

Maintenant que nous disposons d’un groupe relativement important d’URL, l’objectif est de créer un premier sous-ensemble réduit pour le tester manuellement et évaluer la pertinence des résultats.

L’idée est de présenter au testeur deux versions d’une même page :

Une avec exécution du JavaScript
Une sans exécution du JavaScript

Cela donnera ce type d’écran pour le testeur :

Chez Babbar, nous avons déjà développé des outils de classification manuelle et avons remarqué un phénomène important : lorsque le testeur obtient un taux très élevé de similarité entre deux choix (par exemple, si 90 % des pages sont identiques avec et sans exécution du JavaScript), son taux d’erreur augmente. Autrement dit, il risque de manquer certaines différences. Après avoir cliqué dix fois de suite sur le même bouton, la lassitude s’installe et l’attention diminue.

Création d’un jeu de données avec plus d’URL nécessitant JavaScript

Pour éviter cela, nous avons cherché à constituer un jeu de données avec un taux d’URL nécessitant JavaScript important. Nous avons donc mis en place un premier test automatique, volontairement large, afin de détecter un maximum de pages pertinentes.

Le choix a été fait de sélectionner les pages qui remplissent deux critères :

Le parsing du DOM avec Boilerpipe retourne un texte presque vide.
Une famille de frameworks JavaScript est détectée dans le DOM. Pour cette détection, nous utilisons l’outil jappalizer.

Grâce à ce premier filtre, nous obtenons 806 URL sur les 10 086 testées.

Sélection d’un sous-ensemble de 200 URL pour un premier test manuel

À partir de cette liste filtrée, nous avons défini un premier sous-ensemble de 200 URL pour tester notre procédure. Pour garantir un bon équilibre dans l’échantillon, nous avons appliqué les règles suivantes :

80 % d’URL non home / 20 % d’URL home
80 % d’URL passant notre test automatique / 20 % d’URL ne le passant pas

Premiers résultats et ajustements

Après plusieurs itérations de qualification, nous avons identifié 96 URL présentant une différence visuelle avec et sans exécution de JavaScript.

Premier point intéressant : 6 URL détectées comme nécessitant JavaScript n’ont pas été identifiées par notre premier test automatique. Sur un total de 40 URL, c’est un taux important. Ce constat nous amène à revoir notre ratio de sélection. Peut-être faudrait-il passer d’un 80/20 à un 60/40, afin d’améliorer la diversité des pages sélectionnées.

Comparer le texte plutôt que le visuel

Autre observation : même si une page est visuellement différente, le texte exploitable dans le DOM reste parfois identique. Exemple : une page qui s’affiche initialement blanche avant que le JavaScript n’ajoute un display=none sur la div de premier plan.

Et il ne faut pas oublier notre objectif principal : mieux crawler le web en détectant les pages nécessitant l’exécution de JavaScript pour extraire leurs informations.

Nous cherchons à :

Découvrir les liens de la page
Classifier le thème de la page via un embeddings

Se fier uniquement à une différence graphique serait donc une erreur. Il est essentiel de comparer le texte extrait de chaque page avec et sans exécution du JavaScript pour une analyse plus pertinente dans notre cas.

Nous avons modifié notre outil afin d’afficher le texte d’une page après un parsing simple. Pour cela, nous récupérons son code HTML grâce à la librairie Java HTTP Apache Client et au framework Playwright. Pour chaque URL, nous générons un fichier WARC contenant pour les 2 appels :

le code brut HTML
le texte après un parsing simple
le texte extrait avec Boilerpipe

Nous analysons ensuite ces fichiers manuellement pour comparer les résultats.

Les différences sont plus difficiles à repérer que lors du test précédent. L’objectif est d’identifier si l’exécution du JavaScript apporte réellement plus d’informations. Cependant, une partie du texte ajouté provient parfois de bannières de cookies, ce qui ne nous intéresse pas.

En reprenant notre liste de 200 URLs, nous avons trouvé 6 URL où le JS ajoute des données sans que le test automatique les détecte. Nous avons également identifié 5 URL qui n’avaient pas été repérées lors du test visuel. Mais surtout, 51 URL détectées précédemment ne le sont plus, ce qui indique que notre premier test générait beaucoup de faux positifs.

Conclusion

Nous allons maintenant construire une base de milliers d’URL qualifiées pour déterminer quand il est pertinent d’exécuter du JavaScript. L’idée est d’optimiser ce processus afin de ne le faire que sur certaines pages, et ainsi réduire les coûts.