Keep sharedWorker alive durning reload / next-page

[jimmywarting]

While searching for a solution to keep SharedWorker alive durning reload and keeping the state intact and not having to fetch all the resources over again and again durning page reload / navigation when only having one tab open

i found out that my SharedWorker was terminated when the current page died. and the state in the shared worker where lost.
i only have one tab open but i would wish for it to stay alive to the next page.

I happen to stumble upon this in the spec:

The second part of this definition allows a shared worker to survive for a short time while a page is loading, in case that page is going to contact the shared worker again. This can be used by user agents as a way to avoid the cost of restarting a shared worker used by a site when the user is navigating from page to page within that site.

https://html.spec.whatwg.org/multipage/workers.html#the-worker's-lifetime

I tried every way i could think of to keep the SharedWorker alive but it ended in failure.
Tried reload the page, tried navigating to a page
where also about to try portals but that trail period have ended and i don't see a chrome flag for it anymore. maybe it was something about being replaced with "View Transition"

[annevk]

Can you demonstrate this using a test in web-platform-tests?

[jimmywarting]

I could not find any existing test that tested the lifetime of SharedWorker durning reload.
I think only Service Worker can stay alive durning a reload / page navigation.

[annevk]

That's not how shared workers are defined. I recommend writing a test.

[jdeepwell]

I ran into the same issue. I also need the Shared Worker to stay alive during page transitions. I am creating a WebSocket connection in it and it would be bad if that was re-created over and over again for each page transition.

After some testing I was able to boil it down to something testable (see attached files).

The Shared Worker seems to be restarted in the following scenario:

• Only one window/tab of the site is open
• The page(s) loaded have a Cache-Control: no-store, no-cache, must-revalidate header
• The user navigates from one page to another

As long as the pages do not have the Cache-Control header, everything is fine (the Shared Worker does not get restarted on page transitions). Even when the pages are really fetched from the server! - I made sure they are when using the navigation links by appending a random query (and checking on the server side that they really are fetched).

So the fact that the pages are actually loaded from the server (and not served from the cache) is not the issue.

It's when the pages have Cache-Control headers that prevent caching that leads to the Shared Worker being restarted.

Test

(attached)

• sw_page_1.php
• sw_page_2.php
  Example pages (need PHP to generate HTTP headers)
• sw_page.js
  JS included by the example pages, create/connect to Shared Worker
• sw_worker.js
  The Shared Worker

When using the example as is you can navigate between the pages and the Shared Worked will keep running from page transition to page transition.

It is only when you enable the remarked lines that generate the header that it stops working - then the Shared Worked will be restarted with every page transition.

Tested with Chrome 124.0.6367.202 (Official Build) (arm64) and Firefox 125.0.3 (64-bit) on macOS 14.4.1 (23E224).

---

Remark

Keeping Shared Workers alive during page transitions to me seems like an essential part of the definition and purpose of a Shared Worker. The "shared" to me not only means shared between windows/tabs but also shared between pages/requests within a single window/tab. It would be a shame if we had to fall back on Service Workers all the time for such behaviour.

And if the Shared Workers are behaving as stated in the documentation ("...shared worker to survive for a short time while a page is loading...") then I see no reason why this should depend on the caching policy of the page resources using the code that uses the worker (if anything then maybe the caching policy for the Shared Worker code resource itself).

SharedWorkerDying.tgz