The beacon API has exactly one use - reliable analytics. Sending a ping on leaving the page is a pretty contrived example - the beacon API is useful at any time.

I use the beacon API in my homebuilt hit-counter. It means that even if the user navigates away before the hit is registered, the request will still have a fair chance of being received by my server.

Of course there are other ways of doing this, but who wants to muck around with service workers or websockets when there is a simple, well-supported API that does exactly what you want?

▲

Thorrez 5 days ago | parent | next [-]

Could you count hits on the server when serving the page?

I guess caching might break that depending on cache settings. And for SPAs, it might not work as desired.

▲

dspillett 5 days ago | parent | next [-]

Calling out as the page closes, assuming you called out at out listed too, tells you how long the user was there. Not entirely reliable of course as they could have opened it in the background so had it open a while before dismissing it without looking at it at all.

	▲	Thorrez 4 days ago \| parent [-]
		I should have been clearer. I was replying to the "I use the beacon API in my homebuilt hit-counter." part.

▲

AndrewStephens 5 days ago | parent | prev [-]

There are several reasons that you cannot just count the number of times your server has served the page.

The biggest is bots - on my site (and I assume most others), legitimate requests are far, far outweighed by bots. Sometimes you can tell that they are bots but it is very common for bots to pretend to be real users. Oftentimes you can't tell from a single request but only but looking at the pattern of requests.

Some bots do take the trouble of running scripts on the page but thankfully they are in the minority so far.

Caching would certainly break the system as well, in the other direction.

▲

immibis 5 days ago | parent [-]

Why do we automatically suppose that bot requests are "not legitimate" btw?

▲

wredcoll 5 days ago | parent [-]

For the same reason we assume a random tiger wants to eat us.

	▲	meindnoch 4 days ago \| parent [-]
		That's tigrophobic.

▲

LunaSea 5 days ago | parent | prev | next [-]

Is the Beacon API functional nowadays? I remember that a two or three years ago benchmarks showed that the original window.onunload (I believe) was able to log more event than the new Beacon API.

▲

baxuz 5 days ago | parent | prev | next [-]

One downside is that it's not available in web workers.

▲

jauntywundrkind 5 days ago | parent | prev | next [-]

One concern I have is that interactions on sites like HN might not have gotten to the server. Wouldn't this be useful to make sure something like an upvote gets through, even if I navigate away quickly?

▲

stevage 5 days ago | parent | prev [-]

>Sending a ping on leaving the page is a pretty contrived example

I don't think it's a contrived example. It seems to be one of the main use cases. From the spec:

> The main use case for the Beacon API is to send analytics such as client-side events or session data to the server. Historically, websites have used XMLHttpRequest for this, but browsers do not guarantee to send these asynchronous requests in some circumstances (for example, if the page is about to be unloaded). To combat this, websites have resorted to various techniques, such as making the request synchronous, that have a bad effect on responsiveness. Because beacon requests are both asynchronous and guaranteed to be sent, they combine good performance characteristics and reliability.