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
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
In this example the CSS Expression caused 191454 interactions with the DOM.
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.
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?