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