Have you ever thought about how many customers you lose by having a slow site? And I’m not talking about file size only, as we rely on browser capacities to understand our code, we need to consider the processing time also.
That’s why sometimes adding a few bites in your code is much better because it save you precious seconds when real browsers or IE try to process your code.
Let’s see a few nice tips on how to improve this:
1. Don’t repeat yourself
You should use the cascade and avoid repeating code. It’s more than just using common classes, you could make good use of the heritance, for instance, so properties that can be set in the parent should be left there. Also you could use the same set of properties for multiple elements (separating multiple selectors using commas, you know).
Also, in your JS make good use of objects, functions and plugins so you don’t need to repeat code.
2. Write from right to left
Unlike us, browsers will process jQuery and CSS selectors from right to left. You may think that this won’t affect your code, but the truth is that it changes everything. A selector like this one is really, really bad:
$(“body #container div a”)
What we think we are writing is “Hey Browser, find the ‘body’ tag, and then inside of it find the #container. There you’ll find a ‘div’ and a couple of ‘a’ elements, let’s select those”. But the browser will actually read the entire page searching for ‘a’ tags, then for each tag it finds it’ll check if it has a div as parent, then check if the div has an element with the #container id, then
check if there’s a body tag beneath them.
Image from This is just too messy. In the JS we have some elegant solutions, like the find function so your code will actually be read as you wanted. Something like this would be good:
$(“#container”).find(“div”).find(“a”)
When you’re writing CSS you don’t have much options but leaving it as specific as possible, so try finding the closest class or ID you can find.
3. ID’s are really fast
Whenever possible use ID’s, they are faster either in CSS or JS. When using JS you have the possibility of using alternatives rather than jQuery to select tags, like document.body or even passing the entire DOM tree as an array (if you already know the exact location of the element).
4. Keep the selectors short
Keep in mind that sometimes an extra item in your selector will just mess up your code. For instance if you have a “ul li a” selector, you could simply use the “ul a” and you’ll be fine.
The best JS tip we can give you is “don’t use it”. Most times you simply don’t need it and using will cost you a lot more in performance, development time, browser compatibility and maintenance.
You can replace a lot of animations by CSS animations, and you could also use a library like yepnope or modernizr to conditionally load fallbacks for browsers that can’t keep up with your awesomeness.
6. You don’t need to declare your vars, but you should
A lot of people simply skip the var declaration step. That’s ok, but you’ll create a lot of global variables that can break other functionalities and also when the browser has to recover it, it’ll search from local to global scope.
Even if you’ll use a global scope var, you can redefine it locally so you’ll save some time. For example, instead of doing this:
var e1= document.getElementById('ID1'),
e2= document.getElementById('ID2');
Do this:
var doc= document,
e1= doc.getElementById('ID1'),
e2= doc.getElementById('ID2');
So you’ll locally store the document var
7. Do math like you do in your head
We tend to think that programming languages do some kind of black magic and give us the result of complex operations. But the truth is that every single operation has a processing cost. For example, instead of doing 2*15 it’s much easier to do 15+15.
The true tip in this case is, use the more native JS code as you can, so avoid relying on jQuery or other plugins because that will certainly take more time to load and often more code to write.
Image from BONUS: 8. Remove one image from your source code
The One Less JPG movement is right when they say that removing one image from your source code would save you far more bites than what you’d save by worrying about JS (and CSS). But the truth is: You should do both.
We should always do our best to improve user experience and if that means that an image will look good in the page, and the fancy JS animation has to be removed, so do it.
Thanks for the great article! Someone needs to write a coding and naming convention ebook for newbie front-end developers (like me) to help with the development efficiency (especially in a team environment). I’m still trying to get my own convention together by trial and error and learning from other developers.. sucks. :/
Agreed. One thing I learnt today is to write from right to left especially when dealing with javascript. Picking up font-end development is pretty difficult given the amount of overwhelm, and a good convention ebook will definitely help in learning
Hi Guys!
That’s a great idea! Maybe we can talk about this in a future article or an ebook.
-roch
3. ID’s are really fast
How do you support that? Can you post any benchmark?
Hi Juan,
This is just the first google result: https://stackoverflow.com/questions/2559934/id-vs-class-selection-benchmark
🙂
Are you serious with number3? Did you ever read a bit about OOCSS or SMACSS? I highly advise you to do so!
Hi!
In CSS this can be tricky indeed, but for JS id’s are way better!
-roch
There is a book for that already 🙂 here is the link https://smacss.com/ it’s really good and useful,
also – it is a good practice to not use ids in css!
Thanks for your comment Dawid!
Interesting article. I’d love to hear more insight into how much faster, or more of an advantage, using ID’s vs. Classes in CSS. Can it make that much difference? I had no idea but am certainly interested on hearing more on the pros/cons of either.
Cheers!
Hi Matt!
In app development this could certainly save you precious ms.
I couldn’t find any benchmark test but this may help you in your hight performance path: https://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
-roch
IDs are not always faster, https://madebyhoundstooth.com/blog/javascript-selector-performance/
Hi Rob!
This is quite surprising, if we check how many other benchmark tests say that IDs are faster.
-roch
This is awesome! Thanks for posting this great article.
Hi Sheldon!
I’m glad you liked it! Keep coming we have a lot more cool stuff to come.
-roch
#2 is really interesting, thanks for the info!
You’re most welcome Patrick!
-roch
Thanks – great tips! Would add only one – if you are not sure, or don’t know js well enough – consult the professionals. You will avoid a big number of mistakes. And if you don’t want to pay you can at least use forums
Hi Victoria,
That is so true! An expert would know the optimal solution and 15min consultation could solve a lifetime issue.
-roch
1)IDs are the fastest
2)Tag names are next fastest
3)Class names with no tag name are the slowest
Hi Aamir!
That’s the right order indeed.
-roch
The “Do math like you do in your head” is a horrible example. Any multiplication by 2 on a computer is going to be ridiculously fast because it just requires a bit shift operation.