En septembre 2017, nous avons annoncé une modification à venir concernant la gestion du son avec les règles de comportement de lecture automatique dans Chrome. Ce changement de règle a été publié avec la version stable de Chrome 66 en mai 2018.
Suite aux commentaires de la communauté de développeurs Web Audio, nous avons reporté la publication de la section Web Audio du règlement sur la lecture automatique afin de laisser aux développeurs plus de temps pour mettre à jour leurs sites Web. Nous avons également modifié l'implémentation du règlement concernant l'audio Web afin de réduire le nombre de sites Web (en particulier de jeux en ligne) à modifier leur code et d'offrir ainsi une meilleure expérience à nos utilisateurs.
Le déploiement de cette modification des règles est prévu pour Chrome 71 en décembre 2018.
En quoi consiste exactement ce nouveau règlement ?
La lecture automatique est le nom donné à un contenu qui est lu immédiatement lors du chargement d'une page Web. Pour les sites Web censés lire automatiquement leur contenu, ce changement empêche la lecture par défaut. Dans la plupart des cas, la lecture reprendra, mais dans d'autres cas, un petit ajustement du code sera nécessaire. Plus précisément, les développeurs doivent ajouter un code qui réactive leur contenu si l'utilisateur interagit avec la page Web.
Toutefois, si l'utilisateur arrive sur une page dont le contenu est en lecture automatique, et s'il y a accédé à partir d'une page de même origine, ce contenu ne sera jamais bloqué. Pour obtenir des exemples plus détaillés, consultez notre article de blog précédent sur les règles relatives à la lecture automatique.
Nous avons également ajouté une heuristique permettant d'analyser le comportement antérieur des utilisateurs vis-à-vis des sites Web qui lisent automatiquement du contenu audio. Nous détectons quand les utilisateurs autorisent régulièrement la lecture audio pendant plus de sept secondes lors de la plupart de leurs visites sur un site Web, et nous activons la lecture automatique pour ce site Web.
Pour ce faire, nous utilisons un index stocké localement par profil Chrome sur l'appareil. Il n'est pas synchronisé entre les appareils et n'est partagé que dans le cadre de statistiques anonymisées sur les utilisateurs. Nous l'appelons "Media Engagement Index" (MEI). Vous pouvez le consulter via chrome://media-engagement.
L'indicateur MEI comptabilise le nombre de visites sur un site comprenant des lectures audio de plus de sept secondes. Les MEI d'un utilisateur nous permettent de déterminer si un utilisateur s'attend à recevoir de l'audio depuis un site Web spécifique ou non, et d'anticiper ainsi ses intentions à l'avenir.
Si l'utilisateur laisse souvent le domaine d'un site Web lire du contenu audio pendant plus de 7 secondes, nous partirons du principe qu'il s'attend à ce que ce site Web ait le droit de lire automatiquement du contenu audio. Par conséquent, nous accordons à ce site Web le droit de lire automatiquement du contenu audio sans que l'utilisateur ait à interagir avec un onglet de ce domaine.
Toutefois, ce droit n'est pas garanti indéfiniment. Si le comportement de l'utilisateur change (par exemple, arrêt de la lecture audio ou fermeture de l'onglet dans les sept secondes au cours de plusieurs visites), nous supprimons le droit de lecture automatique du site Web.
L'utilisation des éléments HTML multimédias (vidéo et audio) et de l'audio Web (objets AudioContext instanciés par JavaScript) sera prise en compte dans les MEI. En vue du déploiement de cette règle relative au comportement des utilisateurs pour le contenu audio sur le Web, ils commenceront à contribuer à la MEI à partir de Chrome 70. Nous pourrons ainsi anticiper l'intention souhaitée des utilisateurs concernant la lecture automatique et les sites Web qu'ils visitent habituellement.
Il convient de noter que les iFrames ne peuvent bénéficier d'un droit de lecture automatique sans interaction de l'utilisateur que si la page Web parente qui intègre l'iFrame étend ce droit à l'iFrame donné.
Report du changement visant à soutenir la communauté
La communauté des développeurs Web Audio, en particulier les développeurs de jeux Web et les développeurs WebRTC dans cette communauté, ont pris conscience de l'apparition de ce changement dans la version stable de Chrome.
La communauté a indiqué que de nombreux jeux et expériences audio sur le Web seraient affectés négativement par ce changement. Plus précisément, de nombreux sites qui n'auraient pas été mis à jour ne diffuseraient plus de contenus audio. Notre équipe a donc décidé qu'il était judicieux de retarder ce changement pour donner plus de temps aux développeurs de contenus audio Web pour mettre à jour leurs sites Web.
En outre, nous avons pris le temps de:
- Demandez-vous sérieusement si cette modification du règlement constitue la meilleure solution ou non.
- Découvrez comment nous pourrions contribuer à réduire le nombre de sites Web comportant du contenu audio concernés.
Dans le premier cas, nous avons finalement décidé que ces modifications étaient effectivement nécessaires afin d'améliorer l'expérience utilisateur pour la majorité de nos utilisateurs. Pour en savoir plus sur le problème résolu par la modification du règlement, consultez la section suivante de cet article.
Dans ce dernier cas, nous avons ajusté notre mise en œuvre pour Web Audio afin de réduire le nombre de sites Web initialement touchés. Parmi les sites que nous soupçonnons d'être endommagés par ce changement (dont beaucoup ont été fournis à titre d'exemple par la communauté des développeurs de jeux Web), cet ajustement a permis à plus de 80% d'entre eux de fonctionner automatiquement. Pour en savoir plus sur l'analyse et les tests de ces exemples de sites, cliquez ici. Ce nouvel ajustement est décrit plus en détail ci-dessous.
Nous avons également modifié la compatibilité avec les applications WebRTC. Tant qu'une session de capture sera active, la lecture automatique sera autorisée.
Quel problème ce changement de comportement vise-t-il à résoudre ?
Jusqu'à présent, les navigateurs n'étaient pas efficaces pour gérer le son. Lorsque les utilisateurs ouvrent une page Web et reçoivent un son qu'ils ne pensaient pas ou ne veulent pas, l'expérience utilisateur est médiocre. Cette mauvaise expérience utilisateur est le problème que nous essayons de résoudre. Ce type de bruit est la principale raison pour laquelle les utilisateurs ne souhaitent pas que leur navigateur lance la lecture automatique.
Cependant, il arrive parfois que les utilisateurs souhaitent que le contenu soit lu automatiquement et qu'un nombre significatif de lectures automatiques bloquées dans Chrome soient ensuite lus.
Par conséquent, nous pensons pouvoir créer la meilleure expérience utilisateur possible en apprenant de l'utilisateur et en anticipant son intention sur chaque site Web. Si les utilisateurs ont tendance à laisser le contenu d'un site Web activé, la lecture automatique du contenu de ce site sera lancée à l'avenir. À l'inverse, si les utilisateurs ont tendance à interrompre la lecture automatique du contenu d'un site Web donné, nous empêchons par défaut la lecture automatique pour ce contenu.
La communauté a proposé de couper le son d'un onglet au lieu de mettre la lecture automatique en pause. Toutefois, nous pensons qu'il est préférable d'interrompre l'expérience de lecture automatique pour que le site Web sache que la lecture automatique a été bloquée et permettre au développeur du site de réagir. Par exemple, si certains développeurs souhaitent simplement couper le son, d'autres peuvent préférer que leur contenu audio soit mis en pause jusqu'à ce que l'utilisateur interagit activement avec celui-ci. Dans le cas contraire, l'utilisateur risque de manquer une partie de l'expérience audio.
Nouveaux ajustements pour aider les développeurs de jeux Web
La manière la plus courante pour les développeurs d'utiliser l'API Web Audio consiste à créer deux types d'objets pour lire du contenu audio:
- Un AudioContext
- Enfin, les nœuds AudioNodes, qui sont associés à un contexte
Les développeurs de contenus audio sur le Web créeront un élément AudioContext pour lire des contenus audio. Pour reprendre l'audio une fois que la règle de lecture automatique a automatiquement suspendu l'élément AudioContext, il doit appeler la fonction summary() sur cet objet après que l'utilisateur a interagi avec l'onglet:
const context = new AudioContext();
// Setup an audio graph with AudioNodes and schedule playback.
...
// Resume AudioContext playback when user clicks a button on the page.
document.querySelector('button').addEventListener('click', function() {
context.resume().then(() => {
console.log('AudioContext playback resumed successfully');
});
});
De nombreuses interfaces héritent d'AudioNode. L'une d'elles est l'interface AudioScheduledSourceNode. Les composants AudioNode qui implémentent l'interface AudioScheduledSourceNode sont communément appelés nœuds sources (par exemple, AudioBufferSourceNode, ConstantSourceNode et OscillatorNode). Les nœuds sources implémentent une méthode start().
Les nœuds sources représentent généralement des extraits audio individuels pratiqués dans les jeux. Il peut s'agir, par exemple, du son émis lorsque le joueur ramasse une pièce ou de la musique de fond diffusée à l'étape en cours. Il est très probable que les développeurs de jeux appellent la fonction start() sur les nœuds sources chaque fois que l'un de ces sons est nécessaire au jeu.
Une fois que nous avons identifié ce modèle courant dans les jeux Web, nous avons décidé d'ajuster notre implémentation comme suit:
Un AudioContext est réactivé automatiquement lorsque les deux conditions suivantes sont remplies:
- L'utilisateur a interagi avec une page.
- La méthode start() d'un nœud source est appelée.
En raison de ce changement, la plupart des jeux Web reprendront désormais l'audio lorsque l'utilisateur commencera à jouer.
Faire progresser le Web
Pour faire avancer la plate-forme Web, il est parfois nécessaire d'apporter des modifications susceptibles de rompre la compatibilité. Malheureusement, la lecture automatique des contenus audio est complexe et relève de cette catégorie de modifications. Mais ce changement est essentiel pour s'assurer que le Web ne stagne pas et ne perd pas sa touche d'innovation.
Nous sommes toutefois conscients qu'il n'est pas toujours possible de corriger les sites Web à court terme pour diverses raisons:
- Les développeurs Web peuvent se concentrer sur un nouveau projet et la maintenance d'un site Web plus ancien n'est pas toujours possible dans l'immédiat.
- Les portails de jeux en ligne n'ont pas forcément le contrôle sur l'implémentation des jeux de leur catalogue. De plus, la mise à jour de centaines, voire de milliers, de jeux peut s'avérer chronophage et coûteux pour les éditeurs.
- Certains sites Web peuvent tout simplement être très anciens et, pour une raison ou une autre, ne plus être gérés, mais encore hébergés à des fins historiques.
Voici un court extrait de code JavaScript qui intercepte la création d'objets AudioContext et déclenche automatiquement la fonction de reprise de ces objets lorsque l'utilisateur effectue diverses interactions utilisateur. Ce code doit être exécuté avant la création d'objets AudioContext sur votre page Web. Par exemple, vous pouvez ajouter le code suivant à la balise de votre page Web:
(function () {
// An array of all contexts to resume on the page
const audioContextList = [];
// An array of various user interaction events we should listen for
const userInputEventNames = [
'click',
'contextmenu',
'auxclick',
'dblclick',
'mousedown',
'mouseup',
'pointerup',
'touchend',
'keydown',
'keyup',
];
// A proxy object to intercept AudioContexts and
// add them to the array for tracking and resuming later
self.AudioContext = new Proxy(self.AudioContext, {
construct(target, args) {
const result = new target(...args);
audioContextList.push(result);
return result;
},
});
// To resume all AudioContexts being tracked
function resumeAllContexts(event) {
let count = 0;
audioContextList.forEach(context => {
if (context.state !== 'running') {
context.resume();
} else {
count++;
}
});
// If all the AudioContexts have now resumed then we
// unbind all the event listeners from the page to prevent
// unnecessary resume attempts
if (count == audioContextList.length) {
userInputEventNames.forEach(eventName => {
document.removeEventListener(eventName, resumeAllContexts);
});
}
}
// We bind the resume function for each user interaction
// event on the page
userInputEventNames.forEach(eventName => {
document.addEventListener(eventName, resumeAllContexts);
});
})();
Notez que cet extrait de code ne permet pas de réactiver des éléments AudioContext instanciés dans un iFrame, sauf s'il est inclus dans le champ d'application du contenu de l'iFrame lui-même.
Mieux servir nos utilisateurs
Pour accompagner ce changement, nous lançons également un mécanisme permettant aux utilisateurs de désactiver la règle de lecture automatique afin de couvrir les cas où l'apprentissage automatique ne fonctionne pas comme prévu ou pour les sites Web que le changement rend inutilisable. Cette modification sera déployée avec la nouvelle règle dans Chrome 71 et sera disponible dans les paramètres de son. Les sites pour lesquels l'utilisateur souhaite autoriser la lecture automatique peuvent être ajoutés à la liste d'autorisation.
Comment les MEI sont-ils conçus pour les nouveaux utilisateurs ?
Comme indiqué précédemment, nous créons les MEI automatiquement au fil du temps en fonction du comportement de l'utilisateur afin d'anticiper l'intention souhaitée pour un site Web donné avec un contenu en lecture automatique. Chaque site Web a un score compris entre zéro et un dans cet index. Un score élevé indique que l'utilisateur s'attend à ce que le contenu de ce site Web soit lu.
Toutefois, pour les nouveaux profils utilisateur ou si un utilisateur efface ses données de navigation, au lieu de bloquer la lecture automatique partout, une liste pré-source basée sur les scores MEI agrégés des utilisateurs anonymisés est utilisée pour déterminer les sites Web qui peuvent lire automatiquement. Ces données ne déterminent que l'état initial des MEI au moment de la création du profil utilisateur. Lorsque l'utilisateur navigue sur le Web et interagit avec des sites Web en lecture automatique, son MEI personnel remplace la configuration par défaut.
Cette liste est générée par un algorithme plutôt que manuellement, et n'importe quel site Web peut y figurer. Les sites sont ajoutés à la liste si un nombre suffisant d'utilisateurs autorisent la lecture automatique sur ce site. Ce seuil est basé sur un pourcentage afin de ne pas favoriser les sites plus importants.
Trouver l'équilibre
Nous avons publié de nouveaux documents pour vous donner plus d'informations sur notre processus de prise de décision et sur la logique de conception qui sous-tend ces règles. ainsi qu'une nouvelle documentation sur le fonctionnement de la liste de sites pré-source.
Nous accordons toujours la priorité à nos utilisateurs, mais nous ne voulons pas non plus décevoir la communauté des développeurs Web. Le fait d'être le navigateur implique parfois que ces deux objectifs doivent être soigneusement équilibrés. Nous pensons qu'en modifiant l'implémentation de cette règle, et en accordant un délai supplémentaire aux développeurs de contenus audio Web pour mettre à jour leur code, nous parviendrons à trouver cet équilibre avec Chrome 71.