Web Workers in IE10: Background JavaScript Makes Web Apps Faster

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:

This video shows Web Workers in action in the second IE10 Platform Preview.

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.

Screenshot of F12 developer tools at a breakpoint in a web worker with the Watch list open showing 'this' being of type WorkerGlobalScope

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”).
Image comparing the execution environment of a web page to that of a web worker with the worker environment does not include window, the document, elements, or attributes

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

Comments (24)

  1. Alex says:

    Built in debugging for web workers – so cool!

  2. John says:

    Obligatory post about how [other browser] had this feature first.

    In all seriousness though, awesome job guys. Can't wait for Win8/IE10.

  3. Will Peavy says:

    That is very good news. I'm looking forward to using web workers in IE10. If you guys include pushState() as well, then I'd be very excited.

  4. CnEY says:

    It's awesome to see IE10 finally getting this.  Now if only we can get users off all prior versions, stat…

    I have to wonder though, isn't calling it "mini-DOM" kinda misleading?  location and navigator are more BOM than DOM, XHR isn't really DOM, and the stuff below the red line is really JS proper, not DOM at all.  I've usually heard web workers described as not having access to DOM at all.

  5. David Bruant says:


    Thanks for this article and this explanations. I'd ike to point out a couple of things, though.

    I think the "What workers can do: The Web Worker 'Mini-DOM'" is very misleading. XHR, Location, Navigator, setTimeout have nothing to do with the DOM (Document Object Model) especially since they are not related to any document. They are just some JavaScript features being there alongside with the DOM usually, but independent nonetheless.

    Also, when you say: "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 do not lack anything. Not only they have no shared states with the web page, but they have no shared memory at all with the web page and other workers. Consequently, they do not *lack* locks, critical sections, etc. because they don't *need* them. These artifacts exist when paralellism exists with shared memory.

    Instead communication between workers in JS works by message passing (always copying the content of the message since nothing can be shared) and the event loop. This has the advantages of preventing web devs to have to think of deadlocks and some sorts of race conditions, but may have a cost in terms of performance. That's a trade-off.

  6. Mike Gale says:

    A thought crossed my mind as I read this.

    How well can these web workers implement an Actor style of programming?

    Is the messaging performant and robust enough?

    Has anybody given that a try?  If so what findings.

  7. yellowstone says:

    Why is he still .jxr (JPEG XR image files), we do support?

    Please jxr image files.   (Translate)

  8. johnnyq3 says:

    Windows supports it as a default but uses .hdp which is still a form of JPEG XR except a different file type.

  9. ahmad sahbazi says:


  10. Grant Galitz says:

    How can we get how many CPU cores there are directly in JS? This is very useful for determining how many web workers to spawn.

    navigator.cpuCores ?

  11. John Jameson says:

    I can't see the video. Could you also provide a WebM version? Ta.

  12. giuseppe says inefficient (2nd attempt *) says:

    CnEY and David Bruant are right.

    IMHO "mini-DOM" is a term from marketing people targeting the stereotypical webdeveloper who does not know what the DOM is because of quirks abstraction frameworks that according to some fat guy know better how to design an API than the w3c.

    But that's just names, their meanings change (bandwidth in Hz anyone?)

    What concerns me more is following problem:

    With Webworkers, I get +50% fps, but cpu load is atleast +70%. This is less efficient and thus useless. And the reason is, that the whole data has to be copied all the time, appearantly in form of an string serialization, where a 32bit Number can easily take up more than 4 times the size (that is 4x, pronounced 'four ex' for the cool kids). I believe there are even techniques involved (fat guy again) that add additional overhead.

    TypedArrays could help, but they are probably to high a security risk for some strategic minds. However I would be happy if a secure way of passing messages just a little bit less stupid than currently was brought up. Maybe take it from SL d3d, which I hear does not share any of the strategic security concerns.

    Thanky you very much.

    *) blogs.msdn.com comment system: making MSFT look like complete idiots for years now.

    ps. May I wonder what's with the flash video? Ditching SL in favor of flash? What is this going to be? An anti webgl alliance of the only two that are against it, … ah sorry, i mean, that provide more secure alternatives?

  13. IE fan says:

    IE team why in IE9 I cannot save this page successfully as a web archive? http://www.atpworldtour.com/No-1-Novak.aspx It saves but the background doesn't get saved properly. But I can save the same page in Safari (.webarchive) format and it renders successfully. FIX IE's broken MHTML saving.

  14. Matthew says:

    Look, I don't want to be just another hater.  In fact, I don't want to be a hater at all.  But I'm deeply discouraged that when IE10 is released, web developers will STILL need to support IE6 and IE7 because of their consistently-high usage.  And, of course, if they're on Windows XP (which something like half of people still are?), then they can only upgrade as high as IE8.  

    Can't Microsoft do more to compel people to use a modern browser?

  15. Jason says:

    @Matthew – I totally agree.  More importantly some developers will make games/sites that push IE9/IE10 to the max, and users will complain that IE8 doesn't work… support it!

    its a 50/50.  I love that this stuff is coming, but man we need to deprecate IE6 AND IE7, and in 2012 deprecate IE8.

  16. Leigh Marconi says:

    @Matthew: "And, of course, if they're on Windows XP (which something like half of people still are?), then they can only upgrade as high as IE8. Can't Microsoft do more to compel people to use a modern browser?"

    Windows 2000, Windows XP, Windows Vista, and Windows 7 users can upgrade to Firefox for a better Web experience. Mozilla has better Windows support than Microsoft does. I think the easiest course of action to get more people using a modern browser is for Microsoft to promote Firefox.

  17. Rob says:

    @Leigh is absolutely correct. Microsoft HAS been helping promote modern browser usage as half of all users no longer use IE compared to the 95% market share they had just six or so years ago. Now, with no support for newer versions of IE in the most used versions of Windows, Microsoft helps even more users choose a far, far better browser than anything IE has to offer. It's win, win!

  18. IE Fan says:

    Bring back the search box please. Here's why: petermeinl.wordpress.com/…/why-i-dislike-ie-9. I have posted a suggestion to bring back the search box on Connect like countless others. Now let's see if Microsoft really listens to feedback from so many users asking to bring the dedicated search box back. The beta of IE10 MUST bring the search box back or I am going to use exclusively IE8 on Windows 7 and Vista and prompt all my contacts to uninstall and block IE9.

  19. Mike Gale says:

    That search box issue is indeed a killer.  I raised in during IE9 beta feedback as did others.

    A configuration to get rid of the ridiculous (for some) design seems reasonable.

    I use a range of browsers, this design feature makes me use IE9 less.

    The web seems to have dumbed down in some ways over the last ten years.  Browser designers might listen unduly to focus groups.  If the do I reckon they're groups of novices.  This can be a kick in the face for those who are more aware.

    If there was a reasonable way of configuring a browser (not BHO's etc, something easier to use) then serious users could save themselves hours every week, byu more than banishing awkward search boxen.  Get into flow more often…

    Another tragedy of the commons.  Dumbed down UI's.

    We're walking backwards…  I imagine there's sizable opinion in the design team that this is not smart.

  20. Roman says:

    "The beta of IE10 MUST bring the search box back or I am going to use exclusively IE8 on Windows 7 and Vista and prompt all my contacts to uninstall and block IE9."

    ROFL, you are so threatening!

  21. zedd says:

    This looks great, but does the IE team intened to follow standards and allow us to use progressive enhancement and not use vendor specific prefixes?  This won't be some -ms: Filter garbage will it?

  22. <a href="http://parkerenschipholgratis.nl">John Wickens</a> says:

    Such speed, already need to deprecate IE6 and IE7, and in 2012 we need to already deprecate IE8.

  23. soham joshi says:

    I liked your way of presentation. The information you provided is great, Thank you for this, and hope in future you will come with more knowledgeable information.