Read on Twitter
Very interesting thread on navigator.sendBeacon – looks like the best way to utilize it ISN’T at unload (as many believe) but rather upon tab/page backgrounding (so visibilitychange).
Apparently unload can be super unreliable, especially on mobile. https://github.com/mdn/sprints/issues/3722
Apparently unload can be super unreliable, especially on mobile. https://github.com/mdn/sprints/issues/3722
This kinda goes against the grain of how navigator.sendBeacon is used in analytics tools such as Google Analytics 4. The expected design is that it protects hits that are sent on the fringe of the page lifecycle, so that they are not aborted by the unloading of the page.
However, there are many scenarios where “unload” isn’t dispatched (esp. on mobile and with back-forward caches), meaning navigator.sendBeacon() isn’t called either.
The takeaway is that…
There still does not exist a technique that would allow data collection reliably and non-intrusively when the page is about to be unloaded, whether due to navigation, bf-cache, tab/browser process being killed, or something else.
There still does not exist a technique that would allow data collection reliably and non-intrusively when the page is about to be unloaded, whether due to navigation, bf-cache, tab/browser process being killed, or something else.
Thus it’s a bit risky to build a batch system that accumulates requests to be sent upon unload, when that very mechanism just isn’t reliable.
Solution? Per the thread. Clear the batch queue when visibility change happens. It includes a lot more than just unload, but it works.
Solution? Per the thread. Clear the batch queue when visibility change happens. It includes a lot more than just unload, but it works.
Oh, also, “very interesting thread” is about the discussion behind the link in the first Tweet, not this little Twitter thread. I’m not that conceited.
