Technical
Beacon
Also called page beacon.
Beacon is a small fire-and-forget request a page sends to report something, usually while it is closing or running in the background. The browser delivers it even if the visitor has already left.
How it is measured
In the network panel a beacon shows up as a short POST of type `ping` or `beacon` that the page never waits on. The server sees one HTTP request with a body and answers 204 or 200.
Count them on the receiving endpoint by status code and body size. A healthy collector returns mostly 2xx. A rising share of 4xx usually means a size limit or a CORS preflight rejecting the request.
Worked example
A docs site on Astro sends one beacon at `pagehide` carrying scroll depth, an 18-byte JSON body. In Safari it arrives on 91 of 100 test navigations. In Firefox with strict tracking protection it arrives on none, because the collector domain is on a block list.
Moving the endpoint to a path on the site's own domain lifts Firefox to 88 of 100. The remaining misses are tabs killed by the OS before the browser could flush the queue.
How it differs
A beacon is the request itself. sendBeacon is one browser API for making it; an image request or `fetch` with `keepalive` does the same job. A beacon carries no promise of delivery and no reply the page can read.
Common errors
Expecting a response body. Sending a large JSON blob that hits the 64 KB queue limit. Using synchronous XHR in an unload handler and stalling navigation. Adding a Content-Type that triggers a CORS preflight. Treating every beacon as a new visit.
In practice
Send one on `pagehide` or `visibilitychange`, keep the body to a few KB, and test it on a real phone by switching apps. Log rejected beacons by status code so loss is visible instead of silent.