AMÉLIORATION DE LA DIFFUSION DU LECTEUR BRIGHTCOVE

LE PROBLÈME

De nouvelles versions du lecteur Brightcove sont publiées en permanence avec les technologies les plus récentes afin d'offrir la meilleure expérience de lecture. Afin d'obtenir des analyses en temps réel pour les nouvelles modifications apportées au lecteur, Brightcove effectue des tests de comparaison A/B pour prévisualiser l'impact de ces changements. Cet article de blog donne un aperçu du fonctionnement de notre processus de test A/B et des améliorations que nous avons apportées pour que le lecteur soit toujours aussi efficace que possible.

Historiquement, les tests de comparaison A/B ont été réalisés en regroupant les versions A et B de chaque lecteur avec des mises à jour automatiques activées avant la sortie de la version complète. D'un point de vue technique, cela a été réalisé en concaténant le code source des lecteurs A et B et en ajoutant un petit "shim" pour décider quel lecteur exécuter au moment de l'exécution par le biais d'un projet que nous appelons le "player-shim-builder" :

Après une analyse minutieuse des mesures rapportées lors du test A/B, la nouvelle version du lecteur Brightcove a été soit rendue disponible à l'échelle mondiale, soit retirée pour un examen ultérieur. Bien que ce système ait atteint son objectif, il présentait un problème majeur : le regroupement de deux lecteurs doublait la taille de la charge utile pour les utilisateurs finaux. Toute personne disposant d'une connexion internet lente ou d'un vieux téléphone portable a pu remarquer une légère augmentation des temps de chargement des lecteurs grâce à nos tests A/B. Pour faciliter les tests A/B à long terme de notre lecteur, il fallait changer quelque chose.

UN NOUVEL ESPOIR

Avant de révéler la recette secrète qui nous a permis de résoudre ce problème, il est important de comprendre le codage Lempel-Ziv (LZ77) et son rôle dans la diffusion du lecteur Brightcove. Virtuellement, l'algorithme de compression tous les principaux navigateurs le soutenir par le biais de la gzip En-tête HTTP Content-Encoding. Bien qu'une plongée en profondeur dans les détails techniques de l'algorithme dépasse le cadre de ce billet de blog, l'algorithme compresse les données en trouvant des séries de caractères répétés et en utilisant des jetons spéciaux pour se référer à ces bits partagés. Les taux de compression optimaux sont obtenus lorsque les données contenant des caractères très similaires sont très proches les unes des autres.

Du point de vue du lecteur Brightcove, il s'agit d'un élément clé. En général, seul un petit pourcentage du code du lecteur change d'une version à l'autre. Dans le cas d'un test A/B, la quasi-totalité du code entre les versions A et B est identique. Plutôt que de concaténer les codes des deux lecteurs, le concepteur du lecteur peut diviser la base de code de chaque lecteur en petites sections, ou " bandes ", du code source, et les intégrer dans le paquet groupé. Chaque bande du joueur A est susceptible d'être très similaire à la bande correspondante de la source du joueur B :

Le " striping " du lecteur pour les tests A/B a un effet considérable sur la taille du lecteur livré. L'utilisation de la méthode de concaténation pour créer un lecteur de test se traduit par un index.min.js d'une taille de 372 Ko, alors que le striping réduit cette taille à 212 Ko, soit une réduction de 43 % du nombre d'octets livrés.

Cependant, le code du lecteur à bandes que nous livrons n'est pas immédiatement utilisable. Pour pouvoir lire une vidéo, le lecteur doit être dépouillé lors du chargement de la page et évalué en JavaScript exécutable. Le tableau suivant présente une ventilation des temps de dé-striping pour quelques appareils et navigateurs majeurs au cours d'une période de test initiale :

Même en tenant compte des temps de dé-stripe, nous avons constaté que les temps de chargement du lecteur étaient nettement plus rapides que la concaténation sur tous les principaux navigateurs et appareils. Certains utilisateurs finaux du lecteur Brightcove n'ont plus de délais perceptibles lors des tests A/B. En optimisant notre stratégie de diffusion du lecteur, nous avons réduit le temps d'initialisation de notre lecteur dans presque tous les scénarios.

La séparation du lecteur pour les tests de comparaison A/B nous permet non seulement d'exécuter des tests plus longs sans craindre de ralentir la diffusion des lecteurs, mais aussi d'étendre nos tests en dehors de nos fenêtres de test précédentes adaptées aux développeurs à l'heure normale de l'Est. Le découpage du lecteur pour améliorer les tests A/B est l'une des nombreuses améliorations apportées par Brightcove pour repousser les limites de la diffusion des lecteurs à l'échelle mondiale.

FAQ

Pourquoi choisir le lecteur à chaque fois ? Pourquoi ne pas sélectionner le lecteur au moment de l'exécution ?

Le code du lecteur Brightcove garantit depuis longtemps l'instanciation synchrone du lecteur. Avec un code intégré, toutes les balises de script invoquées après l'instanciation du lecteur sont garanties de faire référence à un objet lecteur, et la sélection du code du lecteur à partir d'une ressource distante ne fournit pas d'invariants similaires.

Comment avez-vous déterminé la taille des bandes ?

La fenêtre coulissante de la compression gzip de la plupart des navigateurs est de 32 kB. Afin de maximiser le nombre de caractères répétés entre les bandes sans affecter le temps de publication des joueurs, nous utilisons une fenêtre coulissante de 16 kB pour le code de chaque joueur A ou B. Nous avons testé différentes tailles de bandes pour nous assurer que la longueur choisie était correcte.

Comment avez-vous comparé le temps de dé-striping à la vitesse de téléchargement ?

Les vitesses de téléchargement des lecteurs n'étant pas disponibles pour diverses raisons, nous avons utilisé les débits binaires de lecture pour estimer la vitesse à laquelle le code du lecteur est téléchargé par les utilisateurs finaux.