Le tag JavaScript client-side de DataDome est plus rapide que jamais

Chez DataDome, nous veillons à ce que nos clients soient efficacement protégés, sans engendrer de friction supplémentaire. Nous sommes obsédés par la performance, traitant et analysant chaque requête HTTP sur les sites Web de nos clients en temps réel en moins de 2 millisecondes ! Et avec plus de 5 trillions de signaux analysés chaque jour, l’optimisation de notre solution est clé.

Pour aider nos capacités de détection, nous utilisons un tag JavaScript pour collecter des signaux côté client :

• Empreintes de navigateur utilisées dans le contexte de la détection de bots.
• Informations sur l’appareil de l’utilisateur final, le navigateur et le système d’exploitation, telles que la mémoire de l’appareil, le nombre de cœurs de CPU et les informations sur le GPU.
• Comportement côté client, tel que les mouvements de souris et les événements tactiles.
• Défis JavaScript (JS) spécialement conçus pour détecter les effets secondaires des navigateurs automatisés, des navigateurs sans tête et des frameworks anti-détection.

Bien que le tag JS ait déjà un impact négligeable sur les sites Web de nos clients, nous cherchons toujours à améliorer nos solutions. En nous concentrant sur l’amélioration de la performance, nous avons travaillé dur ces derniers mois pour optimiser davantage le tag JS.

Optimisations du Tag Côté Client : Résultats Clés

De juin 2023 à novembre 2023, nous avons réduit :

• Le Temps de Blocage Total de 110 ms à 10 ms (une réduction de 91%). Notez que le TBT n’est pas la latence.
• La taille du tag JS (gzipé) de 58 kB à 26 kB (une réduction de 53%).

Quels sont les avantages de l’optimisation ?

La performance de votre site est clé pour vos clients, qui en moyenne ne donneront que trois secondes à un site Web pour se charger avant de cliquer ailleurs. Le temps de chargement du site (soit le temps de chargement côté serveur ou côté client) a un impact sur le taux de conversion et le taux de rebond, comme démontré dans plusieurs analyses et audits.

• Rakuten 24 a augmenté son revenu par visiteur d’environ 54% et son taux de conversion d’environ 33% en investissant dans les Core Web Vitals, comme le temps de chargement du site.
• Vodafone a constaté une augmentation des ventes de 8% suite à une amélioration de 31% du LCP (Largest Contentful Paint), l’un des trois piliers principaux des Core Web Vitals.

Bien qu’il existe de nombreuses façons de surveiller la performance web d’un site, les Core Web Vitals sont l’une des métriques les plus suivies sur le marché pour tester la vitesse d’un site Web, ainsi qu’une partie clé du SEO.

Et chez DataDome, nous nous concentrons sur la réduction de notre empreinte écologique. En réduisant la taille de notre tag JS, qui est chargé des millions de fois par jour, nous réduisons l’utilisation de la bande passante en arrière-plan et notre empreinte !

Comment avons-nous amélioré les performances de notre tag JS ?

Nous sommes passés par quatre processus principaux pour optimiser notre tag.

1. Refonte de notre code

Bien que simple, cette étape est obligatoire pour tout projet d’optimisation de performance. Certaines parties de notre JavaScript étaient dupliquées dans notre base de code. En le refactorisant, nous avons pu obtenir un meilleur code et réduire la taille du bundle de 15%.

2. Optimisation de notre code

En effectuant un profilage du code JavaScript, nous avons pu identifier les parties de notre code qui utilisaient le plus de ressources CPU. Nous avons refactorisé ces parties – lorsque cela était possible – pour réduire l’utilisation précieuse du CPU.

3. Division et obfuscation de notre logique

Nous ne voulons pas que les bots puissent inverser l’ingénierie de notre tag JS, donc nous le protégeons avec un obfuscateur personnalisé (en interne).

Dans le passé, nous avions l’habitude de tout obfusquer à l’intérieur de notre tag JS. Mais nous n’avons pas besoin d’obfusquer tout. Par exemple, la façon dont nous affichons un CAPTCHA n’est pas confidentielle, car c’est juste du JS vanilla et cela n’aide pas dans nos capacités de détection. Nous avons donc divisé notre fichier JS en deux “modules” :

• Logique d’affichage CAPTCHA. Cette logique intercepte tous les appels HTTP et affiche notre CAPTCHA sur les requêtes XHR. Ce code n’a pas besoin d’être obfusqué.
• Collecte de signaux côté client. Ce code doit être obfusqué pour éviter le reverse engineering.

4. Déplacement du calcul de certains signaux en dehors du thread principal du navigateur

Certains de nos signaux sont plus complexes à calculer. Ces signaux étaient auparavant calculés à l’intérieur du thread principal JavaScript du navigateur. L’utilisation du thread principal pour cela ajoutait quelques millisecondes à la vitesse de rendu de la page, en particulier sur les appareils lents.

Le “Total Blocking Time” mesure le temps pendant lequel le thread principal est bloqué, et c’est la principale métrique sur laquelle nous nous sommes concentrés pour le réduire. Nous avons déplacé ces signaux vers un service worker dédié, utilisant un autre thread pour les calculer afin d’éviter de bloquer le thread principal du navigateur.

Les mesures métriques ont été effectuées par des prestataires tiers WebPageTest.org et pagespeed.web.dev. 

Conclusion

L’équipe d’ingénierie a travaillé longtemps pour atteindre cette incroyable amélioration des performances. Nous avons effectué des centaines de tests pour trouver la meilleure performance possible – sans compromettre la sécurité.

Nous avons encore quelques améliorations dans notre sac pour continuer à avoir le tag JS le plus rapide du marché et améliorer notre détection. Restez à l’écoute !