Strategic insights
The Browser is Slow

Written by Thomas Baekdal on July 12, 2005

Update: Now includes Internet Explorer 7 (beta 1) performance test. Overall it does not change much. It does load pages faster, but varies greatly in how it handles changes to the DOM. This is good for normal websites, but worse for web applications.

If we compare web applications to other web-based activities, there is one thing that separates them - client-side workload. A web application requires the browser to handle more data, but also to process it directly on the client - where other web-based activities put the stress on the server.

The browser was never built for this activity, it was built to display information and the major activities include clicking on links, or submitting forms. It is slow and uneven when it is tasked with manipulating large amount of data.

What is slow?

Slow as in the performance of web vs. desktop applications. If you take a desktop application like Outlook, and look at how it handles to-dos. It is more than capable of handling 500, 10,000, 50,000 even 100,000 to-dos without experiencing performance problems.

If we take a web application like, say, Backpack, which also handles to-dos - it quickly becomes clear that the browser is totally incapable of handling large amount of data. Even with as few as 20 to-dos Backpack starts to have performance issues. At 500 to-dos (see this backpack test) the browser gets into serious trouble. It is almost not capable of handling them.

Disclaimer: The reason Backpack is used in this example, is not because there is anything wrong with it. It is actually in the upper end in terms of quality and speed compared to other web applications on the market.

Backpack is used because it is easy to use, and allows anyone to create a free account, so you can experience this on your own.

This test's primary concern is the sluggishness of the browser when used to create web applications in general.

Test case: performance in web applications

To see how serious this performance problem really is, I made a test. I created a 500 item to-do list in Backpack and timed how long it took for each step.

The following test results are in seconds - A long bar means slow performance. Keep in mind that desktop applications can perform any of these tasks instantly

Test page: Backpack 500 item to-do list

Loading the page

Loaded locally to ensure consistent test results and better a comparison with desktop applications

Preparing to re-order the list

Re-ordering the list

Visual feedback when re-ordering

Conclusion

I admit this is not a very scientific test, but it does illustrate a pattern that I have experienced in all the years I have been making web applications. The browser is very slow. As soon as the amount of data increases, you web applications turns from being quick and easy to use (like regular users of Backpack experiences), to a slow and frustrating affair.

There is one thing in particular that causes it to be slow. That is when you loop trough the DOM (Document Object Model). This takes ages in a browser, compared to desktop applications and regular programming languages. It will actually be many times faster to add massive amount of code to the initial page - than to loop trough it and add specific behaviors to it afterwards.

In this case it took 3 minutes and 26 seconds for Firefox (Mac) to process and re-render the list before I could re-order each individual item. Over 3 minutes... disastrous!

It is also very slow when you move around in the DOM, to the parent or child elements. So keep this to a minimum too.

What surprises me the most is that it will often be many times faster to simply reload the entire page, than to manipulated it on the client-side. In the above test, it took Internet Explorer 99 seconds to process and re-renders the list. But it only took 1.9 seconds the load it. This means you can have the server process the list and returning it to the browser 52 times faster than simply doing it client-side.

There is, of course, balance to this. When the amount data is kept to a minimum, the browser will be faster. But even with 20 to-dos or similar amounts the browser is no longer capable of handling the data efficiently.

Is there a fix?

No, not really. The browser is more than 100,000 times slower than any desktop application. This gab is too big to be fixed with simple code optimization.

However, there are a number of things you could do to improve performance drastically.

Put the stress on the server. This is where XMLHttpRequest comes in. Instead of using DOM, you can use XMLHttpRequest to make the server do the job, and simply outputting the final result to the browser.
Do not output XML, output the final formatted code. The server can format you XHTML much faster than any client-side XML/XSLT
Do not manipulate the entire list, but try to only manipulate individual elements - and reference them directly.
Read: Wanted, Faster Web Applications
Use Safari, if you are lucky enough to be able to base your web application on Mac OS X Tiger. Safari is consistently much faster than other browser. It is still not fast compared normal desktop performance, but it is certainly better than Internet Explorer and Firefox.