W3C home > Mailing lists > Public > public-web-perf@w3.org > November 2013

Re: [Beacon] spec feedback + few suggestions

From: David Bruant <bruant.d@gmail.com>
Date: Sun, 10 Nov 2013 21:57:08 +0100
Message-ID: <527FF324.8010902@gmail.com>
To: "Reitbauer, Alois" <Alois.Reitbauer@compuware.com>, Jatinder Mann <jmann@microsoft.com>, "Austin, Daniel" <daaustin@paypal.com>, Ilya Grigorik <igrigorik@google.com>, Jonas Sicking <jonas@sicking.cc>, Chase Douglas <chase@newrelic.com>, public-web-perf <public-web-perf@w3.org>
Le 10/11/2013 21:13, Reitbauer, Alois a écrit :
> A bit late, but let me chime in here as well.
> Typically analytics beacons are set in the onunload or unbeforeunload 
> events. However, analytics also sends data while a page is active. 
> Typically you do this to avoid not getting data in case when the user 
> would simply close the browser.
This is already possible with xhr. The only thing sendBeacon adds is 
better scheduling for better battery use... and even that is arguable; 
an implementation could decide to better schedule xhrs.

> You also need to think about about single page applications. Sending 
> data on unload does not make sense in this case
This already works with xhr, no need for a new feature, except for the 
battery saving bit.
For single page apps, sending analytics is sometimes coupled with 
receiving server updates to do one round-trip instead of two; sendBeacon 
would be inappropriate there.

> Personally it does feel a bit weird to have a functionality like this 
> attached to an event rather the navigator object.
This idea was conditioned on the idea that sending beacons is already 
possible with xhr and that a more generic feature could emerge to 
schedule all network requests more efficiently (battery-wise or else).

I imagine beacons aren't the only battery killers; I feel this problem 
deserves its own solution. What do others think?

Received on Sunday, 10 November 2013 20:57:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC