Re: Beacon API

On Wed, Feb 13, 2013 at 8:03 AM, Jatinder Mann <jmann@microsoft.com> wrote:
> The Web Performance working group has been tracking a known poor performance
> pattern involving XHRs.
>
> We have seen cases where analytics code will block the unloading of the
> document in order to send data. To guarantee that the data is sent to their
> servers, analytics will typically register a handler on the unload event,
> which will make a synchronous XHR call to submit the data. The synchronous
> XHR forces the browser to delay unloading the document, and makes the next
> navigation appear to be slower. There is little the next page can do to
> avoid this perception of poor page load performance.
>
> Frankly, analytics don’t have many good options. Browsers will typically
> just ignore asynchronous XHR in an unload handler. Sending the data too soon
> may mean that they miss out on some data gathering opportunities. To solve
> this problem, the Web Performance WG has included writing a Beacon API in
> its charter [1]. This API would be an interoperable means for site
> developers to asynchronously transfer data from the user agent to a web
> server, with a guarantee from the user agent that the data will be
> eventually sent.
>
> However, instead of inventing a new way to send data, it may make sense to
> first explore whether we can update XHR to help in this scenario. This
> change could be as simple as adding an optional parameter to XHR, a new type
> of XHR (e.g., BeaconXHLHttpRequest), or just normative text on the expected
> user agent behavior when a synchronous XHR call is made in the unload event
> handler.
>
> How interested is this working group in taking on such work in the XHR Level
> 2 [2] specification?

I started a thread last year in WHATWG about this subject, though from
a slightly different angle:
<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035686.html>.
 The analytics use-case is a good one.

~TJ

Received on Wednesday, 13 February 2013 16:46:27 UTC