- HTML5 Web Workers
- Creating a Web Worker
- Communicating With the Web Worker
- Exchanging JSON
- Web Worker Implementation
- Web Worker Live Example
- The Web Worker Sandbox
- Importing JavaScript in a Web Worker
- SharedWorker
- Creating a SharedWorker
- Connecting to a SharedWorker
- Sending Messages to a SharedWorker
- SharedWorker Implementation
- SharedWorker Live Example
- Web Workers API
- Web Workers concepts and usage
- Worker types
- Worker global contexts and functions
- Supported Web APIs
- Web Worker interfaces
- Examples
- Specifications
- See also
- Found a content problem with this page?
- MDN
- Support
- Our communities
- Developers
HTML5 Web Workers
The Web Workers API makes it possible to execute a JavaScript file asynchronously and autonomously. A web worker is essentially a thread executing a JavaScript file. Thus, using web workers you can achieve multi threading in your web applications.
Creating a Web Worker
You create a web worker like this:
var worker = new Worker("http://jenkov.com/worker.js");
The string passed as parameter to the Worker() is the URL of the JavaScript file to execute.
Communicating With the Web Worker
You communicate with the web worker using the HTML5 Messaging API, by posting messages to, and receiving messages from, the web worker. Here is an example:
var worker = new Worker("http://jenkov.com/worker.js"); worker.onmessage = function(event) < alert("Reply: " + event.data); >worker.postMessage("Hello worker!");
First a Worker is created.
Second, an onmessage event listener function is set on the web worker. This function is called when the worker sends messages back to the page that created it.
Third, a message is sent to the web worker using the worker.postMessage() function.
The web worker can respond like this:
this.onmessage = function(event)
This code is part of the JavaScript file executed by the web worker. The this keyword is a reference to the web worker instance itself. An onmessage event listener function is added to the web worker. This is not the same onmessage listener as the page creating the web worker added, even if both were added on the worker instance. The web worker responds to the message using the postMessage() .
Exchanging JSON
In the first implementations of web workers the browsers only allowed strings to be exchanged as messages. You can encode a JSON object using the JSON.stringify() function and decode it again using the JSON.parse() function.
However, recent implementations allow for exchange of values or JSON objects that can be handled by the structured clone algorithm.
Web Worker Implementation
Here is a full implementation of a web worker:
this.onmessage = function(event) < postMessage("Reply from web worker"); >//Implementation of web worker thread code setInterval(function() < runEveryXSeconds() >, 5000); function runEveryXSeconds()
This web worker implementation listens for messages, as well as sends a message every 5 seconds to the page that started it.
Web Worker Live Example
Here you can execute the example code shown earlier. Click the button below to execute the example.
To stop the messages sent back every 5 seconds, hit refresh in the browser.
The Web Worker Sandbox
The web workers run in a kind of sandbox, meaning that the web worker has limited access to the features JavaScript normally has access to when executed in a browser.
A web worker does not have access to the DOM of the page that creates the web worker.
Here is a list of what a web worker can do inside the web worker JavaScript:
- Listen for messages, using the onmessage event listener function.
- Send messages via the postMessage() function.
- Send AJAX requests using the XMLHttpRequest.
- Create timers using the setTimeout() and sendInterval() functions.
- Web Sockets
- Web SQL Databases
- Web Workers
- Import more scripts using importScripts()
Importing JavaScript in a Web Worker
You can import JavaScript files for use in your web worker, using the importScripts() function. This is a special function available in a web worker. Here is an example:
importScripts("myscript.js"); importScripts("script1.js", "script2.js");
You can load one or more scripts using the importScripts() function, as you can see from the example above. The scripts are loaded synchronously, and executed one at a time.
SharedWorker
An ordinary web worker is only accessible by the page that created it. If you want to share a web worker between multiple pages, you can use a SharedWorker . A SharedWorker is accessible by all pages that are loaded from the same origin (domain).
Creating a SharedWorker
You create a SharedWorker like this:
var worker = new SharedWorker("shared-worker.js");
The string passed as parameter to the SharedWorker constructor is the URL of the JavaScript the SharedWorker is going to execute.
All pages that create an instance of a SharedWorker with the same URL passed as parameter, will essentially get a connection to the same SharedWorker behind the scenes.
Connecting to a SharedWorker
A SharedWorker has a concept called ports through which the various pages that reference the SharedWorker can communicate with it. The API is again similar to the HTML5 Messaging API.
Here is an example of how to add a message listener to the port of a SharedWorker :
var worker = new SharedWorker("/html5/web-worker-shared.jsp"); worker.port.addEventListener("message", function(event) < alert(event.data); >, false ); worker.port.start();
First at SharedWorker is created. Second, a message event listener function is added to the SharedWorker ‘s port. Third, the port is started. If you do not start the port, you cannot send messages to the SharedWorker .
Sending Messages to a SharedWorker
Once the port is started and your page is listening for messages on the port, you can send messages to the SharedWorker using the port.postMessage() function. Here is an example:
worker.port.postMessage("First Message");
SharedWorker Implementation
A SharedWorker , like an ordinary web worker, needs an implementation in a JavaScript file. Here is an example implementation:
var ports = [] ; onconnect = function(event) < var port = event.ports[0]; ports.push(port); port.start(); port.addEventListener("message", function(event) < listenForMessage(event, port); >); > listenForMessage = function (event, port) < port.postMessage("Reply from SharedWorker to: " + event.data); >//Implementation of shared worker thread code setInterval(function() < runEveryXSeconds() >, 5000); function runEveryXSeconds() < for(i = 0; i < ports.length; i++) < ports[i].postMessage("Calling back at : " + new Date().getTime()); >>
This implementation first creates an array for storing the ports of all the pages that connects with the SharedWorker .
Second, an onconnect function is defined. This function is called when a page connects to the SharedWorker .
The onconnect function first obtains the port to the connecting page, stores it in the port array and then starts the port. If you do not start the port, you cannot receive messages from it. Finally the onconnect function adds a message listener function to the port. Notice how a new anonymous function is created for each page connecting. This anonymous function captures the port to the connecting page and passes it as parameter to the listenForMessage() function called from the anonymous function.
After the onconnect function is a definition of the event listening function listenForMessage() This function simply responds to the port from which the message was received with a simple message.
The last part of this SharedWorker contains the implementation of the autonomous behaviour this SharedWorker has. The setInterval() function is called to make the runEveryXSeconds() execute every 5 seconds (5000 milliseconds).
The runEveryXSeconds() simply iterates all the connected ports and write a message to them. A more advanced implementation could connect to a server and fetch data which could be distributed to all the pages connected to the SharedWorker .
SharedWorker Live Example
Here is a live example of a SharedWorker . Start the SharedWorker by clicking the button on the left. Send a message to the SharedWorker by clicking on the button on the right.
Web Workers API
Web Workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.
Web Workers concepts and usage
A worker is an object created using a constructor (e.g. Worker() ) that runs a named JavaScript file — this file contains the code that will run in the worker thread.
In addition to the standard JavaScript set of functions (such as String , Array , Object , JSON , etc.), you can run almost any code you like inside a worker thread. There are some exceptions: for example, you can’t directly manipulate the DOM from inside a worker, or use some default methods and properties of the window object. For information about the code that you can run see worker global context and functions, and supported web APIs below.
Data is sent between workers and the main thread via a system of messages — both sides send their messages using the postMessage() method, and respond to messages via the onmessage event handler (the message is contained within the message event’s data property). The data is copied rather than shared.
Workers may in turn spawn new workers, as long as those workers are hosted within the same origin as the parent page. In addition, workers may use XMLHttpRequest for network I/O, with the exception that the responseXML and channel attributes on XMLHttpRequest always return null .
Worker types
There are a number of different types of workers:
- Dedicated workers are workers that are utilized by a single script. This context is represented by a DedicatedWorkerGlobalScope object.
- Shared workers are workers that can be utilized by multiple scripts running in different windows, IFrames, etc., as long as they are in the same domain as the worker. They are a little more complex than dedicated workers — scripts must communicate via an active port.
- Service Workers essentially act as proxy servers that sit between web applications, the browser, and the network (when available). They are intended, among other things, to enable the creation of effective offline experiences, intercept network requests and take appropriate action based on whether the network is available, and update assets residing on the server. They will also allow access to push notifications and background sync APIs.
Note: As per the Web workers Spec, worker error events should not bubble (see Firefox bug 1188141. This has been implemented in Firefox 42.
Worker global contexts and functions
Workers run in a different global context than the current window ! While Window is not directly available to workers, many of the same methods are defined in a shared mixin ( WindowOrWorkerGlobalScope ), and made available to workers through their own WorkerGlobalScope -derived contexts:
Some of the functions (a subset) that are common to all workers and to the main thread (from WindowOrWorkerGlobalScope ) are:
- atob()
- btoa()
- clearInterval()
- clearTimeout()
- dump() Non-standard
- queueMicrotask()
- setInterval()
- setTimeout()
- structuredClone()
- window.requestAnimationFrame (dedicated workers only)
- window.cancelAnimationFrame (dedicated workers only)
The following functions are only available to workers:
Supported Web APIs
Note: If a listed API is supported by a platform in a particular version, then it can generally be assumed to be available in web workers. You can also test support for a particular object/function using the site: https://worker-playground.glitch.me/
The following Web APIs are available to workers:
- Barcode Detection API
- Broadcast Channel API
- Cache API
- Channel Messaging API
- Console API
- Web Crypto API (e.g. Crypto )
- CSS Font Loading API
- CustomEvent
- Encoding API (e.g. TextEncoder , TextDecoder )
- Fetch API
- FileReader
- FileReaderSync (only works in workers!)
- FormData
- ImageBitmap
- ImageData
- IndexedDB
- Media Source Extensions API (dedicated workers only)
- Network Information API
- Notifications API
- OffscreenCanvas (and all the canvas context APIs)
- Performance API , including:
- Performance
- PerformanceEntry
- PerformanceMeasure
- PerformanceMark
- PerformanceObserver
- PerformanceResourceTiming
Workers can also spawn other workers, so these APIs are also available:
Web Worker interfaces
Represents a running worker thread, allowing you to pass messages to the running worker code.
Defines the absolute location of the script executed by the Worker .
Represents a specific kind of worker that can be accessed from several browsing contexts (i.e. windows, tabs, or iframes) or even other workers.
Represents the generic scope of any worker (doing the same job as Window does for normal web content). Different types of worker have scope objects that inherit from this interface and add more specific features.
Represents the scope of a dedicated worker, inheriting from WorkerGlobalScope and adding some dedicated features.
Represents the scope of a shared worker, inheriting from WorkerGlobalScope and adding some dedicated features.
Represents the identity and state of the user agent (the client).
Examples
We have created a couple of demos to show web worker usage:
You can find out more information on how these demos work in Using Web Workers.
Specifications
See also
Found a content problem with this page?
This page was last modified on Jul 5, 2023 by MDN contributors.
Your blueprint for a better internet.
MDN
Support
Our communities
Developers
Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998– 2023 by individual mozilla.org contributors. Content available under a Creative Commons license.