Intent to Ship: Beacon

[Sigbjorn Finne]

[ With Firefox now shipping Beacon, I think it is time to consider doing
same. ]

Contact emails

sigb...@opera.com

Spec

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html

Summary

Some web apps need to sync/flush state during document unload. The
existing mechanisms used to accomplish that (sync XHRs, image loads) in
document unload handlers aren't reliable and do slow down page navigation.
The Beacon API (navigator.sendBeacon()) tries to address that by
providing a method for the UA to asynchronously transmit such data,
without blocking page navigation.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Vdi7F7Mk_rM

Is this feature supported on all five Blink platforms (Windows, Mac, Linux,
Chrome OS and Android)?

Yes.

Demo link

None available right now.


Compatibility Risk

Firefox is shipping Beacon as of version 31 (stable release as of
2014-07-22).

OWP launch tracking bug?

http://crbug.com/360603

Link to entry on the feature dashboard <http://www.chromestatus.com/>

http://www.chromestatus.com/features/5517433905348608

[Darin Fisher]

Have you done any study of the reliability of this solution? What happens at browser shutdown time? What happens if a tab is being closed and its corresponding renderer process is being terminated?

-Darin

[Sigbjorn Finne]

Den 24.07.2014 19:03, skreiv Darin Fisher:
> Have you done any study of the reliability of this solution? What happens
> at browser shutdown time? What happens if a tab is being closed and its
> corresponding renderer process is being terminated?
>

The handling of ping requests has not been further studied or improved
upon on the embedder side to the best of my knowledge (but I've been
busy on other projects, so it could have escaped me.)

--sigbjorn

[Darin Fisher]

OK. Is there a plan to study it? I'm concerned that we might dangle a tasty carrot in front of developers only to disappoint them if this method is found to be too unreliable.

[Ilya Grigorik]

On Thu, Jul 24, 2014 at 11:00 AM, Darin Fisher <da...@chromium.org> wrote:

OK. Is there a plan to study it? I'm concerned that we might dangle a tasty carrot in front of developers only to disappoint them if this method is found to be too unreliable.

It would be great to gather some (UMA) stats on size of sent beacons, success rates, etc. I think that would help us determine what (and if) we need to do to improve reliability. At the moment, Beacon and <a ping> are no worse than what developers use today (XHRs, "image pings", and so on), and as such, I don't think we need to block shipping Beacon on this... but we can certainly improve its reliability down the road once we have some data on causes of failed deliveries, etc.

The spec is intentionally vague on this: "The User Agent SHOULD make a best effort attempt to eventually transmit the data."

AFAIK, FF is not doing anything special in this regard at the moment either.

ig

[Sigbjørn Finne]

On Thu, Jul 24, 2014 at 8:10 PM, Ilya Grigorik <igri...@google.com> wrote:

On Thu, Jul 24, 2014 at 11:00 AM, Darin Fisher <da...@chromium.org> wrote:

OK. Is there a plan to study it? I'm concerned that we might dangle a tasty carrot in front of developers only to disappoint them if this method is found to be too unreliable.

It would be great to gather some (UMA) stats on size of sent beacons, success rates, etc. I think that would help us determine what (and if) we need to do to improve reliability. At the moment, Beacon and <a ping> are no worse than what developers use today (XHRs, "image pings", and so on), and as such, I don't think we need to block shipping Beacon on this... but we can certainly improve its reliability down the road once we have some data on causes of failed deliveries, etc.

That clearly could be useful data; ​https://codereview.chromium.org/417943005/ counts sendBeacon() usage + the times the transmission limit is exceeded.

--sigbjorn

[Ilya Grigorik]

On Thu, Jul 24, 2014 at 2:16 PM, Sigbjørn Finne <s...@opera.com> wrote:

That clearly could be useful data; ​https://codereview.chromium.org/417943005/ counts sendBeacon() usage + the times the transmission limit is exceeded.

Nice! Is it possible for us to also track the status of the beacon request? E.g. 2xx/5xx, failed to connect, timeout, etc.

[Sigbjorn Finne]

Getting more data on there being bad servers and networks wouldn't add
much new information, IMHO. :)

If I understand correctly, what darin is interested in looking at more
closely is exceptional conditions like loss of power, browser
shutdown/crashes or network outage while a beacon/ping has been
transmitted. And if beacons are still transmitted across those.

Increasing reliability might be useful, but it also brings complexity
when having to retain beacon packets. Is there any indication that this
is a barrier to adoption?

--sigbjorn

[Chris Bentzel]

Reliability has been pretty important for large sites to adopt <a
ping> in the past, and this is probably going to be the case for
beacon. Fortunately you implemented both with the same underlying
mechanism, so improvements to one should help the other. This is part
of the reasoning behind keeping a limit on the beacon size - it would
allow us to persist in browser process memory to continue to send
across render process shutdown, or potentially even in permanent
storage to send across browser shutdown.

[Ilya Grigorik]

On Fri, Jul 25, 2014 at 12:33 AM, Sigbjorn Finne <s...@opera.com> wrote:

Getting more data on there being bad servers and networks wouldn't add much new information, IMHO. :)

If I understand correctly, what darin is interested in looking at more closely is exceptional conditions like loss of power, browser shutdown/crashes or network outage while a beacon/ping has been transmitted. And if beacons are still transmitted across those.

Well, at one point there was discussion about retry strategies, and having some aggregate data about reasons why the delivery fails (connection errors vs. server errors vs. process errors) might help inform how (and if) we implement that.

[Sigbjorn Finne]

Den 24.07.2014 20:00, Darin Fisher skreiv:
> OK. Is there a plan to study it? I'm concerned that we might dangle a tasty
> carrot in front of developers only to disappoint them if this method is
> found to be too unreliable.

The behavior and reliability of Beacon has been tested some internally
at Google in the past couple of weeks, http://crbug.com/402991/ has a
short summary of the outcome -- the ping/beacon based implementation is
a reliable alternative.

Additionally, the recent Beacon-Age: header spec addition has been
clarified and resolved (http://crbug.com/398167) and the overlap of CSP
and sendBeacon() has been clarified slightly in the CSP level2 spec
(https://w3c.github.io/webappsec/specs/content-security-policy/#directive-connect-src)
. The Beacon implementation will not handle redirects per CSP
(http://crbug.com/372197) until CSP checking has been moved out of the
renderer process (as part of the PlzNavigate effort, I believe.)

Besides tweaking the default setting for the Beacon quota some
(http://crrev.com/503843002/), I think the feature is now ready to move
to stable and ship. i.e., I'd like to re-table this intent-to-ship for
platform owners to consider.

--sigbjorn

[Ilya Grigorik]

Thanks for the update Sigbjorn!

+1 for shipping this in stable. I think all of the previous questions have been addressed. Also, as a bonus, note that GA has now enabled Beacon support: https://developers.google.com/analytics/devguides/collection/analyticsjs/field-reference#useBeacon ... \o/

ig

[Darin Fisher]

LGTM

Thanks for all the due diligence.

-Darin

[Sigbjorn Finne]

Thanks Darin,

and to GA folks for adding Beacon support; that's terrific.

If other platform owners have questions or concerns, please let me know.

--sigbjorn

[TAMURA, Kent]

LGTM2.

--
TAMURA Kent
Software Engineer, Google

[Jochen Eisinger]

lgtm3