Re: Beacon API

I'd personally be in favour of an optional parameter that would ask the
browser to keep on with the request even after the page has been unloaded
(which would be the only solution not to block unloading while ensuring
data is delivered even for asynchronous requests).

I'm not sure how feasibly this would be for implementors (we're talking
about a dangling connection outside of the lifecycle of the page). There is
also the question of knowing what happens when the browser is closed, not
to mention security concerns that will undoubtedly arise.

I also have no idea regarding the eventual name of this property. It's
difficult to convey the intent with a simple word.

Anyway, I agree this is a valid concern. It always bugged me. I too feel
like it makes sense to try and address this within the XHR spec.

On 13 February 2013 17:03, 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?****
>
> ** **
>
> Thanks,****
>
> Jatinder****
>
> ** **
>
> [1] http://www.w3.org/wiki/Web_Performance/Charter#Beacon ****
>
> [2] http://www.w3.org/TR/XMLHttpRequest2/ ****
>
> ** **
>