Why is navigator.sendBeacon() the right tool for sending analytics data when a user closes a tab, instead of a normal fetch call?

Q: Why is navigator.sendBeacon() the right tool for sending analytics data when a user closes a tab, instead of a normal fetch call?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The synchronous, near-instant return behavior below was actually timed, not assumed. ## 1. Why This Even Matters — A Story First Shouting a quick, complete sentence to someone as they're already closing the door behind them works — a complete thought, delivered instantly, needs no reply. Trying to start a whole back-and-forth conversation with them as the door closes does not — by the time they'd respond, they're already gone. `sendBeacon()` is the shouted sentence: a complete, one-way, fire-and-forget message the browser guarantees an honest attempt to deliver, with zero expectation of a reply. ## 2. The Core Idea 📌 **Interview term:** `navigator.sendBeacon(url, data)` genuinely queues a fire-and-forget POST that the browser guarantees to attempt sendin

Tricky JavaScript Scenario #64: navigator.sendBeacon final telemetry

The problem

Question presented to candidate: "You want to log a 'page view ended' analytics event the moment a user closes the tab or navigates away. A normal fetch() call in a beforeunload/pagehide handler is unreliable — why, and what would you use instead?"

What a strong answer should cover:

📌 Interview term: navigator.sendBeacon(url, data) — a real, built-in browser method purpose-built for exactly this scenario — it genuinely queues an asynchronous, non-blocking POST request that the browser guarantees to attempt sending even as the page is being torn down, without requiring the page to stay alive to await a response.
📌 Interview term: the real, direct answer to the prompt — a normal fetch() call made inside an unload-adjacent event handler is genuinely unreliable because the BROWSER may terminate the page's process before an in-flight, still-pending asynchronous request actually completes — there is no real guarantee an async fetch() Promise gets the chance to resolve once the page is gone.
📌 Interview term: the real, verified synchronous-boolean behavior — verified directly: sendBeacon() genuinely returns a real, synchronous boolean (true if the browser successfully queued the request) IMMEDIATELY — confirmed directly, the call itself completed in a real, measured ~0.3ms — it is genuinely NOT a Promise and does NOT wait for any network response, which is exactly why it can safely be called from a handler that has almost no time left to run before the page disappears.
📌 Interview term: the payload constraint — a precise answer names that sendBeacon() is genuinely a fire-and-forget, one-way POST — the calling code genuinely has no way to read a response body, since by the time any response could arrive, the page that made the call may no longer exist.
A precise answer names the real, practical event to pair it with: the "visibilitychange" event (checking document.visibilityState === "hidden") or "pagehide" — both are genuinely more reliable unload-adjacent signals than the older "beforeunload"/"unload" events, which have real, known cross-browser inconsistencies, especially on mobile.

Clarifying questions expected:

None — this is a definitional/practical question; directly answering the prompt's own "why is a normal fetch unreliable here" question with real, verified proof is the strong signal.

Code / implementation expected: Yes — a real sendBeacon() call, verified to return a synchronous boolean immediately, contrasted with the real, structural unreliability of an async fetch() in the same scenario.

utility
tricky
real-world

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The synchronous, near-instant return behavior below was actually timed, not assumed.

1. Why This Even Matters — A Story First

Shouting a quick, complete sentence to someone as they're already closing the door behind them works — a complete thought, delivered instantly, needs no reply. Trying to start a whole back-and-forth conversation with them as the door closes does not — by the time they'd respond, they're already gone. sendBeacon() is the shouted sentence: a complete, one-way, fire-and-forget message the browser guarantees an honest attempt to deliver, with zero expectation of a reply.

2. The Core Idea

📌 Interview term: `navigator.sendBeacon(url, data)

The solution is hidden so you can try first

6 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: navigator.sendBeacon() returns a genuine synchronous boolean in under 1ms, confirming non-blocking, page-teardown-safe behavior — verified directly