Re: FW: Beacon API

For those who want to follow the discussion:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg391

ig

On Wed, Feb 13, 2013 at 8:06 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  As a part of exploring the Beacon API, Alois and I have considered first
> reaching out to the Web Apps WG to see if we can update the XHR Level 2
> specification, instead of inventing a new way to send data. I’ve started
> the below thread with the Web Apps WG. ****
>
> ** **
>
> Thanks,****
>
> Jatinder****
>
> ** **
>
> *From:* Jatinder Mann
> *Sent:* Wednesday, February 13, 2013 8:03 AM
> *To:* 'annevk@opera.com'; 'public-webapps@w3.org'
> *Cc:* Reitbauer, Alois (Alois.Reitbauer@compuware.com)
> *Subject:* Beacon API****
>
> ** **
>
> 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/ ****
>
> ** **
>