Re: FW: Beacon API

Are there other use cases besides Analytics? Anne's comment about <a ping>
is interesting. I think the fact that it could be disabled makes it
unreliable enough to be used by web publishers - something to keep in mind
for this new API.


On Thu, Feb 14, 2013 at 4:25 PM, Ilya Grigorik <igrigorik@google.com> wrote:

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