Java Developer Magazine on Ulitzer

Performance implications of certain CSS Selectors are not specific to a certain JavaScript Library like Prototype. I recently blogged about the internals of CSS Selectors in jQuery. The same holds true for every JavaScript library that offers CSS Selectors. Certain lookups can be done by using the native browser functions like getElementById or getElementsByTagName. Lookups by class name are not natively supported in IE and are therefore implemented in JavaScript by iterating through all elements in the DOM - which is obviously much slower than a native implementation.

Expensive Prototype CSS Selector
I recently analyzed some pages of an online retail store that uses Prototype. I used the dynaTrace AJAX Edition to identify the root cause of several slow pages on that web site. I identified two specific examples of CSS Selectors that caused massive overhead on that particular page:

$$("[id^=contentElement]") -> up to 6 seconds on a single page to find all elements that have an id starting with contentElement

$$("div[class=contentDiv]") -> up to 2.3 seconds on a single page to find all div tags with the class contentDiv

Selector Expressions
The flexibility that you get with CSS selectors is great. As you can see from the examples above you can use certain operators to do not only lookup elements by their full id, tag or class name. The following operators are supported (taken from prototype 1.6.1)

• [id=contentElement] -> finds the element with the id that matches contentElement
• [id!=contentElement] -> finds all elements that do not match contentElement
• [id^=contentElement] -> finds all id's that start with contentElement
• [id$=contentElement] -> finds all id's that end with contentElement
• [id*=contentElement] -> finds all id's that include contentElement

Additionally to these we have two selectors that allow you to query for elements with attribute values containing hyphen or space separated list values.

• [sample~=value] -> finds all elements whose sample attribute is a list of space-separate values and one of them has the value "value"
• [sample|=value]-> finds all elements whose sample attribute is a list of hyphen-separate values and one of them has the value "value"

When using expressions like the ones above (except id=contentElement) Prototype needs to iterate through all DOM elements and manually match the DOM's attribute value with the expected value as there is no native implementation available for this feature by the browser. Depending on the size of your DOM this can cause a huge performance impact.

Sample 1 - Find elements which attributes that start with a certain text
The following screenshot shows the custom JavaScript method that uses the [id=^contentItemContainer] expression to get all elements that have an id attribute starting with contentItemContainer. The page had a total of 3184 DOM elements. The used expression causes Prototype to use getElementsByTagName("*") which returns ALL 3184 elements. Prototype then iterates through all elements. It reads the attribute in question (id) and verifies if it starts with the passed value (contentItemContainer). Additionally to that it reads all sort of other DOM attributes depending on the DOM Element Type (a, td, p, h1, h2, ...) and registers the prototype extension methods (more on this in Sample 2 of this post).

In this example the CSS Expression caused 191454 interactions with the DOM.

Expensive CSS Selector causing 190k DOM Calls

There are multiple solutions to this problem. One is to find a better way to identify these elements. Looking at the HTML document showed me that all these contentItemContainer elements were in fact DIV tags. Changing the query to $$("div[id=^contentItemContainer]") would have caused Prototype to use getElementsByTagName("div") which would have only returned 178 elements instead of 3184.

In case these elements have different tags this first approach wouldn't work. Limiting the number of DOM elements on the page would be another option to speed up iterating through all elements.

Sample 2 - Find elements by class name
This is the classic example which only holds true for Internet Explorer. As discussed in my previous post about jQuery Selectors - IE does not support a native method to get elements by class name. Using a query like "[className=contentDiv]" would therefore be handled in the same way described in Sample 1 - all DOM elements are iterated to find those elements that match the class name.

What was surprising to me was that the query $$("div[className=contentDiv]") still triggered many more DOM interactions than I expect. Using the "div" tag in the expression solves the problem that not all DOM elements are iterated but just the DIV tags using the native getElementsByTagName to get these elements. On those returned DIV elements Prototype defines it's extension methods like previousSiblings, nextSiblings, match, up, down, ... In my case I had 618 DIV tags. On each of these objects Prototype registered 57 extension methods. This "registration" in the end took most of the time of the item lookup.

Selector registering extension methods

The query div[className=contentDiv] caused a total of 42415 DOM interactions even though I only had 618 DIV tags on the page where about 200 matched the passed className. I am wondering if there is a way to configure Prototype to not register the additional extension methods in case they are not needed on a particular web page. Any thoughts on this?

Conclusion
As with any JavaScript framework that offers a variety of CSS Selectors you need to know what is actually going on when using them. They are flexible and easy to use. But keep in mind that certain browsers (especially IE) have limitations when it comes to selections by Class Name. Also - the larger the DOM Tree becomes the more overhead you have when using any other lookup method than by id or tagname - in all these cases the JavaScript framework needs to iterate the complete DOM. As always - I am happy for feedback.

Related reading:

1. Performance Analysis of dynamic JavaScript Menus In my previous post I talked about the impact of...
2. 101 on jQuery Selector Performance Last week I got to analyze a web page that...
3. Your Top Links about Web Site/AJAX Performance With the recent work we did for the dynaTrace AJAX...