Client Side Efficiency
Recently, a team member and myself where looking at a page, and trying to see why suddenly it was rendering slow, even on our local machines. We knew what was new, so we knew what "pushed" the page over the edge, to avoid the problem in production, however, in reality there is no reason even a large addition of html would slow the render down that much if the html is clean enough. We stepped through all the server side, and it was fast as lighting, which left the client side source.... fun fun... html and javascript.
When looking at the page, we had several tables, which had a bunch of images, that had onclick events. The thing about javascript is it all needs to be validated by the browser ( something my collegue explained to me kindly, which brought about a fantastic idea )... let's remove all the javascript.
But hey might be thinking... if you take out all the script, then the page doesn't really do much of waht you originally intended, does it.
Well... yes and no... as my colllegue kindly explained... the key is to put pieces of the puuzzle that you already know... and think of how they may play nice together.
In comes the DOM, client side event... and a little fun thinking from the "xml" world.
Attributes are very fast. much faster then elements. If you have many attributes on something, it's almost negligable. If you have javasccript on it, it takes a bit to validate. id is an attribute.
So... thinking about this... the solution went on.... everything is in some sort of container. which means... with DOM you can access anything in a container. events... Events bubble... means... if an event happens on something and the event bubbles up through it's containers all teh way to the page.
So... let's take this example.
<table>
<tr><td onclick='alert('clicked me');'>click me</td></tr>
<tr><td onclick='alert('clicked me');'>click me</td></tr>
.... Repeat a bunch of times.
<tr><td onclick='alert('clicked me');'>click me</td></tr>
</table>
with only one cell, you will have a hard time slowing down your page... but if you expand the test to several cells, with some varied javascript, you will eventually "break" the barrier and IE (i havent really tested in firefox cause we dont care about it much at work ;-) ). and the page will noticiblaly take it's "time to think".
now.... a better aproach i was taught...is to do something like this...
<script language='javascript'>
function myfunc(){
var clickSource = event.srcElement;
if(clickSource != null){
alert(clickSource.getAttribute('txt'));
}
}
</script>
<table onclick='myfunc()'>
<tr><td txt='clicked me'>click me</td></tr>
.... Repeat a bunch of times.
<tr><td txt='clicked me'>click me</td></tr>
</table>
basically, event thoguh the page sice might end up similar, althoguh in most case your js is probably longer than alert... so it will save size, but it will also render alot faster.
if you want a more visual understanding of the test, put an id='unique' on each td cell, and then do an aler(clickSource.id) in your myfunc to see that the srcElement is actually the td and not just the table.
what is happening is that the the event is the click... which happens at specific coordinates. that event happens in a single most direct container... in this case the td.. So.. the srcElement (source element) is the containing td of the event, which 'bubbles' all the way to your onclick event which is the first 'capture' for the event. if there where no onclicks then the event would go unnoticed. .as well, if you did not target the event.srcElement, and use it.. it would go unnoticed.
Well, that's my client side advice for the week.