If you’re familiar with jQuery you should already know what are selectors and how they work. However we’re used to get some DOM element with a specific selector, but actually sometimes you cannot select directly what you need. This is especially true when mixing more than one JavaScript libraries. In my case OpenLayers generated a vector layer and jQuery was supposed to change the vectors fill-color property.

With the simple $(‘path’) I easily got all vectors in the current document, but the problem was that I took them as text. Thus it came to me to use nested jQuery – $($(‘selector’));

To describe what actually happened in my case, let me show you a breve example.

Example

Here’s a short HTML markup:

text text

With jQuery I can select both the DIV and SPAN with the simple $(‘div’) and $(‘span’), but just for the example lets assume I’ve only the inner text of the DIV tag:

$('div').html();

That was the case in the OpenLayers/jQuery problem. Now I can easily use another jQuery selector:

$($('div').html());

This will return the same as $(‘span’) – a jQuery object.

Perhaps! I was curious how can inefficient selectors impact a page performance. To begin with this topic let me say that inefficient selector is referred usually as nested selector:

div span div {
    border:1px solid red;
}

as you can see here there are three nested tags I use to reference the innermost div. If you’re wondering how you’d know about inefficient selectors – well there is a plugin for the Firebug written by a Google team called Page Speed explaining which of your selectors are inefficient. See the image below.

In the demo page you can find what I was trying to achieve and you can play around with that code to measure by yourself the performance of the different selectors.

So who’s faster? Nested, IDs or Classes?

Actually its pretty though to say. Yet another surprise for me was to notice that the notation:

div.my-class {}

was a bit slower than the marked as “inefficient” by Page Speed:

div span div {}

Another good thing to mention is that there is a difference between div.my-class and .my-class

Question’s answer …

In fact div.my-class is always with a higher priority than .my-class even if you’ve the following code:

div.my-class {
    border:1px solid red;
}

.my-class {
    border:1px solid blue;
}

div span div {
    border:1px solid black;
}

And the computed style for Firefox was …

where “div span div” chain matches the same elements as the previous selectors, as you can see:

so even that div.my-class will be the most important and finally the element will get its red border! It does not depend only on where you put the CSS rules, but also on how they are defined.

Have you ever mentioned the existence of the LABEL tag? Have you ever used it? I guess the majority of us don’t. Let’s take a look of the following chunk of code:

<label>username:</label> <input type="text" name="username" />

It looks familiar to every web developer, but the most common usage in web forms is:

<div>username:</div>

or

<span>username:</span>

How Looks a LABEL Tag?

In fact if you use LABEL for the form instead of DIV or SPAN you’ll get the exactly same result as layout, beside that most common usage is a DIV or SPAN in place of the forgotten LABEL?! Why is that?

Can you see the difference between LABEL and SPAN?

For me the usage of DIV has become critically enormous. It may sound strange that there is a debate about the usage of one or another HTML tag, but don’t you think every little text label in a web project is surrounded by a DIV. Actually that makes clear that if you’d like to be semantically correct, than you should use LABEL.

The funny thing is that almost every project is loading its labels in a PHP array or object or whatever and there they are called “Labels”, but when it comes to HTML they are put into a DIVs.

Why Semantics Matters?

In fact this is important because this is really good for web robots. If this is not important for the human eye it is for a machine “eye”. That’s why there are two tags for bold text.

STRONG vs. B

You can see that most of the browsers display both tags exactly the same by default.

Why’s that? Because STRONG is semantically more important than <B>.

So if you want to make a text simply looking bold, wrap it in <B>, but if you want to make it important both for the human eye and for the machines, than use STRONG.

Source: complete demo.

Why?

Maybe because nobody things that the HTML source of a page can be optimized or the optimization of it cannot bring some benefit to the page load experience. I don’t thing so. If something can be optimized, even if this does not give you so much, why you shouldn’t do it?

How to optimize such thing as HTML?

Well there are few things you should do and other that can speed up a little bit but you should not.

1. Enable gzip

