Autoplay
Update (November 22, 2018)
For the Web Audio API, the Autoplay Policy will launch in M71.
Update (May 15, 2018)
The Autoplay Policy launched in M66 Stable for <video> and <audio>
and is effectively blocking roughly half of unwanted media autoplays in Chrome.
For the Web Audio API, the autoplay policy will launch in M70. This affects web
games, some WebRTC applications, and other web pages using audio features.
Developers will need to
update their
code
to take advantage of the policy. More detail can be found in the Web Audio API
section below.
Summary
This policy controls when video and audio is allowed to autoplay, and is
designed to meet three primary goals:
- Provide user control over what content can autoplay
- Enable legitimate uses of autoplay without complicated workarounds
- Make progress towards consistent policies across mobile and desktop
platforms
Under the new policy media content will be allowed to autoplay under the
following conditions:
- The content is muted, or does not include any audio (video only)
- The user tapped or clicked somewhere on the site during the browsing
session
- On mobile, if the site has been
added to the Home
Screen
by the user
- On desktop, if the user has frequently played media on the site,
according to the
Media Engagement
Index
By default embedded IFrames will only be able to play muted or silent videos.
However, if site owners wish for IFrames on their site to be able to play
unmuted content, they may pass the autoplay permissions to the IFrame using
allow=autoplay
.
This attribute allows any video contained in the IFrame to play as if it were
hosted on the site.
For a more detailed design and rationale, please click
here
.
Autoplay blocking
Around the same time we will be making two additional changes related to
autoplay that will make muted autoplay more reliable. These two changes will
make it possible for sites and advertisers to use muted videos instead of
animated .gifs, which in most cases will reduce overall bandwidth consumption.
- Removing the block autoplay setting that is currently available on
Chrome for Android
- Removing autoplay blocking on mobile when data saver mode is enabled
Developer Recommendations: <video> and <audio>
- Use autoplay sparingly.
Autoplay can be a powerful engagement
tool, but it can also annoy users if undesired sound is played or
they perceive unnecessary resource usage (e.g. data, battery) as the
result of unwanted video playback.
- If you do want to use autoplay, consider
starting with muted
content and let the user unmute
if they are interested in
exploring more. This technique is being effectively used by numerous
sites and social networks.
- Unless there is a specific reason to do so, we recommend
using the
browser’s native controls for video and audio playback
. This will
ensure that autoplay policies are properly handled.
- If you are using custom media controls,
ensure that your website
functions properly when autoplay is not allowed.
We recommend that
you always look at the promise returned by the play function to see
if it was rejected:
var promise = document.querySelector('video').play();
if (promise !== undefined) {
promise.then(_ => {
// Autoplay started!
}).catch(error => {
// Autoplay was prevented.
// Show a "Play" button so that user can start playback.
});
}
Developer Recommendations: Web Audio API
The Web Audio API will be included in the Autoplay policy with M70 (October
2018). Generally, in Chrome developers can no longer assume that audio is
allowed to play when a user first arrives at a site, and should assume that
playback may be blocked until a user first interacts with the site through a
user activation (a click or a tap). Any attempt to create an audioContext before
that time may result in a suspended audioContext that will have to be explicitly
switched to running after a user activation.
Developers who write games, WebRTC applications, or other websites that use the
Web Audio API should call context.resume() after the first user gesture (e.g. a
click, or tap). For example:
// Resume playback when user interacted with the page.
document.querySelector('button').addEventListener('click', function() {
context.resume().then(() => {
console.log('Playback resumed successfully');
});
});
Web Audio API developers can detect whether or not autoplay is allowed by
creating a new AudioContext and then checking its state to see whether it is
running (allowed) or suspended (blocked).
Depending upon the site, it may make sense to add additional user interface
elements (such as a ‘play’ button in front of a game, or an ‘unmute’ button in
some other cases), to explicitly capture a user gesture. This can either be done
prior to creating AudioContext, or afterwards with a call to resume() upon
click.
IFrame embedded content
Embedded content in a cross-origin IFrame needs to have permission to autoplay
delegated to it, otherwise the audioContext will never be allowed to run.
Developers that host IFrames with content inside them (e.g. game hosting sites)
can enable audio for that content without requiring the underlying content to
change any code, by doing the following:
If the content is in a cross-origin IFrame, ensure that the IFrame includes
the attribute allow="autoplay"
Ensure that before the embedded content loads and runs, the site captures a
user gesture (e.g. prompt for a click or a tap)
Developers can find more details about specific code changes, and debugging tips
here
.
Web Audio API FAQs
Why is the Web Audio API part of the autoplay policy? Users don’t like to
click on a link and have sound played automatically that they weren’t
expecting. The Web Audio API produces sound, so it must be included in the
autoplay policy to ensure consistency across all web experiences.
Wait, didn’t you launch the autoplay policy for Web Audio API in M66? Yes,
briefly, but we reverted the change about a week later. We’re always working
to improve things for users and developers, but in this case we did not do
an effective job of communicating the change to developers using the Web
Audio API. We are moving the launch to October 2018 to give those developers
more time to prepare. If you develop web games, WebRTC applications, or
other web experiences with sound please see the developer recommendations.
Release Schedule
September 2017
|
New autoplay policies announced
|
Begin collecting Media Engagement Index (MEI) data in M62 Canary and Dev
|
December 2017
|
Site muting available in M64 Beta Autoplay policies available in M65 Canary and Dev
|
January 2018
|
Site muting available in M64 Stable
|
April 2018
|
Autoplay policies are enforced for <video> and <audio> in M66 Stable
|
October 2018
|
Autoplay policies will be enforced for Web Audio API in M70 Stable
|
General FAQs
- What is the difference between this and Chrome’s enforcement of
the
better ad standard
?
The current better ad standard states that sites cannot embed
stand-alone ads with unmuted
audio
.
This standard does not apply to content integral to the page (e.g.,
video of a news article that goes along with the text). The autoplay
policy is applicable to all video content regardless of its content.
- What is the MEI threshold and how will it apply to my site?
We
are still working on the implementation and don’t have any data yet
on what the threshold will be or how that will impact individual
sites. Our general guidance is if your site offers video content
exclusively, assume that autoplay will work. If it has mixed
content, assume it won’t unless users interact with the site in some
way.
- Can my site be exempted from the policy?
Unfortunately, Chrome
cannot provide any exceptions to the autoplay policy.
- What counts as "user interaction on the domain?"
Any click on
the document itself (this excludes scrolling) will count as user
interaction.
- Will autoplay work if a user leaves my site after watching video
and returns later in a browsing session.
Assuming the MEI
threshold hasn't been met, autoplay will not work in that context.
The user interaction requirement only applies to contiguous
navigations.
- Will gestures and/or MEI score apply across tabs/windows?
If the
user opens a link in a new tab via context menu, yes, the user
gesture will be counted and the MEI will reflect any views on the
new tab.
- How can I view my own MEI scores?
Navigate to
chrome://media-engagement to see your personal scores. Individual or
average scores will not be made available at this time.
More information
Autoplay policy summary
presentation
Autoplay design
document
Media engagement index (MEI) design
document
Autoplay Policy Changes
(developers.google.com)
DOMException: The play() request was interrupted
(developers.google.com)