Why aren't Web Workers used more?

The main reasons they're not used much (in my opinion):

  1. Inertia. They're a relatively new tech, and people haven't taken the time to learn them yet. You went to a talk about it, which means you're ahead of the curve; there's a lot of people out there who haven't even heard the term 'web worker' yet, much less thinking about coding them.

  2. Browser compatibility. Older browsers don't support them. Most people still need to support at least IE8 for their sites, so can't use tech like this yet.

  3. Why bother? The only reason for using a new technology is if it solves a problem or achieves something new. Most sites don't have any real need for web workers. Or even if they do, they don't see the need.

  4. Not shiny enough. The web is a very visual medium, and a lot of the new browser features in the last few years have been very visual. It's easy to persuade someone to try a new feature if it looks good. Web workers are entirely non-visual; the benefits are abstract. Developers may get it, but for most companies the decisions about what to spend time and money on to improve a site are made by non-developers, which makes it harder for web workers to get a look in.


Since most answers to this question are a few years old, here's my perspective on the current state of things, as of May 2019.

Web Workers are now supported in commonly-targeted browsers, and I'd argue that browser support is no longer a significant obstacle to their use. Despite that, Web Workers still aren't commonly used, and most web developers I interact with don't use them.

Certainly not every website needs to do enough heavy lifting to justify a Web Worker; many websites don't need JavaScript at all. So, I wouldn't expect to see Web Workers in a majority of websites realistically.

But "heavy lifting" is not the only factor in justifying a Web Worker – another is ease of use. Web Workers are a significant challenge to use in many contexts. Note that the Web Worker API involves splitting your build outputs into separate files, or generating that code (e.g. with Data URIs or fn.toString()) at runtime. Web developers use many different build systems, and often have many dependencies in their projects. Configuring the project to create these additional build artifacts with the right dependencies can be difficult, or at least it varies with the build system you have.

Furthermore, this work almost invariably has to be done by each web developer, for each individual project. You could expect much higher Web Worker adoption if WWs were commonly used inside the popular libraries and frameworks that developers already depend on. But they aren't (for API-related reasons, if I had to guess), even for libraries that do a significant amount of synchronous work. And as long as using the main thread is the default, easiest thing to do, that's what most developers will continue to do.