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>:

[Mike Taylor]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6U57Q-itgKk9fO5EuS4G2tiWCuYSE6nN%2B0Buyrq8R0B_w%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

Thanks for the update, and apologies for not being clearer. I meant that it'd be good to update the WebKit position thread, as WebKit folks ended it with "An A/B experiment could be interesting for sure as well as more information as to which websites would want to adopt this (but would not want to work offline)."

If we can provide them with data that can help sway them, we should :) 

[Rick Byers]

Looks reasonable to me, just wondering why the test is reporting timeout in Chrome? I'm happy to approve once the test is passing. 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKjZaONFeBapbNDuE6qnsRDjLGQQPf2OfEmGkOLSkMnmw%40mail.gmail.com.

[Yoshisato Yanagisawa]

Hi Yoav and Rick,

Thanks for the feedback. Here is an update on the two points:

WebKit Standards Position
I’ve updated the WebKit standards-position thread with the Origin Trial results and our design refinements (including the strict separation logic for Web Locks safety) as Yoav suggested.
Link: https://github.com/WebKit/standards-positions/issues/492#issuecomment-4175651351

WPT Timeout Investigation
I’ve identified and am now fixing (crrev.com/c/7725421) the timeout issue in SharedWorker-extendedLifetime.html. I suspect the timeout was caused by an unnecessary await window.pageShowPromise; in the test script.  This variable is not defined in the standard RemoteContext executor, leading to hangs in environments like wpt.live. I’ve removed this line from all related tests.

Please let me know if there is anything else needed for the I2S.

2026年4月2日(木) 0:15 Rick Byers <rby...@chromium.org>:

[Rick Byers]

Thank you for fixing the test. It doesn't seem reflected on wpt.fyi yet for some reason (even though the latest run should have it), but I'm confused by the history view saying it's passing. Anyway I'm happy to leave it to you to follow up and get wpt.fyi green. LGTM3

[Yoshisato Yanagisawa]

Sure.  I will keep following up the WPTs.

2026年4月7日(火) 5:31 Rick Byers <rby...@chromium.org>:

[Yoshisato Yanagisawa]

FYI, with the several fixes, the WPT started to succeed in:

https://wpt.fyi/results/workers/SharedWorker-extendedLifetime.html?label=master&label=experimental&aligned

2026年4月7日(火) 16:17 Yoshisato Yanagisawa <yyana...@chromium.org>:

[Jake Archibald]

On Tuesday, 31 March 2026 at 11:47:41 UTC+1 yyana...@chromium.org wrote:

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.

Does this mean Chrome has no intention of implementing the spec'd behaviour here? Both Firefox and Safari maintain a single shared worker across navigations. It would be nice to have some interop here.

Demo: https://random-stuff.jakearchibald.com/shared-worker-navigation/ (the number is the same every navigation in Firefox and Safari, but not in Chrome, since the worker is re-created each time).

Jake.

[Barry Pollard]

This looks like a regression introduced in Chrome 146 due to some unrelated work on bfcache. I've raised https://issues.chromium.org/issues/507358432 for this.

On the plus side the new `extendedLifetime: true` option does reintroduce this functionality for sites happy to use this :-)

But we should fix that regression so it also works for same-origin navigations for workers without that option. And ideally introduce a WPT to catch this next time (I couldn't see an exiting one that is broken in stable and working in experimental) to ensure continued interop as you say.

[Jake Archibald]

Ohh interesting! But now I'm confused about the email I was replying to, which seemed to suggest that the lack of continuity was intentional, due to a "footgun"?

[Barry Pollard]

I think this is basically if you have one constructor with `extendedLifetime: true` and another constructor for the same worker without that option, then ideally the browser could share those workers and upgrade to an extended lifetime one if the non-extended happened first. Especially during the changeover when introducing extendedLifetime for the first time.

However, there are some footguns that get worse with extendedLifetime shared workers (see https://github.com/whatwg/html/issues/10997#issuecomment-3105509844). Therefore it's safer to not combine these two separate invocations and instead "enforce strict separation between the two lifetime modes.", which I believe from https://github.com/whatwg/html/issues/10997#issuecomment-2791533299 is done with option 4 out of the solutions proposed:

4. Only the first new SharedWorker() invocation controls the lifetime. All others have to match, and if they don't match, we throw an exception or fail the worker creation.

[Yoshisato Yanagisawa]

Hi everyone,

I'd like to provide some context regarding the SharedWorker persistence during navigation.

To clarify, this behavior is not a regression introduced by recent BFCache changes. Rather, the recent updates corrected an inaccuracy where BFCached clients were misidentified as "active," which had been masking this behavior for a while. I’ve been aware of this long-standing issue since I took over the *Worker component (see also https://issues.chromium.org/issues/40284712).

I did previously attempt to address this by implementing a 5-second survival buffer (crrev.com/c/4924910), but that approach resulted in significant test flakiness and stability issues, which is why we didn't proceed with it at that time.

Looking ahead, this situation should be naturally mitigated as we roll out kFreezeSharedWorker. With that implementation, the client will be properly BFCached and frozen, and the SharedWorker will be kept alive until the client is evicted. This provides a more robust path to persistence that avoids the instability we previously encountered.

Best,
Yoshisato

2026年4月28日(火) 23:10 Barry Pollard <barryp...@google.com>: