Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A normal asynchronous fetch() started in beforeunload may not finish before the browser discards the page. For small, fire-and-forget telemetry, send it when the page becomes hidden with navigator.sendBeacon(). This queues a POST without holding up navigation—but it is not a delivery receipt, and no page-lifecycle event can guarantee that code will run before a browser or mobile operating system terminates the page.
Why an ordinary fetch can be lost during navigation
When a document is being unloaded, the browser may not wait for an ordinary asynchronous request to complete. A request started in beforeunload can therefore be abandoned as the page goes away; it is not safe to treat that event as a final opportunity to finish network work. The Beacon API is designed for small requests that should be queued while a document is being discarded, without delaying the next navigation. MDN’s Beacon API overview describes that use, while the W3C Beacon specification sets out the API’s behavior.
Send telemetry when the page becomes hidden
For end-of-session analytics or diagnostic data, MDN recommends listening for visibilitychange and sending when document.visibilityState becomes hidden. That state change is a better lifecycle signal than waiting for the page to unload.
document.addEventListener("visibilitychange", () => {
if (document.visibilityState === "hidden") {
const queued = navigator.sendBeacon("/log", analyticsData);
if (!queued) {
// The browser did not accept this data for queuing.
}
}
});Replace analyticsData with the payload your application has prepared and /log with your endpoint. The body can be a string, Blob, FormData, URLSearchParams, or a supported buffer or view type. Keep it small: MDN documents a 64 KiB (65,536-byte) limit on queued data. If sendBeacon() returns false, the user agent did not queue the data. A true result means only that it accepted the data for queuing; the API does not provide a response or confirm that your server processed it. See MDN’s Navigator.sendBeacon() reference.
#1 Best Overall
Choose between sendBeacon, keepalive fetch, and unload handlers
| Approach | Best fit | Method and request control | Can read a response? | Main limitation |
|---|---|---|---|---|
sendBeacon() on visibilitychange |
Small, fire-and-forget end-of-session data | POST; the API does not offer the same request configuration as fetch() |
No | Queued-data limit is 64 KiB (65,536 bytes); queue acceptance is not proof of server processing. MDN |
fetch() with keepalive: true |
Requests needing a method or request properties beyond Beacon’s POST-only interface | Supports more request control; for example, a PUT request | Yes, through the fetch response when available | Keepalive helps with requests that outlive a page, but cannot make a lifecycle callback run or ensure delivery if the page process is terminated. MDN; MDN’s deferred fetch guidance |
fetch() in beforeunload or unload |
Not a dependable end-of-session delivery strategy | Fetch supports request configuration, but the page may disappear before the request completes | Not reliably before the page is discarded | The request can be abandoned, and the event itself may not fire. MDN; MDN Beacon API overview |
Use keepalive fetch when Beacon’s limits do not fit
If the endpoint requires a method other than POST, custom request properties, or response access, use fetch() with keepalive: true rather than sendBeacon(). For example:
fetch("/log", {
method: "PUT",
body: analyticsData,
keepalive: true
});This gives the request more control, but it does not solve every lifecycle problem: the callback that starts the request may never run, and a terminated page process cannot be relied on to complete application work. MDN discusses this tradeoff in its deferred fetch guidance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why beforeunload and pagehide are not guarantees
The weak link may be the event handler, not just the request. MDN cautions that beforeunload, unload, and even pagehide may not fire in many situations, especially on mobile, where a browser or operating system can suspend or terminate a page. pagehide can serve as a fallback in browsers without visibilitychange, and it is compatible with the back/forward cache, but it is still not a reliable mobile delivery guarantee. Do not use synchronous XHR, busy loops, or other navigation-blocking workarounds: they hold up navigation and harm responsiveness. MDN’s lifecycle guidance explains these limitations.
Quick Recap
Best Value
- HTML CSS Design and Build Web Sites
- Comes with secure packaging
- It can be a gift option
Rank #4
- Applying all key ASP.NET Core components, including MVC for HTML generation, .NET Core, EF Core, ASP.NET Identity, dependency injection, and more
- Integrating ASP.NET Core with leading client-side frameworks, including Bootstrap
- ASP.NET Core code for implementing business logic and data transformations
- Handling configuration, routing, controllers, views, and common tasks (including posting forms and presenting data)
- Performing complementary tasks: error handling, logging, application design, authentication, localization, and more
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
