Java Developer Magazine on Ulitzer

Last week I analyzed a web page that spent 4.8 seconds in the onLoad event handler of a custom script file. It turned out that 2.8 seconds were consumed by applying a dynamic menu library (will blog about this one separately). The remaining 2 seconds were spent in jQuery selectors. The analysis showed that most of the selectors didn’t return any object and those that returned objects can be improved by using different selectors.

About jQuery Selectors
There are some great blog articles about jQuery Selectors and their Performance Impact. As you can see you can select elements by ID, TagName or ClassName. Depending on the select jQuery can use the native browser methods to query elements by id or tag or needs to manually iterate through the DOM in case of class names (as there is not getElementsByClassName in IE).

Analyzing the 2 seconds in my page time
The onLoad handler uses jQuery to set hide, show, change style sheets, … for certain elements on the page. Here is a code snippet:

Sample jQuery Script exected in onLoad
The onLoad event handler was full of these calls. Using the free dynaTrace AJAX Edition you can see the individual $ calls that resolves the selector and the following method call in case the selector resolved at least one object. The following PurePath of the onLoad event handler not only shows me how much time was spent in those selector calls – but also how many of these actually didn’t find a single object (the lack of the following method call indicates that no object was found):

Unnecessary jQuery Selector Calls causing massive overhead

All calls marked in red are calls that didn’t return an element because there was no DOM element based on the selection criteria. The JS column shows the execution time of each individual method call – ranging from 1ms to > 100ms per call. The size column tells us how many JavaScript/DOM calls were made by an individual call. Here we can also see why certain $ calls took so much longer as they made many calls to fulfil the request. The Invocation column tells me how often a method was invoked by its parent. We can see here that some objects were actually resolved multiple times, e.g.: “.pop-cart”. It would have been better to only resolve it once and cache the object.

The first lesson learned from this is that most of these calls were not necessary and just caused massive overhead. If you happen to know which elements are on a page you should only resolve those objects and don’t try to resolve others. I know – having global java script files that handle different pages with different content cause a situation like this – but – do you really want to live with this overhead?

Analyzing difference in jQuery Selectors
The first problem on the analyzed page was that too many unnecessary $ calls were made. The other question that came up was why certain $ methods respond very fast (some milliseconds) where others take rather long (up to 100ms). The theoretical answer can be found in the jQuery Best Practice Blog. Coming back to my page shows me the following:

Selector by ID is the fastest using getElementById

Following image shows a selector using an ID. It uses getElementById and therefore returns very fast.

jQuery Selector by ID

Selector by TagName using getElementsByTag
The following example selects elements by TagName and ClassName. jQuery first uses the getElementsByTagName which is a native implementation to retrieve all elements for the specified tag. jQuery then iterates through these items to filter for the ClassName.

jQuery Selector by Tag and ClassName

Selector by ClassName needs to iterate through ALL DOM elements
If you use a selector by ClassName only – jQuery needs to iterate through EVERY element in the DOM as there is no native implementation for getElementsByClassName in Internet Explorer (its a different story for FireFox). Following image shows the overhead of a selector on a page with 3460 DOM Elements:

jQuery Selector by Class Name

Conclusion
Depending on the size of your web site (number of DOM elements) you should consider the overhead of individual selector methods. Instead of selecting by classname you may want to think about using TagName and ClassName or by using unique IDs in case you only have a handful of objects on your page. Also – make sure you cache already resolved objects to avoid the overhead for subsequent resolving calls. And – last but not least – avoid calls that are not necessary. As seen in the page that I analyzed – more than 1.5 seconds of the 2 seconds can be saved by not making those calls.

Related reading:

1. 101 on Prototype CSS Selectors Performance implications of certain CSS Selectors are not specific to...
2. Performance Analysis of dynamic JavaScript Menus In my previous post I talked about the impact of...
3. How to Speed Up sites like vancouver2010.com by more than 50% in 5 minutes Many Web Sites that use JavaScript frameworks to make the...
4. How to test jQuery enabled Apps using JSON with Visual Studio Visual Studio Team System offers a nice Web- and Load-Testing...
5. Ensuring Web Site Performance – Why, What and How to Measure Automated and Accurately It is a fact that end user response time is...