Test your knowledge: Page Lifecycle & Delivery

Question 1 of 6

The Beacon spec's normative MUST flushes beacons on what trigger?

The event is just how JavaScript observes it; the MUST is on the browser-internal change.

Answer options A The visibilitychange event B The pagehide event C The visibilityState transition to hidden — the state change, not any event name D The beforeunload event

The spec says the user agent MUST schedule immediate transmission when the document visibilityState transitions to hidden. The visibilitychange event is merely the JS-visible signal of that transition — the flush happens even with no listener registered.

Review this lesson

Question 2 of 6

During a normal navigation away from a page, what is the event order?

The beacon window is the FIRST of these signals.

Answer options A unload → pagehide → visibilitychange B pagehide → visibilitychange (hidden) → unload — only if the page is not bfcache-eligible C visibilitychange → beforeunload → pagehide D All three fire simultaneously

The reliable end-of-session sequence is pagehide → visibilitychange(hidden) → unload. unload is the least reliable of the three — deprecated in Chrome and skipped for bfcache. Send the beacon on the first signal you see.

Review this lesson

Question 3 of 6

With `unload` fully deprecated, what replaces it for cleanup work (closing sockets, releasing locks)?

bfcache-aware cleanup needs an event that fires on BOTH navigation-away and bfcache-entry.

Answer options A beforeunload — it still fires everywhere B pagehide — it fires even when the page enters bfcache C visibilitychange → visible D Nothing — cleanup must move to the server

pagehide fires for normal navigation AND bfcache entry, and its event.persisted flag tells you which. unload fires for neither reliably anymore. Analytics goes on visibilitychange → hidden; cleanup goes on pagehide.

Review this lesson

Question 4 of 6

A page is restored from bfcache. What should analytics code do?

The user's session continued — a restore is a new impression of the same document.

Answer options A Nothing — the original pageview still counts B Send a fresh pageview with a navigation type marker on pageshow / visibilitychange → visible C Clear all beacons queued before the cache entry D Reload the page to reset analytics state

On restore, pageshow fires with persisted: true and visibilitychange fires → visible. The lesson's flusher debounces the double signal and ships a fresh pageview tagged as a bfcache restore, so restored sessions are not invisible to analytics.

Review this lesson

Question 5 of 6

On mobile, why is `visibilitychange` → hidden the last reliable signal?

The Beacon spec itself warns about process termination in the background state.

Answer options A Mobile browsers never fire pagehide B The mobile OS can kill the process while the page is backgrounded — no later event is guaranteed C Mobile networks drop beacons sent after pagehide D Mobile Safari throttles beacons to one per session

When a mobile OS reclaims memory, the page's process dies while hidden — no unload, no pagehide afterwards. The hidden transition is the last moment your code is running; the spec mandates the flush exactly there.

Review this lesson

Question 6 of 6

What does the `lifecycle-flusher.js` recipe guard against?

hidden can arrive via several signals in quick succession — and twice for bfcache restores.

Answer options A Duplicate beacons from the overlapping lifecycle signals B Beacons exceeding the 64 KiB quota C Service workers intercepting the flush D Chrome's Blob Content-Type throw

visibilitychange, pagehide, and pageshow can overlap and repeat. The flusher debounces them into one flush per state change and re-arms on restore — exactly one beacon per user-visible transition.

Review this lesson

Test your knowledge: Page Lifecycle & Delivery