What is gzip? Well in breve everything the server generates is sent back to the client in text format. You’ve to possibilities to send it. Either compressed or uncompressed. As you may guess the compressed format is a lot faster than uncompressed. In fact to make it work that way you’d need to enable gzip which is supported by the web server. In the case of Apache web server this can be done by enabling mod_deflate. Take a look of mod_deflated and mod_inflate. This two modules gives you the possibility to make your site a lot faster and the good news is that this is done without a single line change. The bad news, as always there’s a bad news, is that sometimes this cannot help a visitor, simply because his browser doesn’t support such corresponding with the server. According to a research I’ve read recently almost 15% of the web browsers doesn’t support gzip. Sometimes the reason is old browser versions, sometimes because the state policy doesn’t allow it. However this is the first thing you should do to speed up your HTML even it is not related directly to HTML scripts. By the way this will speed up everything which is sent back to the client, especially CSS and JavaScript files and in the case of JavaScript this can improve dramatically the user experience.

2. Use div elements instead of tables when possible.

This is the second thing you can do to speed up your site. The simple reason to do that is because the DIV element doesn’t need so much markup as a TABLE element. When widely used in a page – imaging thousands of tables this can be a disaster. Remember the first thing is to make the text you send to the server as small as possible. In that point I should say that not only the tables to div switch is enough. Always prefer smaller tags and constructions. This is a bit difficult. Some experienced web developers can construct the same page with less HTML markup than newbies, but that depends of your level of experience.

3. Make it ugly – just to spend some space.

Your code is beautifully organized and when viewing the source everyone is excited! That was a mistake I used to make in my early projects. Why we thing somebody will take a look of the source code? Why we thing somebody’s using view-source option? Because we’re sick minded web developers. Nobody cares about your well organized source code. Normal users don’t look at it! Forget about beauty! As you may remember – you should spend all the extra spaces you send to the browser. Well if well organized the source code is full of tabulations, new lines and spaces. This is not good! Well if gzip is enabled they may be spent to the client, but if not? Stop writing beautiful HTML. The first task is to make it readable and maintainable.

4. Don’t use inline styling

This cannot be cached by the browser, is difficult to maintain and is – ugly! Yeah don’t use inline styles it makes your markup larger, which yet again is bad and is difficult to maintain. Write everything in CSS files, include them from the outside and setup only the classes you need.

5. Make it maintainable

Although its important to make the HTML as small as possible, sometimes that means to make it as ugly as possible and that brings the enemy number one – unmaintainable code. After a while the change of that code is technically impossible. So use all these techniques with something in mind – make it maintainable even if that will sacrifice some optimization benefits.

To start with some example let’s assume that there is one DIV element with 100 A tags inside. If you assign event to every A tag that as you may know slowes down your browser. That’s a problem because sometimes that can happen, even with more than one hundred A tags. Imagine you’ve a map with one thousand markers, which are A tags. Attaching events slowes down the browser, because every of these A tags bubbles the event that has been fired. And that makes your CPU to make thousands of calculations. Of course you can avoid this problem with a simple technique. Just attach one single event on the container DIV element. Thus you can check if some child of the DIV element has been the target of the event. This makes the browser to breath.

2. How event delegation is implemented in jQuery – $.live()

In jQuery the so called event delegation is done by the $.live() method. As you may see in the doc pages of jQuery thus you can attach events on a selected element even before that element exists into the DOM. Just because the attached event is on the parent element, and once there are more and more elements attached to it as children, thay behave the same way as those attached before.

Example:
$('div > a').live('click', doSomething);

3. bind with $.bind() or $.click, $.mousemove …

More common use in jQuery is to attach elements with $.bind or it’s shortcus $.click, $.mousemove … etc. The problem is that you have to call them again and again after you add more and more elements to the DOM, because this attach events to the matched elements. Normally when you add more elements they don’t have any event attached to.

Example:
$('div > a').click(doSomething);
// this example does exactly the same thing as the one above,
// but applied on 1000 tags is much slower!

4. Performance

Of course the performance is better with $.live, but be carefull when playing around with those methods. See more performance results here.