Re: Beacon API

Some comments on the post:

First I do not think we need special markup for this. Analytics tools will
trigger this programatically. I am however not sure whether the update
handler would really work. It does not solve the problem of the cancelled
XHR requests. It will also not be enough to just send the request when the
page is unloaded as some code might need to be executed first. In some
case a single XHR request is also not enough. We have rare situations when
we need to send more than one request.

// Alois

On 2/13/13 5:45 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>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
>

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Gebäude G.

Received on Thursday, 14 February 2013 09:42:25 UTC