En septembre 2017, nous avons annoncé un changement à venir concernant la gestion de l'audio avec le règlement sur le 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 retardé la publication de la partie Web Audio du règlement sur la lecture automatique afin de laisser plus de temps aux développeurs de mettre à jour leurs sites Web. Nous avons également apporté quelques modifications à l'implémentation du règlement pour Web Audio. Cela réduira le nombre de sites Web qui devront ajuster leur code (en particulier les jeux Web), et améliorera ainsi l'expérience de nos utilisateurs.
Cette modification de règle est désormais prévue pour Chrome 71 en décembre 2018.
Qu'est-ce que ce changement de règles implique exactement ?
La lecture automatique désigne un contenu qui se lance immédiatement lors du chargement d'une page Web. Pour les sites Web qui s'attendaient à pouvoir lire automatiquement leur contenu, cette modification empêchera la lecture par défaut. Dans la plupart des cas, la lecture reprendra, mais dans certains cas, un petit ajustement du code sera nécessaire. Plus précisément, les développeurs doivent ajouter du code qui reprend leur contenu si l'utilisateur interagit avec la page Web.
Toutefois, si l'utilisateur accède à une page contenant du contenu en lecture automatique à partir d'une page de la 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 le règlement sur la lecture automatique.
Nous avons également ajouté une heuristique pour apprendre du comportement passé des utilisateurs concernant les sites Web qui diffusent du contenu audio en lecture automatique. Nous détectons quand les utilisateurs laissent régulièrement un contenu audio s'exécuter 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 indice stocké localement par profil Chrome sur un appareil. Il n'est pas synchronisé entre les appareils et n'est partagé que dans les statistiques utilisateur anonymisées. Nous appelons cet indice l'indice d'engagement multimédia (MEI). Vous pouvez l'afficher via chrome://media-engagement.
Le MEI comptabilise le nombre de visites d'un site qui incluent une lecture audio de plus de sept secondes. Nous pensons que nous pouvons déterminer si un utilisateur s'attend à entendre du contenu audio sur un site Web particulier ou non, et anticiper ses intentions à l'avenir.
Si l'utilisateur laisse souvent le domaine d'un site Web diffuser du contenu audio pendant plus de sept secondes, nous supposons qu'il s'attend à ce que ce site Web ait le droit de diffuser du contenu audio automatiquement. Nous accordons donc à 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, s'il arrête la lecture audio ou ferme l'onglet dans un délai de sept secondes au cours de plusieurs visites), nous supprimons le droit du site Web de diffuser de la lecture automatique.
L'utilisation d'éléments HTML multimédias (vidéo et audio) et de Web Audio (objets AudioContext instanciés en JavaScript) contribue à l'indice MEI. En prévision du déploiement de cette règle, le comportement des utilisateurs concernant Web Audio commencera à contribuer à l'EMI à partir de Chrome 70. Nous pourrons ainsi déjà anticiper l'intention de l'utilisateur concernant la lecture automatique et les sites Web qu'il consulte habituellement.
Notez que les iFrames ne peuvent obtenir le 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é.
Retarder le changement pour soutenir la communauté
La communauté des développeurs Web Audio, en particulier les développeurs de jeux Web et de WebRTC, a remarqué cette modification lorsqu'elle est apparue dans le canal stable de Chrome.
Les commentaires de la communauté ont indiqué que de nombreux jeux Web et expériences audio Web seraient affectés négativement par ce changement. Plus précisément, de nombreux sites qui n'ont pas été mis à jour ne diffuseraient plus de contenu audio auprès des utilisateurs. Notre équipe a donc décidé de repousser ce changement pour laisser aux développeurs audio Web plus de temps pour mettre à jour leurs sites Web.
Nous avons également pris le temps de:
- Réfléchissez sérieusement à savoir si cette modification de stratégie était la meilleure option.
- Étudier les moyens de réduire le nombre de sites Web avec contenu audio concernés
Pour le premier, nous avons finalement décidé que ce changement de règles était effectivement nécessaire pour améliorer l'expérience utilisateur de la majorité de nos utilisateurs. Pour en savoir plus sur le problème résolu par ce changement de règlement, consultez la section suivante de cet article.
Pour ce dernier, nous avons ajusté notre implémentation pour Web Audio, ce qui réduira le nombre de sites Web initialement concernés. Parmi les sites que nous savions affectés par ce changement (dont beaucoup ont été fournis à titre d'exemple par la communauté de développement de jeux Web), plus de 80% d'entre eux fonctionneront automatiquement grâce à cet ajustement. Pour consulter notre analyse et nos tests de ces exemples de sites, cliquez ici. Ce nouvel ajustement est décrit plus en détail ci-dessous.
Nous avons également apporté une modification pour prendre en charge les applications WebRTC. Tant qu'une session de capture est active, la lecture automatique est autorisée.
Quel problème ce changement de comportement vise-t-il à résoudre ?
Les navigateurs ont toujours eu du mal à aider l'utilisateur à gérer le son. Lorsque les utilisateurs ouvrent une page Web et qu'ils entendent un son auquel ils ne s'attendaient pas ou qu'ils ne souhaitent pas, leur expérience utilisateur est mauvaise. C'est ce problème que nous essayons de résoudre. Le bruit indésirable est la principale raison pour laquelle les utilisateurs ne souhaitent pas que leur navigateur lance automatiquement la lecture de contenus.
Toutefois, les utilisateurs souhaitent parfois que le contenu soit lu automatiquement, et un nombre significatif de contenus bloqués dans Chrome sont ensuite lus par l'utilisateur.
Nous pensons donc qu'en apprenant des utilisateurs et en anticipant leur intention sur chaque site Web, nous pouvons créer la meilleure expérience utilisateur possible. Si les utilisateurs ont tendance à laisser la lecture de contenus sur un site Web, nous la lancerons automatiquement à l'avenir. À l'inverse, si les utilisateurs ont tendance à arrêter la lecture automatique des contenus d'un site Web donné, nous désactivons la lecture automatique pour ce contenu par défaut.
La communauté a proposé de couper le son d'un onglet au lieu de suspendre la lecture automatique. Toutefois, nous pensons qu'il est préférable d'arrêter la lecture automatique afin que le site Web sache qu'elle a été bloquée et que le développeur puisse y réagir. Par exemple, certains développeurs peuvent simplement couper le son, tandis que d'autres préfèrent que leur contenu audio soit mis en pause jusqu'à ce que l'utilisateur interagisse activement avec le contenu, sans quoi il risque de manquer une partie de l'expérience audio.
Nouveaux ajustements pour aider les développeurs de jeux Web
La méthode la plus courante pour les développeurs d'utiliser l'API Web Audio consiste à créer deux types d'objets pour lire de l'audio:
- Un AudioContext
- Et des AudioNodes, qui sont associés à un contexte
Les développeurs audio Web créent un AudioContext pour lire du contenu audio. Pour reprendre l'audio après que la règle de lecture automatique a suspendu automatiquement son AudioContext, il doit appeler la fonction resume() 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, dont l'interface AudioScheduledSourceNode. Les AudioNodes 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 lus par les jeux, par exemple le son émis lorsqu'un joueur récupère une pièce ou la musique de fond jouée dans le niveau en cours. Les développeurs de jeux appellent très probablement la fonction start() sur les nœuds sources chaque fois que l'un de ces sons est nécessaire pour le jeu.
Une fois que nous avons reconnu ce modèle commun dans les jeux Web, nous avons décidé d'ajuster notre implémentation comme suit:
Un AudioContext est automatiquement repris lorsque deux conditions sont remplies:
- L'utilisateur a interagi avec une page.
- La méthode start() d'un nœud source est appelée.
En raison de cette modification, la plupart des jeux Web reprendront désormais leur audio lorsque l'utilisateur commencera à jouer.
Faire avancer le Web
Pour faire évoluer la plate-forme Web, il est parfois nécessaire d'apporter des modifications qui peuvent entraîner une incompatibilité. Malheureusement, la lecture automatique des contenus audio est complexe et s'inscrit dans cette catégorie de modifications. Mais ce changement est essentiel pour que le Web ne stagne pas et ne perde pas son avantage innovant.
Toutefois, nous sommes conscients que l'application de correctifs pour les sites Web n'est pas toujours possible à court terme pour diverses raisons:
- Les développeurs Web peuvent être concentrés sur un nouveau projet, et la maintenance d'un ancien site Web n'est pas immédiatement possible.
- Les portails de jeux Web ne peuvent pas toujours contrôler l'implémentation des jeux de leur catalogue. La mise à jour de centaines, voire de milliers de jeux peut être longue et coûteuse pour les éditeurs.
- Certains sites Web peuvent simplement être très anciens et, pour une raison ou une autre, ne sont plus gérés, mais sont toujours hébergés à des fins d'historique.
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. Ce code doit être exécuté avant la création d'objets AudioContext dans votre page Web. Par exemple, vous pouvez ajouter ce code à 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 reprendre les AudioContexts 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 de règles, nous introduisons également un mécanisme permettant aux utilisateurs de désactiver la règle sur la lecture automatique dans les cas où l'apprentissage automatique ne fonctionne pas comme prévu ou pour les sites Web qui deviennent inutilisables en raison de ce changement. Ce changement sera déployé avec la nouvelle règle dans Chrome 71 et sera disponible dans les paramètres audio. Les sites pour lesquels l'utilisateur souhaite autoriser la lecture automatique pourront être ajoutés à la liste d'autorisation.
Comment le MEI est-il construit pour les nouveaux utilisateurs ?
Comme indiqué précédemment, nous construisons automatiquement l'intent utilisateur au fil du temps en fonction du comportement de l'utilisateur afin d'anticiper son intention souhaitée concernant un site Web donné avec du contenu en lecture automatique. Chaque site Web reçoit un score compris entre zéro et un dans cet indice. Des scores plus élevés indiquent que l'utilisateur s'attend à ce que le contenu soit diffusé à partir de ce site Web.
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édéfinie basée sur des scores MEI agrégatifs anonymisés est utilisée pour déterminer les sites Web pouvant être lus automatiquement. Ces données ne déterminent que l'état initial du MEI lors de la création du profil utilisateur. Lorsque l'utilisateur navigue sur le Web et interagit avec des sites Web proposant des contenus en lecture automatique, son MEI personnel remplace la configuration par défaut.
La liste de sites prédéfinis est générée par algorithme, et non sélectionnée manuellement. Tout site Web peut y figurer. Les sites sont ajoutés à la liste si suffisamment d'utilisateurs qui les consultent autorisent la lecture automatique sur ces sites. 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 le raisonnement derrière cette règle. ainsi qu'une nouvelle documentation sur le fonctionnement de la liste de sites pré-sélectionnés.
Nous mettons toujours nos utilisateurs au premier plan, mais nous ne voulons pas non plus décevoir la communauté de développement Web. En tant que navigateur, vous devez parfois équilibrer ces deux objectifs avec soin. Nous pensons que les ajustements que nous avons apportés à l'implémentation du règlement et le temps supplémentaire que nous avons accordé aux développeurs audio Web pour mettre à jour leur code nous permettront d'atteindre cet équilibre avec Chrome 71.