Background Work API

[g-aattar]

Introduction

Browsers intervene aggressively on hidden pages to save battery, CPU, and memory: main-thread timers are throttled, JavaScript execution can be paused by Page Lifecycle freezing, and background tabs are discarded under memory pressure. While these defaults protect system resources, they silently break legitimate user-initiated tasks—such as large media uploads, long-lived line-of-business apps (e.g., call-center softphones), and offline state synchronization.

To survive these interventions, sites currently resort to opaque workarounds like looping silent audio or maintaining dummy WebRTC connections. The Background Work API proposes an explicit, user-granted permission ("background-work") that allows applications to execute logic reliably in dedicated or shared workers while hidden, providing an attributable signal to the browser and full control to the user.

Read the complete Explainer.

Feedback (Choose One)

Please provide all feedback below.

I welcome feedback in this thread, but encourage you to file bugs against the Explainer.

[aluhrs13]

Is a new incubation the solution here? It seems like there's enough overlap with the intent of periodic background sync and/or background sync that iterating on those incubations would likely lead to a MUCH clearer (and more interoperable since WebKit+Gecko both are negative on both of those right now) story for developers.

[g-aattar]

Thanks for the feedback @aluhrs13! That's a great question, as "doing work in the background" sounds similar on the surface, but the underlying use cases and execution models are fundamentally different. I believe Background Fetch/Sync are built for post-close or deferred network tasks, whereas Background Work API is built to protect user-initiated, in-flight work in an open tab from being silently killed by freezing.

[slightlyoff]

hey @g-aattar,

Not sure how much background you might have on some of the design choices we've made here over time. Back when we designed Push, Background Sync, and Periodic Background Sync (2013-2017) we discussed a more generic background work API and decided against it, preferring to tie specific tasks to APIs that are designed to satisfy them out of principle.

Those principles include:

• Specific value: obviously, these are Turing-complete environments, but the work should be tied to some specific pile of value that users can make affirmative decisions about, preferably tied to a capability that we can describe to them in permissions UX.
• Attribution: any work that is being done in the background on the user's behalf should be attributed to that permission and should be revokable. Developers should be guided to use APIs in ways that tie specific tasks to specific events that are spawned by the permission granted.
• Visibility: we should be able to provide iconography and usage indicators across the product that align with end-user-digestable concepts. This ties back to what we might offer as a choice in a UI.
• Control: users should make explicit grants and be able to revoke them at any time.

Periodic Background Sync is perhaps the one that strays furthest from these goals today, and as a result it has been kept on a (too) short leash in terms of execution frequency and other abilities. That doesn't justify, however, introducing a generic concept that throws out the principles in general.

So with my API OWNERS hat on, the questions I'd like to see answered for any Intent in this space is "why isn't this a recipe for privacy disaster ala Android?" and "why isn't this a change of options/behaviour for PBS?"

The last one is perhaps the most load-bearing; if you can't show that an important problem can't be solved with revisions to PBS, expect friction. This should occupy a large fraction of your Explainer's "Considered Alternatives" section, and probably the bulk of the Explainer overall.

Best,

Alex

[tomayac]

The explainer links to Screen Wake Lock as a considered (wasteful) alternative. In the context of the Wake Lock discussions, the topic of a System Wake Lock repeatedly came up.