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?



Reply via email to