Organiser une démo
Se connecter à la console
  • Technologie

  • Solution

  • SDK

Distribuer de manière fiable les SDK JavaScript et les widgets à l'échelle

novembre 23, 2021 by Jawad Stouli

Lorsque nous avons commencé à distribuer notre SDK JavaScript, nous sommes passés de 0 à des millions de pages vues par jour en quelques jours. Depuis, notre croissance a été assez rapide et nous sommes fiers de notre taux de disponibilité de 100 % jusqu'à présent.
Voici l'histoire de la mise en place de notre infrastructure à une échelle indolore.

 

Sommaire 

 

 


 

Des bannières, des bannières partout !

 

Nous aidons les entreprises à se mettre en conformité avec le RGPD et la directive ePrivacy, deux réglementations européennes qui ont une portée mondiale. Parmi les nombreuses nouvelles obligations, ces deux règlements obligent les entreprises à recueillir le consentement avant de collecter et de traiter les informations personnelles des utilisateurs.

 

Découvrir Didomi pour la Conformité
Lorsque nous sommes déployés sur un site web, notre travail consiste à nous assurer que le consentement de l'utilisateur est recueilli de la bonne manière, puis partagé avec tous les tiers qui auront accès aux données de l'utilisateur (publicité, analyse, CRM, etc.) pour garantir la conformité de toute la chaîne.

Votre bannière type pour recueillir le consentement de l'utilisateur ressemblera à ceci :

Bannière de collecte de consentement de Didomi

Nous avons différents formats et variations pour nous assurer que nos bannières s'intègrent bien et nous essayons de les garder courtes et précises tout en respectant le règlement.

 

Découvrir la CMP

 

Le problème


Nos clients déploient notre SDK (une balise <script> standard que nous hébergeons) sur tous leurs sites web et il se charge sur toutes les pages. Cela entraîne quelques contraintes différentes :

 

  • Notre SDK doit fonctionner dans des environnements que nous ne contrôlons pas du tout. Cela signifie ne pas polluer le DOM, être capable de fonctionner avec de nombreuses bibliothèques, etc. Et ce n'est pas toujours facile, surtout si l'on considère que notre SDK fait beaucoup plus que simplement collecter des données comme le ferait un script d'analyse : nous affichons des widgets, exposons une API publique sur la page, etc.

  • Nous devons être rapides. Comme nous devons recueillir le consentement avant que le site web ou les tiers puissent commencer à collecter des données ou à installer des cookies, nous devons charger et exécuter le plus rapidement possible pour nous assurer que nous ne retardons pas d'autres opérations sur la page.

  • L'ampleur de nos activités croît assez rapidement car de nouveaux clients nous déploient sur leurs sites web qui ont déjà leur propre audience développée.

Compte tenu de ces contraintes, nous savions que nous voulions quelque chose qui s'appuierait sur des services très évolutifs qui pourraient nous aider à nous développer.

 

Documentation technique

 

Comment avons-nous optimisé la distribution de notre SDK ?


Notre SDK est une bibliothèque JavaScript assez standard. Nous le construisons avec Webpack et l'hébergeons sur S3 comme un actif statique.
La plus grande partie de la complexité vient de sa distribution : comment l'acheminer à l'utilisateur de la manière la plus efficace (tant du point de vue de la vitesse que du coût) et comment renvoyer les données à nos serveurs.

Nous avions trois règles directrices pour la construction de notre infrastructure.


1) Ne charger que ce qui est nécessaire


Nous effectuons un chargement paresseux pour nous assurer que nous ne chargeons que les modules qui sont pertinents pour l'utilisateur final et le site web. Par exemple, nous ne chargeons que le code correspondant au type de bannières utilisées par un site web donné et nous évitons de charger des bannières qui ne sont pas utilisées par le site web sur lequel nous tournons actuellement.


2) Rester proche de l'utilisateur final


Lorsque l'on sert des ressources statiques compressées, la seule façon de rendre les requêtes HTTP plus rapides est de réduire la distance qu'elles doivent parcourir. Si vos serveurs sont situés en Europe et que les utilisateurs se trouvent aux États-Unis, vous ne pouvez pas faire plus en termes de latence. Nous utilisons donc un CDN (CloudFront) pour nous assurer que l'utilisateur final accède aux serveurs situés à proximité de lui.
Nous veillons également à ce que les ressources servies par le CDN soient répliquées dans différents centres de données, à la fois pour des raisons de fiabilité et de rapidité.


3) Minimiser les requêtes HTTP


Les requêtes HTTP sont fondamentalement lentes et c'est encore pire sur les mobiles, donc minimiser le nombre de requêtes que notre SDK envoie était un objectif assez important.

La première chose que nous avons faite a été de nous assurer que notre JavaScript serait mis en cache sur les bords et, la plupart du temps, par les navigateurs eux-mêmes. Cela garantit que notre SDK est chargé assez efficacement.

 

Regrouper les requêtes HTTP


L'autre élément qui était important pour nous était de regrouper les requêtes HTTP lorsque c'était possible. Par exemple, notre SDK a besoin du pays de l'utilisateur, qui est déterminé à partir de son adresse IP. Cela pourrait être fait avec une requête HTTP envoyée par le SDK à un serveur API, mais c'est un aller-retour supplémentaire que nous voulions éviter. Au lieu de cela, nous utilisons Lambda@Edge pour modifier le contenu du SDK à la volée et y injecter le pays de l'utilisateur. Nous mettons ensuite en cache une version du SDK par pays.

Notre infrastructure finale est la suivante :

SDK Didomi et infrastructure de collecte des consentements

Ce sont quelques-unes des optimisations que nous avons ajoutées pour nous assurer que notre SDK puisse être chargé le plus rapidement possible. Nous avons également passé du temps à mettre en place une architecture évolutive pour nos serveurs d'API qui stockent les consentements et divers événements. Nous en parlerons dans un autre article !

 

Didomi pour les développeurs

 

Vous voulez en savoir plus ? 

 

Organiser une démo

 

Articles reliés