Test your knowledge: Decision Tree & Hybrid Transport

Question 1 of 6

The decision tree's first branch point is…

The APIs differ by what they guarantee at teardown time.

Answer options A payload size: under or over 64 KiB B context: is the send happening during page-death (the hidden transition) or during normal life? C origin: same-origin or cross-origin collector? D browser: Chromium or Gecko?

On the dying path you need the MUST-flush guarantee → sendBeacon. During normal page life you can afford fetch(keepalive)'s richer contract — headers, methods, response. Payload size, origin, and feature support refine the branches below.

Review this lesson

Question 2 of 6

sendBeacon is the right choice when you need…

It is exactly the shape of an analytics pageview ping.

Answer options A the response body of the telemetry request B a POST of safelisted-type data, sent at page death, with cookies, no custom headers C cross-origin sends without any server CORS work D payloads larger than 64 KiB

sendBeacon's contract: POST-only, safelisted Content-Types, credentials included, no headers, MUST-flush at hidden. That is the analytics pageview / error ping shape — its natural habitat.

Review this lesson

Question 3 of 6

fetch(keepalive) wins over sendBeacon when…

Everything sendBeacon forbids, fetch allows — at the cost of the flush guarantee.

Answer options A you must send during the hidden transition with maximum reliability B you need custom headers (auth, tracing) or non-POST methods with keepalive semantics C the browser lacks fetch entirely D you want to avoid the 64 KiB pool

Authorization headers, traceparent propagation, PUT/PATCH telemetry endpoints, response status checking — all impossible through sendBeacon's three-argument surface, all native to fetch(keepalive).

Review this lesson

Question 4 of 6

The hybrid transport pattern means…

Not redundancy — selection. One sender, two transports, chosen per send.

Answer options A sending every beacon twice through both APIs for redundancy B routing each send through the API the decision tree picks — beacon at page death, keepalive fetch in life C load-balancing between two collector origins D compressing payloads to fit the smaller of the two quotas

The hybrid sender probes capabilities once, then dispatches by context: lifecycle-driven sends go through sendBeacon (MUST-flush), interactive sends go through fetch(keepalive) (rich contract). Same queue, same retry policy, right transport per moment.

Review this lesson

Question 5 of 6

The 'webdev pattern' shared-quota trap bites when…

The common web.dev recipe pairs the two APIs without mentioning they draw from one account.

Answer options A a page uses sendBeacon for analytics AND fetch(keepalive) for error reporting — both charge the same pool B two tabs of the same site share one collector C the SW intercepts and re-issues the beacon, doubling the charge D HTTP/2 multiplexing splits one beacon into many frames

Analytics beacons and error-reporting keepalive fetches all draw on the single 64 KiB per-fetch-group pool. Under load the two producers starve each other; the hybrid transport must budget them together, not independently.

Review this lesson

Question 6 of 6

`hybrid-transport.js` composes the earlier recipes into…

It is the hybrid transport layer: the decision function as running code.

Answer options A a Service Worker that mirrors beacons to a mirror origin B one sender with capability detection, quota-aware queueing, and per-send transport choice C a bundler plugin that tree-shakes unused transports D a server-side aggregator for dual-transport payloads

The recipe combines detect.js capabilities, the quota queue's in-flight accounting, and the boolean/promise contracts of both transports into a single sender whose per-send routing implements the decision tree.

Review this lesson

Test your knowledge: Decision Tree & Hybrid Transport