Web Workers in IE10: Background JavaScript Makes Web Apps Faster

July 2nd, 2011

Responsive Web pages result in happier consumers. With Web workers, Web applications are more responsive by offloading complex JavaScript algorithms to run in the background. For example, in this test drive (link), you can see that offloading the work to calculate movement of water in the fountains via Web workers makes the main page more responsive for consumers:

For a closer look at the code behind this demo, watch this video.

This example (link) shows the difference in how Web workers help run the ECMAScript test suite much faster. With Web workers, the script on the page runs in parallel without the interruptions of page updates. The difference in elapsed time between today’s programming model and what is possible using Web workers will help the Web get faster.

IE10 Platform Preview 2 includes complete tooling support for Web workers. All of the existing tooling that the F12 developer tools provide for script debugging now works exactly the same for workers, without requiring a simulated environment (e.g. using iframes to emulate a worker). For example, in the image below, the developer paused the script in a worker and can inspect and debug the correct WorkerGlobalScope. We’ll write about Web worker tooling in more detail in an upcoming post.

IE10 also includes support for channel messaging, so Web workers can work together without the Web page itself needing to coordinate their work. You can try this out in the test drive with the checkbox that says “use lighting effects (requires channel messaging).” Note that this checkbox is disabled in Firefox since that browser does not currently support channel messaging.

Looking at the standards specifications, IE10 Platform Preview 2 includes interoperable support for the W3C Web workers specification along with related features specified in W3C Web messaging specification (channel messaging as discussed above) as well as the HTML5 specification (the structured clone algorithm). Additionally, to help the specification and browser implementations improve, Microsoft has published 50 tests for this specification on the IE testing center.

New Web App Scenarios with Background JavaScript

Web workers enable a host of new programming scenarios for the Web. For example, casual games might choose to run the logic for the “computer player” in a Web worker while users take their turn.

Web workers are a way for a Web page to execute script in the background, in parallel to the page. The main Web page can be much more responsive by separating itself from these long-running and intensive scripts and communicating with them through messages.

Previously, Web applications avoided complex JavaScript algorithms and long-running processing because these activities blocked the Web page from responding to user tasks or updating content on the page. When JavaScript runs too long without yielding, users experience slow response from the Web page and in extreme cases the Web page appears to hang (here’s an example in the context of IE9’s improved hang protection). Web workers enable these complex JavaScript algorithms to run with little impact on the user’s experience on the site.

Web workers also enable MVC-style Web page design. MVC designs aim to separate an application’s model from its view and controller (user-input). By designing a Web page with all the business logic on a Web worker (the “model”), the Web page can be the view and controller and remain responsive to the user.

While these may look like “threads” for JavaScript, technically there are a few key differences relative to other programming languages. Web workers do not share state with the Web page, and they lack synchronization primitives like locks, critical sections, semaphores, or mutexes. Web workers typically are “long lived,” and start their own event loop and wait for further input once they are started, rather than immediately terminating.

As always, please use feature detection to accommodate browsers (for example on mobile devices) that don’t yet have support:

if (window.Worker) {

      /* Use Web Workers in this browser */


Workers and Privacy

Microsoft has communicated privacy concerns (link) about the design of shared workers (link) in the W3C draft specification to the working group, along with a proposal for a way to resolve the issue. Unlike a regular worker that is dedicated to a single page, a shared worker can have different Web pages connect to it. We believe that allowing any two top level domains (e.g. a banking site and a potential attacker, or any site and a potential tracking site) to share a Web worker creates privacy issues. We remain committed to the Security Development Lifecycle (link) and making informed decisions about the security risks consumers face.

As the dialog continues, we look forward to the working group reaching consensus on a design that does a better job respecting consumer privacy.

What workers can do: The Web Worker “Mini-DOM”

The “Mini-DOM” is how Web workers maintain separate state from the Web page. Each worker has its own “Mini-DOM” so it can operate independently of the full Web page and other workers.

The diagram below compares the DOM of a Web page to the Mini-DOM of a worker. Like the main Web page, Web workers have a JavaScript engine with all the typical JavaScript libraries (e.g., Math, Date, Array, etc.).  Unlike the main Web page, Web workers do not have access to anything related to the “view” of the Web page, like the window, document, elements, or attributes. Instead, there is a “worker global scope” object (accessible via the “self” property), which contains a few APIs of the window object (such as “setTimeout” and “postMessage”).

Using Web workers, developers make clear choices in what functionality they offload to maximize computation while retaining Web page responsiveness.

Please download IE10 Platform Preview 2, try out the Web worker demos (link, link), and send us your feedback!

-Travis Leithead
IE Program Manager