Summary

  • W3C's first public Beacon draft in October 2013 described the awkward last-minute analytics tricks that delayed navigation, including synchronous XMLHttpRequest, image loads and busy loops.
  • The August 2022 Candidate Recommendation Draft described navigator.sendBeacon() as a way to queue a small one-way report while the browser schedules transmission and the reader moves on.

Picture the page at closing time. You have your coat on, a hand on the door. A clerk from the analytics department appears with a form: “Before you go, could you wait while I send this to headquarters?” The form may be tiny. The insistence is the problem. The next page cannot start its day because the old page is still trying to finish its paperwork.

That scene was technical, not merely theatrical. W3C's first public Beacon Working Draft of 29 October 2013 described analytics and diagnostics code that wanted to transmit data as a document unloaded. If it sent an ordinary asynchronous request at the last moment, the browser might discard the request when the page disappeared. Developers sometimes used synchronous XMLHttpRequest to hold the exit, an image load, or even a loop that did nothing except burn time. The draft named the cost: navigation appeared slower to the person who had already decided to leave.

The proposed bargain was simple. Give the report to the user agent and let it handle transmission later, without forcing the page to stand in the doorway. The 2013 draft used an early method called beacon; its shape was different from the later navigator.sendBeacon(). The historical point is the transfer of responsibility, not the survival of every line of the first draft's example code.

Why did the page care about a final message? A session may end with a last event, a diagnostic detail or a small measurement that was unavailable earlier. Sending every observation immediately can waste network and battery resources; saving everything until departure risks losing the report. The old answer was sometimes to make the reader pay for that tension in waiting time. Beacon offered a smaller bill: the browser could accept data and choose a suitable time to transmit it.

The W3C Candidate Recommendation Draft of 3 August 2022 describes navigator.sendBeacon(url, data) as an asynchronous, non-blocking interface for small one-way requests. It gives the browser room to schedule, prioritize and sometimes coalesce transmissions around other work. An animation, a click, or the next page need not queue behind an analytics receipt. The browser becomes a courier who can carry an envelope after the customer has stepped out.

The 2022 example pays attention to a different moment than the 2013 unload handler. It listens for visibilitychange and sends a session report when the document becomes hidden. The draft notes that an unload event may never fire when a mobile page goes to the background and the operating system later ends the process. Waiting for a formal farewell is a poor plan if the room can be quietly closed. The hidden transition is a practical earlier cue for handing over the envelope.

The method's return value is an especially important piece of etiquette. sendBeacon() returns true when the user agent can queue the data. That is the courier saying, “I have the envelope.” It is not a signed receipt from the destination server, nor proof that anyone opened the report. The interface offers no response callback. A publisher that needs a server answer should choose another exchange, not invent one from a boolean.

The payload is deliberately small. The 2022 draft links sendBeacon() to fetch with keepalive and limits how much data can sit in such a queue. It does not give the page an unlimited background freight service. Requests needing a custom method, headers or response handling belong with the appropriate fetch facilities. The small envelope metaphor is useful precisely because the envelope cannot secretly become a moving truck.

The W3C publication history places the first public draft in October 2013, a Candidate Recommendation Snapshot in April 2017 and the later Candidate Recommendation Draft in August 2022. Those dates trace the documents. The later API and scheduling rules are visible in the later text; the 2013 draft is evidence of the original problem and early proposal.

For the reader, the change is felt as an absence. The door opens without a pause engineered for the old page's statistics. For the site, the gain is a clean handoff: it can prepare a modest report, offer it to the browser, and avoid building a tiny traffic jam at every exit. The browser may still have work to do after the page is gone. The person who left does not need to supervise the courier's shift.

A final message is perfectly reasonable. Keeping someone at the door until the office confirms the filing is the rude part. Beacon made the distinction operational.