I wrote a post before the weekend about some performance issues with MooTools, DHTML and AJAX, but having found the solution to a related problem this morning, I wanted to post a followup.
I’ve been working with a large, dynamically generated and AJAX populated table that features sorting, filtering and row highlighting, and was finding that my table took a long time to render, and was also very slow to close - that is, when I tried to close the window or refresh the page, there would be a delay when the browser would first hang for a few seconds. IE often (but not always) popped up the error/prompt Stop this script running?, and Firefox less often threw it’s Unresponsive Script warning.
I’d heard of MooTools’ garbage collection functions that reduced memory leakage, and figured that these were probably responsible. I then found Kevin Smith’s write up of his similar experience, and came to understand the problem. MooTools’ garbage collection takes time to clean up any element that has been extended. My table was executing the following code, effectively extending every table row in the table, resulting in some 500+ extended elements.
// MooTools Code
Element.extend({
…
getChildren: function(){
return $$(this.childNodes);
},
…
});
…
// My Code
this.tablerows = this.body.getChildren();
When it came to cleanup, this javascript processing took longer than IE’s configured script timeout, and thus prompted the warning.
To avoid this cleanup overhead, you’ll have to avoid extending the elements with MooTools’ extensive set of functions and instead extend the specific elements in question with the specific functions required.
I first delved into javascript frameworks with Prototype, but I quickly realised that the Prototype+Script.aculo.us combination, even in Protocoluous or Protopackt form, was never going to work - it was just too slow.
I moved to MooTools, and for a while was pretty happy - load times were quicker, effects smoother.
But having recently tried to build sorting and filtering functionality into an HTML table of 200+ rows, I’ve been forced to take a closer look at how different browsers execute javascript, and at where the bottlenecks are. Here I’m going to promote a few best practices, largely via Julien LeComte at Yahoo.
Inserting new Elements
Working with the DOM in MooTools is a breeze - code like the following is a pleasure to write and to read:
var div = new Element(’div’, {id:’example’}).addClass(’example’).setHTML(’Example Content’).injectAfer(’previousElementID’);
However it’s worth noting that the Element class uses ‘document.createElement’, which is much more expensive than the alternative, albeit less readible innerHTML. Further, inject() and adopt() functions use appendChild() and are also thus very expensive. An it certainly feels like this effect is magnified when working with tables.
Changing Existing Elements
Working with with DOM can cause performance issues, but if the DOM element in question is not visible (display:none), or if the DOM element is ‘off-DOM’, you’ll acheive a performance gain.
Retrieving Values from the DOM
Retreiving values from the DOM is much more expensive than referencing a local variable:
// bad code
children.each(function(child) {
if (child.getText() == otherElement.getText()) alert(’slow’);
});
// good code
var text = otherElement.getText();
children.each(function(child) {
if (child.getText() == text) alert(’fast’);
});
Attaching Event Handlers
Attaching events is also very slow. To tackle this, instead of looping through multiple elements attaching events, attach the event handler to the parent, and within the handler detect which element has been clicked:
// bad code
children.each(function(child) {
child.addEvent(’mousedown’, function () {
alert(child.getText());
}
});
// good code
parent.addEvent(’mousedown’, function (e) {
var child = new Event(e).target;
alert(child.getText());
}
By applying these ideas, I was able to cut the processing time of loading a table by more than 70%, and hopefully you can benefit too.
“Web Standards” is like another of these modern-day web buzzwords, like “Web 2.0″ and “The Blogosphere”. But buzzwords become popular for a reason - let me give this one a simple definition, and explain the business benefits of web standards, namely reduced website costs and risks.
Web standards are, quite simply, a set of coding guidelines developed by a consortium of experts to reduce the risks involved in producing a website. The simple principle is that if everybody codes in the same way, the standard way, then everybody is compatible. More >>
If you are still using just hits and pageviews to measure your website’s performance, it’s time to ask yourself a few questions about how well you understand the performance of your website. How do these metrics contribute to understanding of how well you are acheiving your business objectives? eMarketing is just like offline marketing, in that requires measurement followed by optimisation. Only better, because we have more data.
Thus, central to every web project should be a Website Performance tracking sheet outlining targets and progress across a variety of measures that together communicate to your web management teams a picture of performance towards objectives. Use your imagination to find those indicators that provide into the performance of your website.
Below are a few alternative metrics to get you thinking. Do you know how well youre website is performing? What would your targets be?
- New Referrers
- Basket Size
- Repeat Purchase Count
- Number of Commenters / Comments
- Other Content Contributions
- Monthly Membership Registrations
- Newsletter Subscriber Count
- Click-Thrus from Newsletter Links
- Number of Social Bookmarks (i.e. Diggs)
Update: Bud Caddell has also written a post about website performance indicators along similar lines over at seoMoz.org, with a more exhaustive list.
