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

RE: [Beacon] spec feedback + few suggestions

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 30 Oct 2013 22:50:22 +0000
To: Ilya Grigorik <igrigorik@google.com>
CC: Chase Douglas <chase@newrelic.com>, public-web-perf <public-web-perf@w3.org>, Jonas Sicking <jonas@sicking.cc>
Message-ID: <e09d45b7c89c42a8b695bc64d6897eed@BLUPR03MB065.namprd03.prod.outlook.com>
On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> I think the above is too broad, and should be scoped to something like: "... to asynchronously transfer
> small (<TBD KB) HTTP payloads (typically, analytics beacons) from the user agent to a web server ..."

I agree that the current abstract is a bit too broad. I'll update it.

On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> Large background uploads are a liability for the UA and something that we don't want to allow -- the app
> should handle large uploads, and there are parallel efforts (ServiceWorker, Alarm API) that are much better
> suited to tackle this problem. On the other hand, we do know that there are a lot of small HTTP transfers
> (typically, analytics related) which if made async would have significant positive impact on web performance -
> that's what we need to solve in this spec.


On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> I would be careful with calling AsyncSend() because I think it overpromises on functionality.
> ...
> As far as the name goes, I'm not attached to Beacon, but I do think it should feel different enough to capture the
> above semantics.

We can keep the function name as beacon or sendBeacon for now and wait until we hear a better name.

On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> Perhaps one thing to consider is to provide some guidance on possible delays. For example, if I want to use
> Beacon for ~real-time analytics, small delays (on the order of 0-300s) may be acceptable, but I wouldn't want
> to get the notification 15 minutes after the fact. A simple strategy would be: deliver beacons next time the radio
> is available, or flush the beacon queue every X seconds.

Do you think "best effort" is good enough? On the other thread, there is an idea of passing in a timeout argument after which the user agent won't attempt to send the data. At least you'll know it's a failure if you haven't received the data in that window.

On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> Right, exactly what we're trying to guard against.. Don't have a number yet, but I've reached out to the Google
> Analytics team to see if they can provide some stats on what they see for their pings.

It would be great if we can base our limit on data.

Received on Wednesday, 30 October 2013 22:50:57 UTC

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