35

What is the difference between Service Worker and Shared Worker?

When should I use Service Worker instead of Shared Worker and vice versa?

Lewis
  • 11,912
  • 9
  • 59
  • 79
  • 1
    Per [specs (draft as of 2015-02-05)](http://www.w3.org/TR/service-workers/), a service worker is a type of web worker, which responds to events dispatched from documents and other sources. – Ray Shan Mar 08 '15 at 09:11

3 Answers3

26

A service worker has additional functionality beyond what's available in shared workers, and once registered, they persist outside the lifespan of a given web page.

Service workers can respond to message events, like shared workers, but they also have access to additional events. Handling fetch events allows service workers to intercept any network traffic (originating from a controlled page) and take specific actions, including serving responses from a Request/Response cache. There are also plans to expose a push event to service workers, allowing web apps to receive push messages in the "background".

The other major difference relates to persistence. Once a service worker is registered for a specific origin and scope, it stays registered indefinitely. (A service worker will automatically be updated if the underlying script changes, and it can be either manually or programmatically removed, but that's the exception.) Because a service worker is persistent, and has a life independent of the pages active in a web browser, it opens the door for things like using them to power the aforementioned push messaging—a service worker can be "woken up" and process a push event as long as the browser is running, regardless of which pages are active. Future web platform features are likely to take advantage of this persistence as well.

There are other, technical differences, but from a higher-level view, those are what stand out.

Jeff Posnick
  • 45,379
  • 12
  • 113
  • 142
  • 8
    Service Workers have very short life times: ["Developers are advised to keep in mind that service workers may be started and killed many times a second."](http://www.w3.org/TR/2015/WD-service-workers-20150205/#motivations). Though, you might not mean the same thing when you say "lifespan". – Noah Freitas Jun 24 '15 at 01:57
  • 1
    So, web worker lives with page only, while service worker lifecycle is completely separate from page? + service worker has access to cache storage, and special events (like 'fetch'). Any idea why they created **new entity**? Why not just add some special flag to existing web worker, like 'stay alive when page is closed' or something, and add required events and API? – artin Mar 09 '16 at 09:59
  • Service workers are not persistent. They are request handlers - one instance per request/response pair. This allows many concurrent requests and responses without blocking the DOM. Even XHR requests block the DOM in the response. That is because all workers have their own context/event loop. – Dominic Cerisano Jan 25 '17 at 17:19
  • 1
    @NoahFreitas, Isn't that the same as with sharedworkers? – Pacerier Oct 16 '17 at 07:04
  • 1
    @Pacerier the most relevant difference here is the "lifespan" of a sharedworker is established programmatically by the application (via `new SharedWorker` and calling terminate on that worker); whereas for a service worker the browser itself decides how long a worker instance lives and when it begins based on registered event listeners. – Noah Freitas Oct 16 '17 at 18:01
  • 1
    I see this answer is from 5 years ago. is it still up-to-date? – Zach Smith Apr 04 '20 at 17:11
21

A SharedWorker context is a stateful session and is designed to multiplex web pages into a single app via asynchronous messaging (client/server paradigm). Its life cycle is domain based, rather than single page based like DedicatedWorker (two-tier paradigm).

A ServiceWorker context is designed to be stateless. It actually is not a persistent session at all - it is the inversion of control (IoC) or event-based persistence service paradigm. It serves events, not sessions.

One purpose is to serve concurrent secure asynchronous events for long running queries (LRQs) to databases and other persistence services (ie clouds). Exactly what a thread pool does in other languages.

For example if your web app executes many concurrent secure LRQs to various cloud services to populate itself, ServiceWorkers are what you want. You can execute dozens of secure LRQs instantly, without blocking the user experience. SharedWorkers and DedicatedWorkers are not easily capable of handling many concurrent secure LRQs. Also, some browsers do not support SharedWorkers.

Perhaps they should have called ServiceWorkers instead: CloudWorkers for clarity, but not all services are clouds.

Hopefully this explanation should lead you to thinking about how the various Worker types were designed to work together. Each has its own specialization, but the common goal is to reduce DOM latency and improve user experience in web based applications.

Throw in some WebSockets for streaming and WebGL for graphics and you can build some smoking hot web apps that perform like multiplayer console games.

Dominic Cerisano
  • 2,789
  • 25
  • 41
3

2020 11 Update

Important detail for anyone interested in this discussion: SharedWorker is NOT supported by WebKit (was intentionally removed ~v6 or something).

WebKit team are explicitly suggesting to use ServiceWorker wherever SharedWorker might seem relevant.

For a community wish to get this functionality back to WebKit see this (unresolved as of now) issue.

GullerYA
  • 719
  • 6
  • 20