Re: Beacon API

A lot of the discussion so far focused on the async analytics beacon +
unload use case. However, while this is an important case to consider,
let's not constrain this proposal to "on unload" case only.

Effectively, what we want is a generic "send this request sometime later, I
don't care when", where "sometime" could be after the page has unloaded, or
even during the lifetime of the page. Why would we want such a thing?

One of the largest anti-patterns in the mobile world, when it comes to
battery performance, is the inefficiency of periodic transfers: your app
occasionaly wakes up and has to cycle to full power state to send an
intermittent ping (audience measurement, analytics, whatever). These
periodic pings can easily dominate the battery consumption over the actual
resource fetch for any page or app.

By allowing an API which says "sometime later", the browser is then able to
aggregate multiple beacon requests (from many apps, tabs, or whatever
aggregation mechanism it choose to employ), and then periodically dispatch
these requests in one shot.

Something as simple as "defer" flag on an XHR would be sufficient - no
promises as to when it'll run, no success / error callbacks, etc.

ig