Test your knowledge: fetch(keepalive)

Question 1 of 6

Which statement about `fetch(keepalive: true)` browser support is TRUE?

The six-year gap is why hybrid senders probe before choosing the superset.

Answer options A Universal since 2017, like sendBeacon B Firefox shipped it only in v133 (Nov 2024) — the last browser to do so C Safari has never shipped it D It requires a secure context flag

Chrome 66 (2018) and Safari 11.1 shipped fetch(keepalive); Firefox landed it in v133, November 2024 — six years after Chrome. Feature detection remains mandatory in 2026.

Review this lesson

Question 2 of 6

What does `fetch(keepalive)` offer that `sendBeacon` does not?

It is a full fetch: the headers parameter, the method parameter, the promise — all present.

Answer options A Custom headers, any HTTP method, response access, and credentials control B A larger dedicated quota C A MUST-flush-on-hidden guarantee D Worker-origin exemption from CORS

keepalive fetches set custom headers (Authorization, traceparent), use PUT/PATCH/DELETE, expose the response through the promise, and let you choose credentials mode. The boolean API trades all of that for one guarantee fetch cannot give — see the next question.

Review this lesson

Question 3 of 6

What does `sendBeacon` guarantee that `fetch(keepalive)` does NOT?

One API is specced for page death; the other merely survives it.

Answer options A Delivery on networks slower than 100 ms RTT B The spec's MUST-flush on the visibilityState → hidden transition C Exemption from the 64 KiB quota D Compression of the request body

The Beacon spec's normative MUST schedules immediate transmission when visibilityState transitions to hidden. fetch(keepalive) requests MAY outlive the page but nothing obligates the browser to flush them at the hidden transition — an in-flight keepalive fetch can still be dropped at teardown.

Review this lesson

Question 4 of 6

A page sends a 60 KiB `sendBeacon`, then a 20 KiB `fetch(keepalive)` in the same tick. What happens?

Beacons ARE keepalive fetches — of course they share the accounting.

Answer options A Both send — the two APIs have separate pools B The fetch rejects/beacon returns false — they share ONE 64 KiB in-flight pool C The fetch is queued behind the beacon D The beacon is silently upgraded to the fetch group

Both APIs charge the same per-fetch-group 64 KiB keepalive pool. 60 + 20 exceeds 64 KiB, so the pool refuses the second request. This is the trap behind 'sendBeacon returned false but fetch also failed' — the fallback ladder shares the pool it fell back from.

Review this lesson

Question 5 of 6

Why did the spec keep sendBeacon's synchronous boolean instead of returning a promise?

Think about what await means when the execution context is about to be destroyed.

Answer options A Backward compatibility with Chrome 39's original API B The call must not be await-able during the hidden transition — a pending promise would die with the page C Promises cannot cross the fetch group boundary D The boolean is cheaper for the garbage collector

During visibilitychange → hidden the page is moments from death; a synchronous queueing answer is the only answer that can arrive in time. fetch(keepalive) gives you the richer promise API — usable when your code is not on the dying path.

Review this lesson

Question 6 of 6

The `keepalive-sender.js` recipe wraps fetch(keepalive) to…

It is the superset with the ergonomics of the simpler API.

Answer options A mirror sendBeacon's boolean contract while adding headers and methods B defeat the 64 KiB quota by chunking C disable CORS preflights for credentialed sends D polyfill fetchLater onto older browsers

The sender exposes a sendBeacon-style boolean API (queueing success), built on fetch with keepalive: true — so callers get headers, methods, and credentials control without giving up the familiar contract.

Review this lesson

Test your knowledge: fetch(keepalive)