CSS Selectors - Speed Myths
July 10, 2007 by Jack Slocum
On of the things updated in Ext 1.1 RC1 was DomQuery, the CSS selector implementation in Ext. There seems to be a trend sweeping through all of the popular JavaScript libraries of implementing or improving existing DOM querying using CSS selectors. In fact, since my original post with querying benchmarks for the various selector implementations, overall selector processing power has gone from Pinto power to a Mustang GT 500.
Has it really?
While there is no doubt that there have been improvements in every library, the manner in which each has gotten there is different. Some use XPath support in FireFox to gain a slight edge in that browser, but lag way behind in other browsers. I have tried to remain as impartial as possible in my evaluations of each library’s implementation.
Mootools
The latest on the scene with their slickspeed post, has implemented a nice test suite. In fact, it was so easy to set up I decided to use it for the tests included in this post below.
For some reason, although their test suite is titled “speed/validity selectors test for frameworks”, it leaves out many useful selectors such as div.dialog.emphatic (multiple classes) and div:not(.dialog) but includes completely useless selectors such as div div div. I have added those two selectors in my tests below.
The Mootools selector implementation relies heavily on XPath in FireFox. Performance in other browsers drops significantly.
Prototype
Prototype’s selector implementation is based on the initial Ext DomQuery code mixed with XPath support in FireFox. I had high hopes when seeing the first benchmarks for their implementation, but somewhere something must have gone wrong. The XPath picks up a lot of slack in FireFox but similar to Mootools, performance in other browsers drops significantly.
Dojo
Dojo’s selector implementation borrows ideas from various sources. It also uses XPath in FireFox but it’s more selective in the selectors it converts to XPath. Its cross-browser performance is also pretty consistent.
jQuery
jQuery’s recent 1.1.3 release gave it quite a big boost in performance. jQuery, like Ext, does not use XPath in FireFox. Credit goes to John Resig for the most efficient nth-child implementation I have seen to date. In fact, Ext 1.1’s new nth-child implementation is modeled very closely after it.
jQuery was the only library other than Ext that passed all the tests.
Ext
DomQuery’s performance is based on highly optimized code. In FireFox, even without XPath Ext is right there in the mix - I think that says a lot about the efficiency of the code. DomQuery by far has the most consistent performance cross browser. Like jQuery, Ext supports unlimited chaining of filters and selectors and querying XML Documents.
Results
Here are my results. Bold indicates the fastest time.
| Library | IE 7 | FireFox 2 | Safari 2.0.4 | Opera 9.2 | IE 6 | Errors |
|---|---|---|---|---|---|---|
| Ext | 202 ms | 239 ms | 330 ms | 96 ms | 902 ms | 0 errors |
| jQuery | 334 ms | 392 ms | 843 ms | 176 ms | 1948 ms | 0 errors |
| Dojo | 415 ms | 315 ms | 917 ms | 110 ms | 1775 ms | 4 errors |
| Mootools | 684 ms | 136 ms | 1446 ms | 129 ms | 2655 ms | 4 errors |
| Prototype | 868 ms | 172 ms | 2031 ms | 119 ms | 3743 ms | 2 errors (IE only) |
IE7, FF2 and Opera 9 tested on Vista, Core 2 Duo 6600, 4GB RAM
Safari 2 tested on Mac OS X 10.4.9, Core 2 Duo T5600, 2GB RAM
IE6 tested on XP, Athlon x64 3200+, 1.5GB RAM
Run them yourself
http://extjs.com/playpen/slickspeed
Why another test?
These tests were conducted to test the 1.1 RC1 release, and to dispel some myths about the selector speed of each library.
Posted on July 10th, 2007 at 1:00 pm
I would prefer it if these tests were restricted to valid CSS selectors too.
Posted on July 10th, 2007 at 2:37 pm
Great work again Jack…you never cease to amaze me.
Posted on July 10th, 2007 at 3:02 pm
CSS Selector Speed tests using SlickSpeed…
Jack Slocum - creator of my favorite JavaScript library1 Ext JS - ran some tests using SlickSpeed from the MooTools developers with the latest development release of Ext JS, 1.1 RC1.
I ran a few additional tests with the following configurations:
Fire…
Posted on July 10th, 2007 at 5:15 pm
Great post, Jack! I always appreciate reading your take on these issues.
Unfortunately, I think the slickspeed test has a few other problems worth mentioning:
The HTML that the test uses was taken from a slapdash speed test I put together back in 12/2006 to determine the relative speeds of selectors within jQuery. I had no idea it would be used in the battle for selector speed dominance, and I’m a little embarrassed that it’s still out there. Surely someone can come up with something better than Act 1, Scene 3 of Shakespeare’s As You Like It. It’s hardly representative of what the DOM tree will look like on corporate sites or blogs.
Also, the slickspeed test reports the total time it takes to run through all of the queries, but the results are misleading when, for example, one library (incorrectly) finds 0 elements but records 1ms while the libraries that get it right record 5-15ms.
It might be more appropriate to have two rows at the bottom of the slickspeed table. One would report the average time for all of the library’s successful queries, and the other would report the total number of failed queries.
By the way, I realize that you aren’t the one who put the slickspeed test together, and I’m not suggesting that you ought to do anything about it. Just thought I’d add my 2 cents and offer a couple more reasons that we should probably take the results with a grain of salt.
Posted on July 10th, 2007 at 7:50 pm
Karl,
I agree 100% that the test DOM is not very realistic. In my personal selector usage and Ext’s internal selector usage, selectors are always scoped to a specific element/container. This makes the number of nodes it is working with much smaller and makes the use of XPath a slow down instead of a speed boost. For the sake of not wanting to spur a new debate in that department, I specifically left it out of my post.
> offer a couple more reasons that we should probably take the results with a grain of salt.
I think it’s worth noting that Ext and jQuery had no errors, so their times are in fact the correct times. I agree there are spots where Mootools picks up time because when it fails, it fails fast.
Posted on July 11th, 2007 at 2:01 am
[...] более быстрая версия DomQuery. Подробнее о ней в Джек написал в статье “Мифы о скорости CSS-селекторов” (перевод будет завтра). Всем кто использует ветку 1.1 [...]
Posted on July 11th, 2007 at 7:25 am
Some suggestions to dispel more myth. You count the thrown errors but not the results with wrong count (like div[class!=madeup] and div[class|=dialog]) . Imo that should also count as error, since the results are wrong. Ignoring not supported selectors or throwing an error is simply a design decision during framework design.
I agree also that a more realistic HTML (jQuery used a snap from the digg site for an realistic test dom once: http://www.kenzomedia.com/speedtest/template.html, http://www.kenzomedia.com/speedtest/) would bring better real-life results.
Furthermore Safari3 should be also in your overview, since it should have totally different results because of his XPath support.
Posted on July 11th, 2007 at 8:21 am
Karl, exactly what I noticed upon jQuery’s 1.1.3 release -> http://jquery.com/blog/2007/07/01/jquery-113-800-faster-still-20kb/#comment-34150
Posted on July 11th, 2007 at 8:43 am
[...] Jack Slocum has continued the CSS Selector trend by taking another look at the various frameworks and dispelling some CSS Selectors Speed Myths. [...]
Posted on July 11th, 2007 at 9:13 am
What is the version of Prototype used ? Isaw the last relased fix lots of performance issue on DOM Query ?
I’m using prototype, is there a solutions to bind Prototype DOM Queries functions (.up(), .down(), …) with other DOM Query libs to test in a real application if there is visible changes ?
Regards
Posted on July 11th, 2007 at 9:27 am
Andrie, ha! That’s great! You know, I just might have read the comment on the jQuery blog and internalized your idea so much that I thought it was my own. Sorry if that was the case. In any case, I hope I added a little more to the discussion in my comment above. Cheers!
Posted on July 11th, 2007 at 10:11 am
[...] CSS Selectors - Speed Myths Jack Slocum has continued the CSS Selector trend by taking another look at the various frameworks and dispelling some CSS Selectors Speed Myths. [...]
Posted on July 11th, 2007 at 12:16 pm
Safari 3 beta (Windows) is the fastest on my system and this in every library! Opera and Firefox clearly have some strengths and issues with some libraries. Safari 3 does an overall good and a very performant job in javascript.
Has anyone encountered similar results?
Posted on July 11th, 2007 at 12:49 pm
Jack -
I posted about this on my blog a couple of days ago, and I also introduce two variations on the selector test suite - both using a copy of a complex, realistic page from my company’s website, Zillow.com. One suite simply does analogous queries to the original, modified for the new document; the other will scan the document and create 25 arbitrary queries based on actual elements in the DOM.
I came to much the same conclusions you did, and congratulations - DomQuery looks to the the best-of-breed for CSS selector engines.
Posted on July 11th, 2007 at 12:55 pm
Jack,
I’ve used a variation on this test for testing a toy selector implementation I’ve been playing with (I’ve got to post it one day) that uses what I think is a very different approach to things (unfortunately its not as speedy as I thought it should be). I’ve noticed something about most selector implementations, one that is hidden by the test scenarios give. Failed selectors (that is those that do not return any nodes) take almost as long as successful selectors of similar length, depending on where the failed node is within the selector. This is actually one of the situations that I’ve optimized for in my toy; I find the speed of failed selectors more useful than successful ones.
Why would that be? I don’t write hand crafted web applications or sites. I belong to a company that builds online banking systems for a large percentage of credit unions in Canada. I have to support a large team of very smart Java Developers, who (generally) don’t know a thing about HTML, JavaScript or CSS. In my world, the ideal solution is to have well thought out mark-up and a single JavaScript Library that attaches all the necessary behaviour to the mark-up it finds. That means that I may have a lot of selectors running that don’t return anything on any given page.
And that means that I want selectors that won’t return any results to run FAST! Ideally, selector speed should be proportional to the number of results it retrieves, not the complexity of its query. Or to be more precise, the more complex (that is the more specific the query) the faster it ought to be. Which suggests that tree traversing methods should be abandoned, eventually.
Perhaps you could add some selectors to your test that are guaranteed to return 0 results?
Posted on July 11th, 2007 at 2:05 pm
Just wondering. How come some are packed and some aren’t?
Does that change the results?
It might be neat to have a way to point the speed test at a URL and test. That way each person could see how their site would measure up. I suppose many of the test results would have zero found, but that’s probably even better. That way they only see the speed results from the selectors they would possibly use.
Hope all is well,
Glen Lipka
Posted on July 11th, 2007 at 3:10 pm
@Glen
Packing shouldn’t affect results. I do agree that a better markup source and more direct queries should be incorporated into the test. I personally *never* use global queries like the one found in this test as I believe they are a bad idea for performance. Selectors should be scoped so they work with only the nodes they need.
@Adam
It’s difficult to determine that there are 0 results without running the query. A zero result would return a little faster though as it would do significantly less node processing.
@mg
Safari 3 is blazing!
Posted on July 11th, 2007 at 4:43 pm
Quick question: What version of Dojo was this?
Posted on July 11th, 2007 at 5:14 pm
Thanks for finally touching on the “fad” status of CSS selector speeds these days. I hate that.
Posted on July 11th, 2007 at 6:21 pm
@Karl - not at all a problem! It’s good to see that the logics behind my proposal are spread individually! Common sense and good logic don’t have copyright.
@mg - indeed, Safari 3 shows us a new Formula 1!
@Alec - I would assume it’s the latest (Dojo 0.4.3)
Posted on July 12th, 2007 at 2:49 am
I did some test, especially with jQuery on Windows XP & Vista, Mac OS X, Linux etc. The results confirm your testresults: The fastest browser is OPERA!
Posted on July 12th, 2007 at 4:15 am
Congratulations Jack. These are great numbers. I am not even sure if it is possible to query any faster the DOM.
Anyway, speaking of widest browser support (a must IMHO for a library), you may be interested in ext behavior on various linux browsers. Apropo linux - ext, jQuery and dojo are the only libraries that run on Konquerer. You can find these test results along with screenshot over at my site.
Posted on July 12th, 2007 at 7:04 am
[...]
Posted on July 12th, 2007 at 7:04 am
[...] CSS Selectors - Speed Myths WOW, look at those time differences between IE6 and IE7! Opera takes the cake across the board though along with Ext. (tags: CSS Browsers Toolkits Ext) [...]
Posted on July 12th, 2007 at 12:38 pm
[...] have been addressed and additional documentation updates have been made. One notable change is the upgrade of DomQuery in 1.1 as well. It’s now even faster than before and handles more selectors. 1.1 is getting [...]
Posted on July 12th, 2007 at 6:21 pm
Nice listing, thanx for your work.
Posted on July 12th, 2007 at 9:50 pm
[...] to express my disappointment that Jack didn’t include Dean’s excellent Base2 in his latest round of benchmarks. It’s doing us all a disservice that he’s not including the fastest engine around in [...]
Posted on July 13th, 2007 at 3:54 am
[...] Оригинал статьи на блоге Ext. [...]
Posted on July 13th, 2007 at 8:07 am
So, Opera is the fastest and by a decent margin.
Posted on July 13th, 2007 at 3:26 pm
Yay for opera \o/
Posted on July 13th, 2007 at 4:28 pm
I have to agree with Dean, only use valid selectors in the tests, otherwise the test isn’t a fair one.
Also I ran the tests on all browsers for the Mac and Prototype came out on top every time and found more and only threw exceptions(2) in safari2. How accurate is this test?
Thanks for the effort and time,
Kevin
Posted on July 14th, 2007 at 7:22 pm
Nice article/blog Jack
Good read
Posted on July 16th, 2007 at 11:29 am
[...] guys over at ExtJS ran a speed test for CSS Selectors, and among IE6, IE7, Firefox 2, and Safari, Opera has been shown to be the fastest. They tested the speed of 5 JavaScript libraries (Ext, jQuery, Dojo, Mootools, and Prototype), and [...]
Posted on July 16th, 2007 at 11:32 am
[...] 1. Zawiera poprawki zgłoszone oraz zaktualizowaną dokumentację. Z ważniejszych zmian: nowy DomQuery - teraz działa szybciej i obsługuje więcej [...]
Posted on July 16th, 2007 at 2:35 pm
I got pretty different results with Safari on Win XP and Opera on same machine.
And Safari was not so bad at all as your Mac Safari seems to be.
Posted on July 16th, 2007 at 5:33 pm
Safari 3 is NOT that much faster. In fact: safari cheats the speedtests. Read this: http://www.howtocreate.co.uk/safaribenchmarks.html
Posted on July 16th, 2007 at 8:43 pm
[...] CSS Selectors—Speed Myths Jack Slocum tackles a few of the myths surrounding the impressive performance gains made recently by the popular JavaScript libraries in their support for CSS-style node selection. (tags: javascript ) [...]
Posted on July 17th, 2007 at 7:42 am
I’ve got quite different results on 4-core Mac Pro:
Safari: 115 161 118 87 171
Firefox: 146 355 152 256 306
Opera: 137 215 138 138 146
Posted on July 20th, 2007 at 11:28 am
The opera is the fastest and the best
Posted on July 23rd, 2007 at 8:01 am
[...] You can view the post here. [...]
Posted on July 27th, 2007 at 3:59 am
[...] Slocum von der ext JavaScript Library hat sich auch diese Frage gestellt und die CSS Selectoren von fünf (Mootools, Prototype, Dojo, jQuery und Ext) JavaScript [...]
Posted on July 29th, 2007 at 2:10 pm
The test seems to be flawed, vastly different results in spite of getting the same result: error.
Also, testing normal pageloading are both Safari 2 and WebKit much faster so there are likely a few bugs in the script.
Mac mini 1.42 GHz G4, 1 GB RAM.
WebKit (Safari 3): 228 435 258 232 445
Safari 2.0.4: 2898 798 1465 389 817
Firefox 2.0.0.5: 458 1023 407 836 771
Opera 9.22: 384 588 358 370 344
Posted on August 2nd, 2007 at 11:19 pm
@David
Sorry your post got caught by WordPress and I just found it. I agree the markup used in the test is pretty bad and your test looks much more realistic. Thanks for sharing your results!
Posted on August 13th, 2007 at 2:40 pm
[...] y lo puedes hacer aquí . En la imagen a continuación se ven los resultados. Enlace directo: extjs.com/blog/2007/07/10/css-selectors-speed-myths/ Relacionada: meneame.net/story/cual-es-el-navegador-mas-rapidoetiquetas: opera, velocidad, [...]
Posted on August 18th, 2007 at 5:16 pm
Cool to see Opera is actually as fast as they claims, alghough milliseconds isn’t a trouble for me during daily browsing
@mg @jack @andrie Safari for windows may not be comparable when doing javascript-based speed-tests: http://www.howtocreate.co.uk/safaribenchmarks.html
Posted on August 24th, 2007 at 1:03 pm
Would it be possible that you update your slickspeed to the recently released jQuery 1.1.4, and maybe to Prototype 1.6.0 RC if there aren’t too many bugs/regressions in it?
Posted on September 8th, 2007 at 11:19 pm
it is very good,
Posted on September 17th, 2007 at 8:47 am
teraz…
Good to know ……
Posted on September 22nd, 2007 at 3:50 pm
[...] 我用的是firefox2.x，CPU 赛扬1.7G, 256M+512M RAM。 从测试结果看，明显是两个梯级，时间相差3倍。官方做的测试结果差不多也是这样，不过没相差那么多倍而已，时间上比我的短多了，毕竟人家用来做测试的机器条件要好得多。 [...]
Posted on September 30th, 2007 at 10:20 pm
Web Site Design…
I couldn’t understand some parts of this article, but it sounds interesting…
Posted on October 7th, 2007 at 6:21 pm
[...] статья о сравнении css-селекторов в разных js-библиотеках (ExtJs [...]
Posted on October 30th, 2007 at 11:11 am
The opera is the fastest and the best…
Posted on November 8th, 2007 at 10:56 am
Very useful, thanks.
Posted on November 16th, 2007 at 8:09 am
Please, do so clean up to your (trash)blog
Posted on November 18th, 2007 at 4:05 pm
Selectors are one of the most important aspects of CSS as they are used to “select” elements on an HTML page so that they can be styled
Posted on January 9th, 2008 at 11:59 pm
thanks very much
Posted on January 11th, 2008 at 4:06 am
Interesting - I never thought that there such differences in CSS Speed
Posted on January 11th, 2008 at 10:26 am
What about Ext 2.0?
Posted on January 12th, 2008 at 6:05 pm
Hopefully no effect on existing code already in place.
Posted on January 14th, 2008 at 10:02 am
[...] Paul Irish put together a bit of history in the form of the Javascript CSS selector engine timeline which shows us that “selector processing power has gone from Pinto power to a Mustang GT 500.” [...]
Posted on January 14th, 2008 at 1:33 pm
[...] Paul Irish put together a bit of history in the form of the Javascript CSS selector engine timeline which shows us that “selector processing power has gone from Pinto power to a Mustang GT 500.” [...]
Posted on January 14th, 2008 at 2:08 pm
[...] Paul Irish put together a bit of history in the form of the Javascript CSS selector engine timeline which shows us that “selector processing power has gone from Pinto power to a Mustang GT 500.” [...]
Posted on January 14th, 2008 at 9:27 pm
[...] Ext JS Blog - » CSS Selectors - Speed Myths 315 ms (tags: javascript css performance selectors speed library) [...]
Posted on January 15th, 2008 at 2:16 am
[...] Paul Irish put together a bit of history in the form of the Javascript CSS selector engine timeline which shows us that “selector processing power has gone from Pinto power to a Mustang GT 500.”. [...]
Posted on January 15th, 2008 at 3:04 am
[...] Paul Irish put together a bit of history in the form of the Javascript CSS selector engine timeline which shows us that “selector processing power has gone from Pinto power to a Mustang GT 500.”. [...]
Posted on January 15th, 2008 at 5:32 am
[...] Paul Irish put together a bit of history in the form of the Javascript CSS selector engine timeline which shows us that “selector processing power has gone from Pinto power to a Mustang GT 500.”. [...]
Posted on January 15th, 2008 at 9:57 am
[...] Ext 1.1 RC1 [...]
Posted on January 18th, 2008 at 12:32 am
[...] Paul Irish put together a bit of history in the form of the Javascript CSS selector engine timeline which shows us that “selector processing power has gone from Pinto power to a Mustang GT 500.”. [...]
Posted on January 24th, 2008 at 4:00 pm
Payday Loans No Fax…
Worthy provider which provides quick payday advance loan programs for finance applicants craving online pay day loan options….
Posted on January 25th, 2008 at 11:13 pm
hello…
nice…
Posted on January 28th, 2008 at 5:49 am
Jack…
Thanks for the info. By the way, I am a big fan of your site. Keep up the great work….
Posted on January 28th, 2008 at 1:39 pm
Eric…
I don’t mean to be too in your face, but I’m not sure I agree with this. Anyhow, thanks for sharing and I think I’ll write a post on this on my blog soon….
Posted on June 21st, 2008 at 8:44 pm
[...] CSS Selectors - Speed Myths Jack Slocum tackles a few of the myths surrounding the impressive performance gains made recently by the popular JavaScript libraries in their support for CSS-style node selection. (tags: javascript) [...]
Posted on July 30th, 2008 at 6:02 am
Jack
Nice work..