Web Workers, Done Properly
Background threads that run JavaScript separately from the page's main thread, used for heavy computation such as parsing data, image processing or search indexing.
Marcus Adeyemi
Why does it matter?
Work done in a worker cannot block scrolling or input, which makes workers one of the few ways to run heavy JavaScript without hurting responsiveness.
What are the numbers?
- DOM access workers cannot access the DOM directly
- Communication messages are passed with postMessage
- Types dedicated workers, shared workers and service workers
- Transferable objects large data can be transferred without copying
What should I do?
- Move CPU-heavy work that does not need the DOM to a worker
- Keep messages small or use transferable objects
- Handle worker errors explicitly
- Measure main-thread time before and after
- Reuse a worker instead of creating one per task
What should I avoid?
Avoid:
- Sending huge objects back and forth on every message
- Moving tiny tasks to workers
- Assuming workers fix slow network requests
- Starting many workers on low-end devices
When should I get help?
Short answer Bring in help when an application does heavy data processing in the browser, or when profiling shows long computation tasks.
Where this comes from
- MDN Web Docs — Using Web Workers
- web.dev — Use web workers to run JavaScript off the browser's main thread
The figures and practices above come from the sources listed.
Working on something like this?
We take on Performance & Accessibility work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
