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, 17 Nov 2013 08:57:26 -0800
Message-ID: <5288F576.40609@gmail.com>
To: Ilya Grigorik <igrigorik@google.com>
CC: "Reitbauer, Alois" <Alois.Reitbauer@compuware.com>, Jatinder Mann <jmann@microsoft.com>, "Austin, Daniel" <daaustin@paypal.com>, Jonas Sicking <jonas@sicking.cc>, Chase Douglas <chase@newrelic.com>, public-web-perf <public-web-perf@w3.org>
Le 10/11/2013 18:41, Ilya Grigorik a écrit :
>
> On Sun, Nov 10, 2013 at 12:57 PM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>
>>     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.
>
>
> That's not entirely true. Yes, in theory you can patch XHR such that 
> next time you make a request you also flush some pending queue of 
> beacons, but this is (a) non-trivial to implement / error-prone, and 
> (b) does not work across multiple apps / tabs - e.g. if you have 
> multiple beacons firing across multiple open tabs/apps, sendBeacon can 
> aggregate those events and dispatch them all at once.
I meant to say that all network requests (including beacons and XHR, but 
not limited to) could be better scheduled. My point above suggested that 
it could be done automatically, but I understand why that would be a lot 
of work. Hence my idea of a generic request scheduling feature.

David
Received on Sunday, 17 November 2013 16:58:00 UTC

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