Web Performance Tips

Performance Checklist: Front End Side

Ravi Raj

Discuss some development tips thats helpful to improve performance

Don't Put CSS in body tag. CSS in the body can block rendering, especially in IE

Put only js needed to render the page in the HEAD section. Everything else can go at the end of the BODY.

Scripts block parallel downloads , While a script is downloading, the browser won't start any other downloads, even on different hostnames.

Avoid Redirect (really harmful as performance point of view)

Preload Components :- take advantage of the time the browser is idle and request components (like images, styles and scripts) you'll need in the future.

Based on a user action you make an educated guess where the user is headed next and preload accordingly

Cookie:- Eliminate unnecessary cookies Keep cookie sizes as low as possible to

minimize the impact on the user response time

Be mindful of setting cookies at the appropriate domain level so other sub-domains are not affected

Set an Expires date appropriately. An earlier Expires date or none removes the cookie sooner, improving the user response time

DOM manipulations are the slowest Never update the DOM if that's not possible, at least do it as infrequently as possible. Bunch up

your updates to the DOM and save them for a later time. Realize that it is not the size of the update but the high frequency of updates that's slow. Doing appendChild in a loop is updating the DOM frequently. Caching the markup in a string, and then setting the innerHTML in the end is batching and updating infrequently. The second is much faster.

What if you are updating existing elements on the DOM? How do you keep updates to a minimum when you want to change style, class names, content and children of a node that already exists? Simple. Clone the node you want to work with. Now you will be working with a clone of the real node, and the cloned node doesn't exist in the DOM. Updating the cloned node doesn't affect the DOM. When you are done with your manipulations, replace the original node with the cloned node. However, note that the performance problems here are because of the content and rendering reflow that the browser has to do. You might get similar benefits by simply hiding the element first, making the changes, and then showing it. Though I haven't tried this, it should work in theory.

Keep track of events. For me, this is the worst part of working with the DOM. This is important because when your application (or any DOM nodes) are being unloaded or destroyed, you will have to manually unregister the events from the nodes BEFORE you destroy the elements. Yes, this is the garbage collector's job, and that's supposed to be the job of the environment your code runs in, but guess which browser is the offender here. Internet Explorer doesn't free all the references even when the user leaves your web page. Unless you want your web app to earn the reputation of being responsible for many a crashed browser, and a horrid browsing experience for other websites too, count your references.

If you are going to iterate through a node list to attach event handlers, you are probably wasting processor time. Instead, simply attach the event handler to some parent of the node list and read from the event object to know what was clicked on. You save the cycles required to iterate over the nodes this way.

Avoid calls to functions like getElementsBySelector, where there's lot of DOM walking involved. If you cannot, then make sure you work on as small an area of the DOM as possible. If your favourite version of getElementsBySelector lets you send in a root node under which to search, do that. Otherwise, provide a very high specificity, starting with a "#someId" so that the function can narrow down the search. Also, understand how these functions work internally. For example, you could use a getElementsByClassName to find divs with the class "foo", and the implementation of getElementsByClassName will probably be just three lines, However, using getElementsBySelector("div.foo") will be faster in almost all frameworks, even though it might have a hundred lines of code in it's implementation, since it has less DOM walking to do.

WRONG ( it touches the live DOM each time through the loop)

for (var i=0; i < items.length; i++){ var item = document.createElement("li");

item.appendChild(document.createTextNode("Option " + i);

list.appendChild(item); }

RIGHT (create a document fragment as an intermediate placeholder for the created li elements and then use that to add all of the elements to their parent )

var fragment = document.createDocumentFragment();

for (var i=0; i < items.length; i++){

var item = document.createElement("li");

item.appendChild(document.createTextNode("Option " + i);

fragment.appendChild(item);

}

list.appendChild(fragment);

IT touches the live DOM only once, on the last line. Prior to that, the document fragment is used to hold the intermediate results. Since a document fragment has no visual representation, it doesn’t cause reflow when modified. Document fragments also can’t be added into the live DOM, so passing it into appendChild() actually adds all of the fragment’s children to list rather than the fragment itself.

WRONG(code has three style changes…and also three reflows. A reflow happens with every change in style to this element. If you’re going to be making a number of changes to an element’s style, it’s best to group those in a CSS class and then change the class using JavaScript rather

than applying individual style changes manually) element.style.backgroundColor = "blue"; element.style.color = "red"; element.style.fontSize = "12em";

RIGHT .newStyle { background-color: blue; color: red; font-size: 12em; } element.className = "newStyle";

very important to cache results that you retrieve from the DOM

document.getElementById("myDiv").style.left =document.getElementById("myDiv").offsetLeft+document.getElementById("myDiv").offsetWidth + "px";

IT IS WRONG ...

The three calls to getElementById() here are the problem. Accessing the DOM is expensive, and this is three DOM calls to access the exact same element. The code would better be written as such:-

var myDiv = document.getElementById("myDiv");

myDiv.style.left = myDiv.offsetLeft + myDiv.offsetWidth + "px";

HTMLCollection type … This is the type of object that is returned from the DOM anytime a

collection of nodes must be represented, and so is the type of the childNodes property and is the type returned from getElementsByTagName(). An HTMLCollection may act like an array in many ways, but it actually is a living, breathing entity that changes as the DOM structure changes. Every time you access a property on an HTMLCollection object, it actually queries the DOM for all nodes matching the original criteria once again.

WRONG var divs =

document.getElementsByTagName("div"); for (var i=0; i < divs.length; i++){ //infinite loop

document.body.appendChild(document.createElement("div"));

}

This code is an infinite loop because every time a new div element is added to the document, the divs collection is updated with that new information. That means that i will never reach divs.length because divs.length increases by one every time through the loop. Every time divs.length is accessed, it collection is updated, making it far more expensive than accessing a regular array’s length property. When dealing with HTMLCollection objects, it’s best to minimize the number of times you access their properties. You can speed up a loop tremendously by simply caching the length in a local variable

RIGHT var divs =

document.getElementsByTagName("div"); for (var i=0, len=divs.length; i < len; i++){ //not

an infinite loop

document.body.appendChild(document.createElement("div"));

}

THANKS

[email protected]