A jQuery UI Dialog “open” performance issue and how to fix it 12

jQuery UI is a great way to get good looking, feature packed sites up and running ASAP.  It doesn’t come without it’s costs sometimes though, especially if you use it right out of the box. I recently discovered and interesting issue in jQuery UI surrounding the performance of creating a dialog with a large amount of <table> data in it. Now don’t get me wrong, popping up a dialog with a 1700 row table in it isn’t the panacea of UX design but its definitely not unheard of. In fact I’ve seen this sort of design quite often for mass data display or selection.

So what’s the problem?

Head on over to the demo and click the “Trigger dialog slow” button. Yikes! On my < 2 year old 2.6GHz i5 running the latest version of FireFox it takes about 3.5 seconds to open the dialog containing a modestly widthed table containing 1700 rows. Trying the same in IETester @ IE8 causes the program to crash (real IE8 would probably get it done within 10 – 15 seconds I’m guessing on my box). Meanwhile the user has no idea what is going on and might be wondering with their CPU fan just kicked it up a notch.

Stepping into the jQuery UI source code after using the Firebug JavaScript Profiler it appears that two parts of the jQuery UI Code are causing most of the slow-down:

• Resizing the dialog box to fit the dimensions specified (~1.5 sec)
• Finding the first tabbable element and setting focus to it (~1.0 sec)

Well there isn’t much we can do about the first bullet unless we are okay with the dialog not being sized appropriately, but 1 second just to find the first tabbable element? That’s pretty crazy. Unfortunately since both of these bullets exist within jQuery UI code that isn’t extendable we are forced to find another solution. (I may do a pull on jQuery UI’s source to allow a custom tabbable algorithm which can shortcut the expensive “:tabbable” selector in the future)

An easy solution

Head on over to the demo and click the “Trigger dialog fast” button. Wow, much better! That comes up almost instantly on my machine with only a slight delay. What is the huge difference you might ask?

Instead of creating the dialog around the existing large table as seen in “Slow code” below “Fast code” first detaches the children of the future dialog, creates the dialog and then re-inserts the children into the DOM after the dialog is created. This makes all the difference by allowing us to circumvent the painfully slow DOM parsing of all those table rows. The “detach” is also very important because it allows any events, (jQuery or otherwise) to remain wired up to the table elements that will soon make there way back into the DOM.

Slow code

Fast code