JavaScript Execution and Browser Limits

Contributing Editor

The browser UI and JavaScript code (effectively*) share a single processing thread. It doesn’t matter whether the browser needs to respond to its own menu click, render an HTML page or execute your Ajax call — every event is added to a single queue. When the browser becomes idle, the next item on it’s to-do list is retrieved and executed.

note: Single Browser Threads

In reality, no modern browser operates on a single thread. As an extreme example, IE9 and Chrome start a new OS process for every tab. However, there is still a single event queue per viewed page and only one task can be completed at a time. This is absolutely necessary because the browser or your JavaScript can alter the rendered HTML before, during or after it’s downloaded.

Understandably, the browser must limit the time it takes for your JavaScript code to run. If a script takes too long, it will lock the application and potentially cause OS instability. It’s the reason you’ll see the dreaded “Unresponsive Script” alert:

Unresponsive Script

But how does a browser determine when a script has run for too long? As you’d expect, the top 5 vendors implement different techniques and limits…

Internet Explorer
IE limits JavaScript execution to 5 million statements.

Firefox
Firefox uses a timed limit of 10 seconds.

Safari
Safari uses a timed limit of 5 seconds.

Chrome
Chrome does not limit execution but detects when the browser crashes or becomes unresponsive.

Opera
Opera does not implement a limit and will execute JavaScript indefinitely. However, the browser will not cause system instability — you can continue to open other tabs or close the page executing the code.

Several of the browsers allow you to configure the execution limit parameters, but that’s not something I’d recommend. I won’t publish the details here because someone, somewhere will use it as a “fix” for their unresponsive page! Google it if you like, but tweaking browser settings for badly-behaved code does not address the root of the problem.

So how can we prevent JavaScript execution alerts? The best solution is to avoid long-running client-side tasks. Ideally, no event handler should take longer than a few dozen milliseconds. Intensive processing jobs should normally be handled by the server and retrieved with a page refresh or an Ajax call.

However, I’m conscious that minimizing client-side processing is not necessarily a viable solution for today’s JavaScript-heavy applications. Fortunately, there are a number of solutions … stay tuned to SitePoint for several alternatives coming soon.

note:Want more?

If you want to read more from Craig, subscribe to our weekly tech geek newsletter, Tech Times.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.users.on.net/~gulati/ AnilG

    It’s nice to think you can run all heavy processing on the server but the direction I’ve been travelling is to put as much on the client as possible; to minimise latency.

    When I was doing this around 2006/2007 IE couldn’t actually cope (frequent hanging) with the JavaScript processing load I was putting through it and we had to terminate support for that browser.

    I’m keen to try again now with the browser improvements we’ve had since then. I don’t think you can discount heavy client side processing requirements. We’re going to want to do more and more on the client.

  • frio80

    Interested to see the techniques. Timing out and giving up execution is the current methodology I use to combat this problem. Nicholas Zakas of Yahoo has a great write up. http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/

    • http://www.optimalworks.net/ Craig Buckler

      Thanks frio80. Watch out for my next few articles where I discuss similar techniques.

  • http://www.cemerson.co.uk Stormrider

    Would be nice not to have broken this up into several days posts, because this post basically consists of ‘Sometimes JavaScript takes ages to run’.

    • http://www.optimalworks.net/ Craig Buckler

      I hope it provides a little more information than that … knowing how each browser sets the limit is important! There are 4 further posts coming which describe various ways of overcoming long-running task issues.

      • aamonkey

        I agree – the blog posts here are becoming ridiculous. I understand the goal is to constantly create fresh content, but when you start splitting up what are effectively a few semi-useful excerpts into multi-part series…..well, you’ll have to wait for my next post response to hear how I feel about that…..

  • http://www.deathshadow.com deathshadow60

    One good technique for handling really long tasks is to break it up into smaller groups and then use settimeout with a delay of 0 between them. Even a zero delay will return control to the browser long enough for the warning about execution time to never trip.

    • http://www.optimalworks.net/ Craig Buckler

      Shhh, you’ll spoil the next installment!