W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Beacon API

From: Ilya Grigorik <igrigorik@google.com>
Date: Thu, 14 Feb 2013 16:21:07 -0800
Message-ID: <CADXXVKqHZWX2Wohz7e+-fdK-zQ+qSzHjy6wDhHfQQi4PZOOm2A@mail.gmail.com>
To: public-webapps@w3.org
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
Received on Friday, 15 February 2013 00:22:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT