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.create
Element("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.create
Element("div"));
 }

 THANKS
 raviraj4u@in.com

Web Performance Tips

More Related Content

What's hot (18)

Similar to Web Performance Tips (20)

More from Ravi Raj (8)

Recently uploaded (20)

Web Performance Tips