Intent to Ship: Extended lifetime shared workers

[Chromestatus]

Contact emails

dom...@chromium.org, yyana...@chromium.org

Explainer

https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b#file-1-explainer-md

Specification

https://github.com/whatwg/html/commit/9c009049e4fa9dba638ef68ca502b781082bbb68

Summary

This update adds a new option, `extendedLifetime: true`, to the `SharedWorker` constructor. This requests that the shared worker be kept alive even after all current clients have unloaded. The primary use case is to allow pages to perform asynchronous work that requires JavaScript after a page unloads, without needing to rely on a service worker.

Blink component

Blink>Workers

Web Feature ID

shared-workers

Motivation

Many sites want to perform some work during document unloading. This usually includes writing to storage, or sending information to severs. Currently, if this work is done asynchronously (e.g., writing to IndexedDB instead of localStorage, or using CompressionStream to compress the body before sending a fetch()) the only way to do this is to use a service worker. However, requiring a service worker for this simple case of work-after-unload is heavyweight: the disk space, memory consumption, and developer experience of managing the service worker registration and lifecycle makes this hard to deploy. By using shared workers, all of these downsides are avoided.

Initial public proposal

https://github.com/whatwg/html/issues/10997

TAG review

https://github.com/w3ctag/design-reviews/issues/1089

TAG review status

Pending

Origin Trial Name

Extended lifetime shared workers

Goals for experimentation

None

Chromium Trial Name

SharedWorkerExtendedLifetime

Origin Trial documentation link

https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b#file-1-explainer-md

WebFeature UseCounter name

kSharedWorkerExtendedLifetimeFeatureEnabled

Risks

Interoperability and Compatibility

We intend to specify that the lifetime timeout for these shared workers be extended in the same way as service workers. Because the exact timeout of service workers is left implementation-defined, it's possible that code using this new feature could be non-interoperable. However, this has so far not proved to be a major problem in practice for service workers.

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1227) Some unofficial tentative positive signals and engagement in the proposal issue.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/492) Some unofficial tentative negative signals in the proposal issue.

Web developers: Positive The problem of wanting to perform asynchronous work during unload is well-known, with the service worker workaround currently deployed, including by Google properties.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

The chrome://inspect/#workers page indicates when a SharedWorker is using the extendedLifetime option.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
Shared workers are not yet supported on Android and Android WebView. However, we are concurrently working on enabling them there, and when we do, this feature will also be supported.

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/workers/tentative/SharedWorker-extendedLifetime.html

Flag name on about://flags

No information provided

Finch feature name

SharedWorkerExtendedLifetime

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/400473072

Estimated milestones

Shipping on desktop	148
Origin trial desktop first	139
Origin trial desktop last	142
Origin trial extension 1 end milestone	145
Origin trial extension 2 end milestone	148
Shipping on Android	148
Shipping on WebView	148

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

We are currently discussing some details in preparation for specification. The exact nature of how the lifetime extension works with regard to non-window clients, particularly, has only recently reached a tentative conclusion.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5138641357373440?gate=4686145547665408

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6862683f.170a0220.16d1bf.0122.GAE%40google.com
Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68de2b1f.050a0220.58465.05c2.GAE%40google.com
Intent to Extend Experiment 2: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69704662.2b0a0220.2c228a.0283.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

LGTM1

On Tue, Mar 31, 2026 at 8:09 AM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

dom...@chromium.org, yyana...@chromium.org

Explainer

https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b#file-1-explainer-md

Specification

https://github.com/whatwg/html/commit/9c009049e4fa9dba638ef68ca502b781082bbb68

https://github.com/whatwg/html/pull/11600 is a slightly more convenient link.

It'd be good to update that thread with OT results, as discussed.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69cb650f.050a0220.201b21.039e.GAE%40google.com.

[Yoshisato Yanagisawa]

Let me share the summary of origin trials as Yoav asked:

Currently, 35 sites, including large and medium-scale origins, participated in the origin trials. Usage metrics can be found at https://chromestatus.com/metrics/feature/timeline/popularity/5550.

Developers expressed strong interest in using this feature to maintain a SharedWorker's lifetime across same-origin navigations within a single tab. While there were requests for seamless migration from non-extended to extended lifetime workers, we identified a potential "footgun" regarding WebLocks where a long-lived worker could hold a lock indefinitely. To ensure safety, we decided to enforce strict separation between the two lifetime modes.

Feedback also showed that the feature effectively handles asynchronous tasks after a page unloads in most scenarios. However, some sites with strict Content Security Policies (CSP) encountered issues when using the feature with blob: URLs.

Notably, extended lifetime shared workers were successfully integrated into the HTML standard during the OT period, with positive signals from other browser vendors. Additionally, as we are working on enabling SharedWorker on Android (as discussed in a separate thread), this feature will also be available on Android following that rollout. To improve observability, chrome://inspect/#workers was updated to indicate whether a SharedWorker is running with the extendedLifetime flag.

Please let me know if you have any questions.

2026年3月31日(火) 18:22 Yoav Weiss (@Shopify) <yoav...@chromium.org>: