Re: Beacon API

I don't think that a link would work here as the user will not click it.  It is really about a reliable communication means. Why do you want to make it unreliable?

// Alois

From: Arvind Jain <arvind@google.com<mailto:arvind@google.com>>
Date: Friday, February 15, 2013 2:17 AM
To: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>
Cc: Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>>, "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>, Alois Reitbauer <alois.reitbauer@compuware.com<mailto:alois.reitbauer@compuware.com>>
Subject: 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<mailto: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<mailto: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<mailto:annevk@opera.com>'; 'public-webapps@w3.org<mailto:public-webapps@w3.org>'
Cc: Reitbauer, Alois (Alois.Reitbauer@compuware.com<mailto: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/




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.