RE: [Beacon] spec feedback + few suggestions

Thanks Ilya and Jonas for reviewing the spec and putting together this feedback. It would be great if we can discuss the feedback on the mailing list directly to get more visibility.

> // Move from window.beacon() to navigator.sendBeacon(), or something similar
> // to reduce chance of collision with existing user code.

I have actually heard feedback that the "beacon" name isn't very clear, and there maybe conflicts with existing "beacons". What do you think about AsyncSend()? It captures the intention of the API well.

Looks like navigator is mostly used to share data on the user agent's state. To reduce conflicts, we can move the AsyncSend/beacon method under the Performance interface? That has the added benefit of implying the method as a performance feature.

I can move the url parameter to be the first argument and set "GET" as the default verb.

> Beacons are fire and forget
I like the feedback that the beacon should be sent at earliest opportunity, but the UA can choose to defer it if required to conserve power. I will update the spec.

> If the UA has successfully dispatched beacon HTTP request, then it is marked as successful regardless of server return code
I'll make sure the spec call this out.

The current spec states that the beacon is an "interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with the user agent taking the responsibility to eventually send the data." This may be confusing as it can be interpreted to mean that we will re-send multiple times. I think we should change the "responsibility" to instead "best effort". The spec should probably also call out that if the browser session is ended before the beacon is sent, we will not try again.

> In order to keep things simple we could apply the same limitations for same-origin requests as we have for cross-origin requests.
I can understand that we should limit cross-origin verbs to {POST, GET}, but I don't think we should limit same origin to not use PUT.

> Beacon API should limit size of send payload to <TBD> KB
I agree that we should add a limit. I've heard feedback where some folks were hoping to use this API to do large background uploads. Adding a limit would prevent this kind of abuse of the API. What is a decent limit?

Thanks,
Jatinder


From: Chase Douglas [mailto:chase@newrelic.com]
Sent: Wednesday, October 30, 2013 10:40 AM
To: Ilya Grigorik
Cc: public-web-perf; Jonas Sicking
Subject: Re: [Beacon] spec feedback + few suggestions

I made some comments in the doc itself. Is this alright, or should we be sending all comments to the list?

Thanks!

On Wed, Oct 30, 2013 at 10:27 AM, Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>> wrote:
Google search is rolling out <a ping> to mobile clients that support it and based on our measurements its saving 200-400ms on every click [1]. The latency savings by themselves are, of course, a huge win, but just as importantly, our metrics also show a significant improvement in number of successful navigations (one less redirect to go wrong + faster load of destination site).

a) Above should address the previously raised concerns over usefulness of <a ping> (and by implication, Beacon).
b) <a ping> lacks cross-browser support (limited to Safari and Chrome), which makes deployment a non-trivial exercise.

As a result, I believe that having a cross-browser implementation of Beacon API would be a big performance win. Plus, Beacon is also much more flexible and would enable many additional optimization opportunities, including optimizing for battery life of mobile handsets... In short, we need Beacon API!

On that note, Jonas and myself have put together a doc outlining some feedback and suggestions on current proposal:
https://docs.google.com/document/d/1KSDg9ji53l-IrL6U5g1vvD96KIbZoQj1iUX4KwVvORM/edit#<https://docs.google.com/document/d/1KSDg9ji53l-IrL6U5g1vvD96KIbZoQj1iUX4KwVvORM/edit>

Would love to hear any thoughts or feedback.

ig

[1] https://plus.google.com/+IlyaGrigorik/posts/fPJNzUf76Nx