Em setembro de 2017, anunciamos uma mudança na forma como o áudio seria processado com a política de comportamento de reprodução automática no Chrome. A mudança na política foi lançada com o Chrome 66 Stable em maio de 2018.
Após recebermos feedback da comunidade de desenvolvimento do Web Audio, adiamos o lançamento da parte do Web Audio da política de reprodução automática para dar mais tempo aos desenvolvedores atualizarem os sites. Também fizemos algumas mudanças na implementação da política para Web Audio, o que vai reduzir o número de sites que precisam ajustar o código, principalmente jogos da Web, e, portanto, oferecer uma experiência melhor aos nossos usuários.
Essa mudança na política está programada para ser lançada com o Chrome 71 em dezembro de 2018.
O que a mudança na política faz exatamente?
Autoplay é o nome dado a um conteúdo que é reproduzido imediatamente após o carregamento de uma página da Web. Para sites que esperam poder reproduzir o conteúdo automaticamente, essa mudança vai impedir a reprodução por padrão. Na maioria dos casos, a reprodução é retomada, mas em outros, um pequeno ajuste no código é necessário. Especificamente, os desenvolvedores precisam adicionar um código que retome o conteúdo se o usuário interagir com a página da Web.
No entanto, se o usuário chegar a uma página com conteúdo de reprodução automática e navegar para essa página de uma página da mesma origem, esse conteúdo nunca será bloqueado. Leia nossa postagem anterior sobre a política de reprodução automática para mais exemplos detalhados.
Além disso, adicionamos uma heurística para aprender com o comportamento anterior dos usuários em relação a sites que iniciam áudio automaticamente. Detectamos quando os usuários deixam o áudio tocar por mais de 7 segundos durante a maioria das visitas a um site e ativamos o recurso de reprodução automática nesse site.
Fazemos isso com um índice armazenado localmente por perfil do Chrome em um dispositivo. Ele não é sincronizado entre dispositivos e é compartilhado apenas como parte das estatísticas de usuários anonimizadas. Chamamos esse índice de Índice de engajamento de mídia (MEI, na sigla em inglês). Ele pode ser acessado em chrome://media-engagement.
O MEI monitora quantas visitas a um site incluem a reprodução de áudio com mais de 7 segundos. Com base no MEI de um usuário, acreditamos que podemos entender se ele espera áudio de um site específico ou não e antecipar a intenção dele no futuro.
Se o usuário permitir que o domínio de um site reproduza áudio por mais de sete segundos, vamos presumir que ele espera que esse site tenha o direito de reproduzir áudio automaticamente. Portanto, concedemos a esse site o direito de reproduzir áudio automaticamente sem exigir que o usuário interaja com uma guia desse domínio.
No entanto, esse direito não é garantido indefinidamente. Se o comportamento do usuário mudar, por exemplo, se ele parar a reprodução de áudio ou fechar a guia dentro do limite de 7 segundos ao longo de várias visitas, o direito de reprodução automática do site será removido.
O uso de elementos HTML de mídia (vídeo e áudio) e do Web Audio (objetos AudioContext instanciados do JavaScript) contribui para o MEI. Em preparação para o lançamento desta política, o comportamento do usuário em relação ao Web Audio vai começar a contribuir para o MEI a partir do Chrome 70. Isso garante que já possamos antecipar a intenção desejada do usuário em relação à reprodução automática e aos sites que ele costuma visitar.
Os iframes só podem ter o direito de reprodução automática sem interação do usuário se a página principal que incorpora o iframe estender esse direito ao iframe em questão.
Atraso na mudança para apoiar a comunidade
A comunidade de desenvolvedores de áudio da Web, principalmente os desenvolvedores de jogos e do WebRTC, notaram essa mudança quando ela apareceu no canal estável do Chrome.
O feedback da comunidade foi de que muitos jogos e experiências de áudio na Web seriam afetados negativamente por essa mudança. Especificamente, muitos sites que não foram atualizados não reproduziriam mais áudio para os usuários. Por isso, nossa equipe decidiu adiar essa mudança para que os desenvolvedores de áudio da Web tivessem mais tempo para atualizar os sites.
Além disso, aproveitamos o tempo para:
- Considere seriamente se essa mudança de política foi a melhor opção ou não.
- Analise maneiras de reduzir o número de sites com áudio que seriam afetados.
No caso da primeira, decidimos que a mudança na política é realmente necessária para melhorar a experiência da maioria dos usuários. Confira mais detalhes sobre o problema que a mudança na política está resolvendo na próxima seção deste artigo.
Para o segundo caso, fizemos um ajuste na nossa implementação do Web Audio que vai reduzir o número de sites afetados originalmente. Dos sites que sabemos que foram corrompidos pela mudança, muitos foram fornecidos como exemplos pela comunidade de desenvolvimento de jogos da Web. Com esse ajuste, mais de 80% deles funcionaram automaticamente. Confira nossa análise e testes destes sites de exemplo. Confira mais detalhes sobre esse novo ajuste abaixo.
Também fizemos uma mudança para oferecer suporte a aplicativos WebRTC. Enquanto houver uma sessão de captura ativa, a reprodução automática será permitida.
Qual problema essa mudança de comportamento pretende resolver?
Historicamente, os navegadores não ajudam muito o usuário a gerenciar o som. Quando os usuários abrem uma página da Web e recebem um som que não esperavam ou não queriam, a experiência do usuário é ruim. Essa experiência ruim do usuário é o problema que estamos tentando resolver. O ruído indesejado é o principal motivo pelo qual os usuários não querem que o navegador reproduza conteúdo automaticamente.
No entanto, às vezes os usuários querem que o conteúdo seja reproduzido automaticamente, e um número significativo de reprodução automáticas bloqueadas no Chrome são reproduzidas pelo usuário posteriormente.
Portanto, acreditamos que, ao aprender com o usuário e antecipar a intenção dele em cada site, podemos criar a melhor experiência. Se os usuários tendem a reproduzir conteúdo de um site, vamos ativar o recurso de reprodução automática para esse site no futuro. Por outro lado, se os usuários tendem a interromper a reprodução automática de conteúdo de um determinado site, vamos impedir a reprodução automática desse conteúdo por padrão.
Uma proposta apresentada pela comunidade foi desativar o áudio de uma guia em vez de pausar a reprodução automática. No entanto, acreditamos que é melhor interromper a experiência de reprodução automática para que o site saiba que ela foi bloqueada e permita que o desenvolvedor do site reaja a isso. Por exemplo, alguns desenvolvedores podem querer simplesmente silenciar o áudio, enquanto outros podem preferir que o conteúdo de áudio seja pausado até que o usuário interaja ativamente com ele. Caso contrário, o usuário pode perder parte da experiência de áudio.
Novos ajustes para ajudar desenvolvedores de jogos da Web
A maneira mais comum de os desenvolvedores usarem a API Web Audio é criando dois tipos de objetos para reproduzir áudio:
- Um AudioContext
- E AudioNodes, que são anexados a um contexto
Os desenvolvedores de áudio da Web vão criar um AudioContext para reproduzir áudio. Para retomar o áudio depois que a política de reprodução automática suspender automaticamente o AudioContext, é necessário chamar a função resume() nesse objeto depois que o usuário interagir com a guia:
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');
});
});
Há muitas interfaces que herdam de AudioNode, uma delas é a interface AudioScheduledSourceNode. Os AudioNodes que implementam a interface AudioScheduledSourceNode são comumente chamados de nós de origem (como AudioBufferSourceNode, ConstantSourceNode e OscillatorNode). Os nós de origem implementam um método start().
Os nós de origem geralmente representam fragmentos de áudio individuais que os jogos tocam, por exemplo: o som que é reproduzido quando um jogador coleta uma moeda ou a música de fundo que toca no estágio atual. É muito provável que os desenvolvedores de jogos chamem a função start() em nós de origem sempre que algum desses sons for necessário para o jogo.
Depois de reconhecer esse padrão comum em jogos da Web, decidimos ajustar nossa implementação para o seguinte:
Um AudioContext será retomado automaticamente quando duas condições forem atendidas:
- O usuário interagiu com uma página.
- O método start() de um nó de origem é chamado.
Devido a essa mudança, a maioria dos jogos da Web vai retomar o áudio quando o usuário começar a jogar.
Avançando na Web
Para avançar na plataforma da Web, às vezes é necessário fazer mudanças que podem afetar a compatibilidade. Infelizmente, a reprodução automática de áudio é complexa e se enquadra nessa categoria de mudança. No entanto, essa mudança é fundamental para garantir que a Web não estagne ou perca sua vantagem inovadora.
No entanto, reconhecemos que aplicar correções em sites nem sempre é viável no curto prazo por vários motivos:
- Os desenvolvedores da Web podem estar focados em um novo projeto, e a manutenção de um site mais antigo não é possível imediatamente.
- Os portais de jogos da Web podem não ter controle sobre a implementação dos jogos no catálogo, e atualizar centenas ou até milhares de jogos pode ser demorado e caro para os editores.
- Alguns sites podem ser muito antigos e, por um motivo ou outro, não são mais mantidos, mas ainda são hospedados para fins históricos.
Este é um snippet de código JavaScript curto que intercepta a criação de novos objetos AudioContext e aciona automaticamente a função de retomada desses objetos quando o usuário realiza várias interações. Esse código precisa ser executado antes da criação de qualquer objeto AudioContext na página da Web. Por exemplo, você pode adicionar esse código à tag da página da 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);
});
})();
Esse snippet de código não vai ajudar a retomar AudioContexts que são instanciados em um iframe, a menos que ele seja incluído no escopo do conteúdo do próprio iframe.
Melhor atendimento aos nossos usuários
Para acompanhar a mudança na política, também estamos introduzindo um mecanismo para os usuários desativar a política de reprodução automática nos casos em que o aprendizado automático não está funcionando como esperado ou para sites que ficam inutilizáveis devido à mudança. Essa mudança será lançada com a nova política no Chrome 71 e pode ser encontrada nas "Configurações de som". Os sites em que o usuário quer permitir a reprodução automática podem ser adicionados à lista "Permitir".
Como o MEI é construído para novos usuários?
Como mencionado anteriormente, criamos a MEI automaticamente ao longo do tempo com base no comportamento do usuário para antecipar a intenção desejada em relação a um determinado site com conteúdo de reprodução automática. Cada site tem uma pontuação entre zero e um nesse índice. Pontuações mais altas indicam que o usuário espera que o conteúdo seja reproduzido nesse site.
No entanto, para novos perfis de usuário ou se um usuário limpar os dados de navegação, em vez de bloquear a reprodução automática em todos os lugares, uma lista de pré-sementes baseada nas pontuações MEI agregadas do usuário anônimo é usada para determinar quais sites podem fazer a reprodução automática. Esses dados determinam apenas o estado inicial do MEI na criação do perfil do usuário. À medida que o usuário navega na Web e interage com sites com conteúdo de reprodução automática, o MEI pessoal substitui a configuração padrão.
A lista de sites pré-selecionados é gerada por algoritmo, em vez de ser selecionada manualmente, e qualquer site pode ser incluído. Os sites são adicionados à lista se um número suficiente de usuários que os visitam permitirem a reprodução automática. Esse limite é baseado em porcentagem para não favorecer sites maiores.
Encontrar o equilíbrio
Postamos uma nova documentação para dar mais informações sobre nosso processo de tomada de decisão e o raciocínio por trás do design dessa política. Além de uma nova documentação sobre como funciona a lista de sites pré-preenchidos.
Sempre colocamos nossos usuários em primeiro lugar, mas também não queremos decepcionar a comunidade de desenvolvimento da Web. Às vezes, ser o navegador significa que esses dois objetivos precisam ser cuidadosamente equilibrados. Acreditamos que, com nossos ajustes na implementação da política e o tempo extra que demos para os desenvolvedores de áudio da Web atualizarem o código, vamos alcançar esse equilíbrio com o Chrome 71.