Re: [Beacon] spec feedback + few suggestions

>  > // 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.
>

I would be careful with calling AsyncSend() because I think it overpromises
on functionality. In fact, since this has come up a few times both on the
thread and in the comments in the doc, I think we should clarify the intent
of the API. The current abstract says: *"This specification defines 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."*
*
*
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 ..."*

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.

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.

 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.
>

sg, don't have a strong opinion on this.


>   > 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.
>

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.


>  > 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.
>

+1. As Will pointed out, that statement simply describes how any HTTP
request works today.. So, we can skip it, unless we want to consider
explicitly describing some retry strategies that UA must follow (although
this may be too low-level and implementation details).


> **
>
> > 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.
>

Yup, I removed PUT due to preflight, but see no reason why it should not be
allowed on same origin.


>  > 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?
>

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.

ig



>  *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>
> 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****
>
>  ** **
>