By Craig Buckler

JavaScript Execution and Browser Limits

By Craig Buckler

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 uses a timed limit of 10 seconds.

Safari uses a timed limit of 5 seconds.

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

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.

  • 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.

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

  • 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’.

    • 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…..

  • 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.

Get the latest in JavaScript, once a week, for free.