The exit ping that never left: fetch in beforeunload loses to the browser's unload policy

The failure hides for a mechanical reason: the conditions that break it are the conditions you do not have locally. According to the dev.to write-up, a request fired during unload is sometimes completed if the connection is already established, and sometimes cancelled outright, and you cannot rely on either behaviour ^[6]. On a laptop hitting a local endpoint the socket is warm and the round trip is nothing, so the request lands before teardown. In production the same code meets a cold connection and a browser that has already decided the document is finished ^[1].

The distinction that actually matters is ownership of the request. `beforeunload` runs synchronously as the page is about to be discarded, and anything asynchronous started inside it inherits no delivery guarantee ^[5]. `sendBeacon` hands the request to the browser, which queues it and delivers it after the page is gone ^[2]. The bill for that transfer is narrow ergonomics: POST only, minimal headers, no custom headers, no response body, and a single boolean telling you whether the browser accepted the payload for queueing ^[3][4]. Any telemetry scheme that authenticates or routes on a custom header does not survive the move as written.

`fetch` with `keepalive: true` is the near miss. It does tell the browser to outlive the page context, but the source puts the ceiling at 64 KB shared across all active keepalive requests, and notes reliability problems in older Safari ^[7]. A shared budget is not a per-request limit, so measuring one flush in isolation tells you nothing about whether it will fit when something else is holding the allowance. That is why the fallback branch in a feature-detection snippet is the weaker path, not merely the older one.

The delivery race is also the smaller of the two bugs. On mobile, and iOS Safari in particular, `beforeunload` does not fire reliably when the user switches apps, locks the phone, or gets backgrounded by the OS, so events gathered in that session vanish with no record ^[10]. `visibilitychange` to `hidden` fires on all of those, plus navigation away and loss of focus ^[11]. Hidden is not dead, though: the user can come back, so the queue-and-clear pattern is what keeps the next batch honest ^[13]. Batching also keeps you under the payload limit and costs fewer requests than one call per event ^[12].

Two details are easy to skip. `sendBeacon` takes the same `BodyInit` types `fetch` accepts for a body ^[8], and a bare JSON string goes out as `text/plain` unless you wrap it in a `Blob` with an explicit type, which strict backends will notice ^[9]. And availability is not the obstacle anyone still pretends it is: Chrome 39 and Firefox 31 shipped it in 2014, Safari 11.1 in 2018, and it carries a Baseline 2022 label ^[14], meaning all three engines had it four years before the designation ^[1]. In any currently supported browser the `else` branch of the detection check never executes ^[15]. The open question in most codebases is not whether the API exists, but whether the exit path was ever wired to an event that fires.