This post is number one in a three part series about memory consumption for web applications in general.

Since the Web 2.0 era, Web Applications have changed for the better. They provide more functionality, better usability and improved performance. However this tendency led to increased complexity. It is not unusual for a user to stay on a single page for hours without leaving. The browser would just poll data from the server through Ajax requests and display it in even more interesting manners. Therefore it is no wonder that web applications have become hungrier for resources and the browsers couldn’t keep up with it. The heavy utilization of JavaScript and DOM revealed the poor memory management of most of the major browsers at the time. These issues still persist nowadays and it is our duty as developers to be aware of them.

There seems to be a slight confusion among Web developers, when it comes to separating Memory Leaks issues from Memory Consumption. In order to get things clear, let’s investigate the definitions of both.

Definition of Memory Consumption

Memory consumption stands for the amount of memory a particular program utilizes throughout its execution. This term is self-explanatory as every application relies on the underlying memory to store instances of variables. The more the variables, the larger the memory consumption will be. Therefore it is a common assumption that more complicated applications require more memory.

Definition of Memory Leak

Memory leaks are a specific case of using the memory, or more precisely misusing it. Memory leaks are bugs in the memory management of either the platform (browser) or the application itself. When a program occupies a piece of memory and later does not release it, this memory becomes useless and inaccessible. Reproducing this process for a long time may lead to memory starvation – a special case, in which the application is unable to continue the execution due to insufficient memory resources. The application becomes slower, less responsive and eventually crashes.

It is a well-known fact that the memory management of older versions of the Internet Explorer browser has been poor, with Internet Explorer 6 being the most notorious of them. Here is one very famous article on the topic by Justin Rogers - However memory leaks are not limited to IE, almost any browser will leak memory under the right circumstances. A simple search through the bug list should be just enough to understand it. Still, in my opinion, Internet Explorer has proven itself as one with the most issues, when memory leaks are concerned.

Memory leak patterns

Memory leaks are caused by specific programming patterns, whose understanding is quite valuable. Very often they are divided in the following categories:

  1. Circular References - when mutual references are counted between Internet Explorer's COM infrastructure and any scripting engine, objects can leak memory. This is the broadest pattern.
  2. Closures - Closures are a specific form of circular reference that poses the largest pattern to existing Web application architectures. Closures are easy to spot because they rely on a specific language keyword and can be searched for generically.
  3. Cross-Page Leaks - Cross-page leaks are often very small leaks of internal book-keeping objects as you move from site to site. We'll examine the DOM Insertion Order issue, along with a workaround that shows how small changes to your code can prevent the creation of these book-keeping objects.
  4. Pseudo-Leaks ­- these aren't really leaks, but can be extremely annoying if you don't understand where your memory is going. We'll examine the script element rewriting and how it appears to leak quite a bit of memory, when it is really performing as required.

This classification has been taken from the previously mentioned article - In order to stay true to the DRY principle, I will skip the extensive explanation and code samples for each category, as they are already explained there.


Still we cannot miss the fun part of writing and changing some example code. Before that, one should have the necessary tools at hand. In order to observe the “diminishing” memory, the easiest way is to open the Task Manager/Process Explorer/Activity Manager and observe the consumed memory there. A better option is to use sIEve - – a tool specially designed to track memory usage and detect memory leaks under IE. The page is loaded in the sIEve environment and two scenarios could follow:

  1. Auto Refresh: The current URL will be automatically refreshed. In the memory samples list and graph you can observe if there are still leaks in your application. The ‘Auto Refresh’ button will change into ‘Stop’ to cancel the auto refresh mode.
  2. about:blank: unloads the current page, giving a blank screen. This is extremely useful to find leaks after page is unloaded. If you press the Show in Use button after pressing the about:blank button, then you see all the real leaks (DOM elements which are not freed or garbage collected by IE.


An interesting effect can be observed, when upgrading the installed Internet Explorer to the latest version - 9, i.e. many examples that produce leaked memory in the latter case will not leak. This should lead to the conclusion that Microsoft has improved the memory management in Internet Explorer 9 compared to the previous versions.

 The next post in this series will show particular examples of memory leaks with code samples of the different types of leaks.

About the Author

Nikodim Lazarov

is a Senior Software Developer in the Telerik's ASP.NET AJAX devision. He has years of experience building web applications of various scales. Niko is a strong advocate of Web standards, TDD, Agile and basically anything that makes every developer a true craftsman. Outside of office he usually rides his bike, goes kayaking or is simply out with friends.

Related Posts