In september 2017 hebben we een aanstaande wijziging aangekondigd in de manier waarop audio zou worden afgehandeld met het gedragsbeleid voor automatisch afspelen in Chrome. De beleidswijziging werd in mei 2018 uitgebracht met Chrome 66 Stable.
Na feedback van de Web Audio-ontwikkelgemeenschap hebben we de release van het Web Audio-gedeelte van het autoplay-beleid uitgesteld om ontwikkelaars meer tijd te geven om hun websites bij te werken. We hebben ook enkele wijzigingen aangebracht in de implementatie van het beleid voor webaudio, waardoor het aantal websites dat hun code moet aanpassen (vooral webgames) zal afnemen en daardoor een betere ervaring voor onze gebruikers zal worden geboden.
Het is nu de bedoeling dat deze beleidswijziging in december 2018 wordt uitgerold voor Chrome 71 .
Wat houdt de beleidswijziging precies in?
Autoplay is de naam die wordt gegeven aan een stukje inhoud dat onmiddellijk wordt afgespeeld bij het laden van een webpagina. Voor websites waarvan werd verwacht dat ze hun inhoud automatisch konden afspelen, zal deze wijziging het afspelen standaard voorkomen. In de meeste gevallen wordt het afspelen hervat, maar in andere gevallen is een kleine aanpassing aan de code nodig. Concreet moeten ontwikkelaars code toevoegen die hun inhoud hervat als de gebruiker interactie heeft met de webpagina.
Als de gebruiker echter op een pagina terechtkomt met automatisch afgespeelde inhoud en naar die pagina is genavigeerd vanaf een pagina van dezelfde oorsprong, wordt die inhoud nooit geblokkeerd. Lees onze eerdere blogpost over het autoplay-beleid voor meer gedetailleerde voorbeelden .
Daarnaast hebben we een heuristiek toegevoegd om te leren van het eerdere gedrag van gebruikers met betrekking tot websites die audio automatisch afspelen. We detecteren wanneer gebruikers tijdens de meeste bezoeken aan een website regelmatig audio langer dan zeven seconden laten afspelen, en schakelen automatisch afspelen in voor die website.
We doen dit met een index die lokaal per Chrome-profiel op een apparaat wordt opgeslagen. Deze wordt niet gesynchroniseerd tussen apparaten en wordt alleen gedeeld als onderdeel van de geanonimiseerde gebruikersstatistieken. Deze index noemen we de Media Engagement Index (MEI) en je kunt deze bekijken via chrome://media-engagement.
MEI houdt bij hoeveel bezoeken aan een site een audioweergave bevatten die langer dan 7 seconden duurt. Op basis van de MEI van een gebruiker denken we te kunnen begrijpen of een gebruiker audio van een bepaalde website verwacht of niet – en te kunnen anticiperen op de bedoelingen van de gebruiker in de toekomst.
Als de gebruiker het domein van een website vaak langer dan 7 seconden audio laat afspelen, gaan we ervan uit dat de gebruiker in de toekomst verwacht dat deze website het recht heeft om audio automatisch af te spelen. Daarom verlenen we die website het recht om audio automatisch af te spelen zonder dat de gebruiker interactie heeft met een tabblad van dat domein.
Dit recht is echter niet voor onbepaalde tijd gegarandeerd. Als het gedrag van de gebruiker verandert – bijvoorbeeld het stoppen van het afspelen van audio of het sluiten van het tabblad binnen de drempel van zeven seconden in de loop van meerdere bezoeken – verwijderen we het recht van de website om automatisch af te spelen.
Zowel het gebruik van media-HTML-elementen (video en audio) als webaudio (door JavaScript geïnstantieerde AudioContext-objecten) zullen bijdragen aan de MEI. Ter voorbereiding op de uitrol van dit beleid zal gebruikersgedrag met betrekking tot webaudio vanaf Chrome 70 en later gaan bijdragen aan de MEI. Dit zorgt ervoor dat we al kunnen anticiperen op de gewenste intentie van de gebruiker met betrekking tot autoplay en de websites die ze vaak bezoeken.
Opgemerkt moet worden dat iframes alleen het recht kunnen krijgen om automatisch af te spelen zonder tussenkomst van de gebruiker als de bovenliggende webpagina die het iframe insluit , dat recht uitbreidt naar het gegeven iframe .
Veranderingen uitstellen om de gemeenschap te ondersteunen
De Web Audio-ontwikkelaarsgemeenschap (met name de webgame-ontwikkelaars en WebRTC-ontwikkelaarsgedeelten van deze community) merkte op toen deze wijziging verscheen in het Chrome Stable-kanaal.
De feedback van de community was dat veel webgames en webaudio-ervaringen negatief zouden worden beïnvloed door deze verandering; met name veel sites die niet waren bijgewerkt, zouden niet langer audio afspelen voor gebruikers. Als gevolg hiervan besloot ons team dat het de moeite waard was om deze wijziging uit te stellen, zodat webaudio-ontwikkelaars meer tijd krijgen om hun websites bij te werken.
Daarnaast hebben we deze tijd gebruikt om:
- Overweeg serieus of deze beleidswijziging de beste handelwijze was of niet.
- Ontdek manieren waarop we kunnen helpen het aantal websites met audio dat hierdoor wordt beïnvloed, te verminderen.
Voor het eerstgenoemde hebben we uiteindelijk besloten dat de beleidswijziging inderdaad noodzakelijk is om de gebruikerservaring voor de meerderheid van onze gebruikers te verbeteren. Meer details over welk probleem de beleidswijziging oplost, kunt u lezen in het volgende gedeelte van dit artikel.
Voor dit laatste hebben we een aanpassing gedaan in onze implementatie voor Web Audio, waardoor het aantal websites dat oorspronkelijk getroffen werd, zal afnemen. Van de sites waarvan we wisten dat ze kapot waren door de verandering – waarvan er vele als voorbeeld werden gegeven door de gemeenschap van webgame-ontwikkelaars – betekende deze aanpassing dat meer dan 80% ervan automatisch zou werken. Onze analyse en testen van deze voorbeeldsites kunt u hier bekijken . Deze nieuwe aanpassing wordt hieronder nader beschreven.
We hebben ook een wijziging aangebracht om WebRTC-applicaties te ondersteunen; zolang er een actieve opnamesessie is, is autoplay toegestaan.
Welk probleem wil deze gedragsverandering oplossen?
Browsers zijn van oudsher slecht in het helpen van de gebruiker bij het beheren van geluid. Wanneer gebruikers een webpagina openen en geluid ontvangen dat ze niet hadden verwacht of gewenst, hebben ze een slechte gebruikerservaring. Deze slechte gebruikerservaring is het probleem dat we proberen op te lossen. Ongewenste ruis is de belangrijkste reden dat gebruikers niet willen dat hun browser inhoud automatisch afspeelt.
Soms willen gebruikers echter dat inhoud automatisch wordt afgespeeld, en vervolgens wordt een aanzienlijk aantal geblokkeerde autoplays in Chrome door de gebruiker afgespeeld.
Daarom geloven wij dat we door van de gebruiker te leren – en per website te anticiperen op hun intentie – de beste gebruikerservaring kunnen creëren. Als gebruikers de neiging hebben om inhoud van een website af te spelen, zullen we in de toekomst de inhoud van die site automatisch afspelen. Omgekeerd, als gebruikers de neiging hebben om het automatisch afspelen van inhoud van een bepaalde website te stoppen, zullen we het automatisch afspelen van die inhoud standaard voorkomen.
Eén voorstel van de community is om de audio van een tabblad te dempen in plaats van het automatisch afspelen te onderbreken. Wij zijn echter van mening dat het beter is om de autoplay-ervaring te stoppen, zodat de website weet dat de autoplay is geblokkeerd en de website-ontwikkelaar hierop kan reageren. Terwijl sommige ontwikkelaars bijvoorbeeld de audio simpelweg willen dempen, geven andere ontwikkelaars er misschien de voorkeur aan dat hun audio-inhoud wordt gepauzeerd totdat de gebruiker actief met de inhoud bezig is – anders mist de gebruiker mogelijk een deel van de audio-ervaring.
Nieuwe aanpassingen om ontwikkelaars van webgames te helpen
De meest voorkomende manier waarop ontwikkelaars de Web Audio API gebruiken, is door twee soorten objecten te maken om audio af te spelen:
- Een audiocontext
- En AudioNodes , die aan een context zijn gekoppeld
Webaudio-ontwikkelaars zullen een AudioContext creëren voor het afspelen van audio. Om hun audio te hervatten nadat het autoplay-beleid hun AudioContext automatisch heeft opgeschort, moeten ze de CV()-functie op dit object aanroepen nadat de gebruiker interactie heeft gehad met het tabblad:
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');
});
});
Er zijn veel interfaces die overerven van AudioNode, waarvan er één de AudioScheduledSourceNode -interface is. AudioNodes die de AudioScheduledSourceNode-interface implementeren, worden gewoonlijk bronknooppunten genoemd (zoals AudioBufferSourceNode, ConstantSourceNode en OscillatorNode). Bronknooppunten implementeren een start() -methode.
Bronknooppunten vertegenwoordigen doorgaans individuele audiofragmenten die games afspelen, bijvoorbeeld: het geluid dat wordt afgespeeld wanneer een speler een munt verzamelt of de achtergrondmuziek die in de huidige fase wordt afgespeeld. Het is zeer waarschijnlijk dat game-ontwikkelaars de functie start() op bronknooppunten aanroepen wanneer een van deze geluiden nodig is voor het spel.
Toen we dit algemene patroon in webgames herkenden, besloten we onze implementatie aan te passen aan het volgende:
Een AudioContext wordt automatisch hervat als aan twee voorwaarden is voldaan:
- De gebruiker heeft interactie gehad met een pagina.
- De start()-methode van een bronknooppunt wordt aangeroepen.
Als gevolg van deze wijziging hervatten de meeste webgames nu hun audio wanneer de gebruiker de game begint te spelen.
Het web vooruit helpen
Om het webplatform vooruit te helpen, is het soms nodig om wijzigingen aan te brengen die de compatibiliteit kunnen verstoren. Helaas is het automatisch afspelen van audio complex en valt het in deze categorie van veranderingen. Maar deze verschuiving is van cruciaal belang om ervoor te zorgen dat het web niet stagneert of zijn innovatieve voorsprong verliest.
Niettemin erkennen we dat het toepassen van oplossingen voor websites om verschillende redenen niet altijd op de korte termijn haalbaar is:
- Webontwikkelaars kunnen gefocust zijn op een nieuw project en onderhoud aan een oudere website is niet direct mogelijk.
- Webgameportals hebben mogelijk geen controle over de implementatie van de games in hun catalogus en het updaten van honderden – zo niet duizenden – games kan tijdrovend en duur zijn voor uitgevers.
- Sommige websites zijn misschien gewoon heel oud en worden – om de een of andere reden – niet meer onderhouden, maar worden nog steeds gehost voor historische doeleinden.
Hier is een kort JavaScript-codefragment dat de creatie van nieuwe AudioContext-objecten onderschept en de hervattingsfunctie van deze objecten automatisch activeert wanneer de gebruiker verschillende gebruikersinteracties uitvoert. Deze code moet worden uitgevoerd voordat er AudioContext-objecten op uw webpagina worden gemaakt. U kunt deze code bijvoorbeeld toevoegen aan de
tag van uw webpagina:(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);
});
})();
Opgemerkt moet worden dat dit codefragment niet zal helpen bij het hervatten van AudioContexts die binnen een iframe zijn geïnstantieerd, tenzij dit codefragment is opgenomen binnen de reikwijdte van de inhoud van het iframe zelf.
Onze gebruikers beter van dienst zijn
Ter begeleiding van de beleidswijziging introduceren we ook een mechanisme waarmee gebruikers het autoplay-beleid kunnen uitschakelen voor gevallen waarin het automatische leren niet werkt zoals verwacht, of voor websites die door de wijziging onbruikbaar worden gemaakt. Deze wijziging wordt met het nieuwe beleid in Chrome 71 uitgerold en is te vinden in de Geluidsinstellingen; sites waar de gebruiker autoplay wil toestaan, kunnen worden toegevoegd aan de lijst Toestaan.
Hoe is de MEI opgebouwd voor nieuwe gebruikers?
Zoals eerder vermeld, bouwen we de MEI in de loop van de tijd automatisch op, op basis van het gedrag van de gebruiker, om te anticiperen op de gewenste intentie met betrekking tot een bepaalde website met autoplay-inhoud. Elke website heeft een score tussen nul en één in deze index. Hogere scores geven aan dat de gebruiker verwacht dat inhoud van die website wordt afgespeeld.
Voor nieuwe gebruikersprofielen of als een gebruiker zijn browsegegevens wist, wordt in plaats van autoplay overal te blokkeren, een pre-seed-lijst op basis van geanonimiseerde, door gebruikers verzamelde MEI-scores gebruikt om te bepalen welke websites autoplay kunnen gebruiken. Deze gegevens bepalen alleen de initiële status van de MEI bij het aanmaken van het gebruikersprofiel. Terwijl de gebruiker op internet surft en interactie heeft met websites met autoplay-inhoud, overschrijft zijn persoonlijke MEI de standaardconfiguratie.
De vooraf geplaatste sitelijst wordt algoritmisch gegenereerd in plaats van handmatig samengesteld, en elke website komt in aanmerking om te worden opgenomen. Sites worden aan de lijst toegevoegd als voldoende gebruikers die die site bezoeken autoplay op die site toestaan. Deze drempel is gebaseerd op een percentage, om grotere sites niet te bevoordelen.
Balans vinden
We hebben nieuwe documentatie geplaatst om meer inzicht te geven in ons besluitvormingsproces en de ontwerpgrondslag achter dit beleid. Evenals nieuwe documentatie over hoe de vooraf geplaatste sitelijst werkt .
We stellen onze gebruikers altijd op de eerste plaats, maar we willen ook de webontwikkelingsgemeenschap niet in de steek laten. Soms betekent het feit dat je de browser bent, dat deze twee doelen zorgvuldig met elkaar in evenwicht moeten worden gebracht. We zijn van mening dat we met onze aanpassingen aan de implementatie van het beleid en de extra tijd die we webaudio-ontwikkelaars hebben gegeven om hun code bij te werken, dit evenwicht zullen bereiken met Chrome 71.