Front End Performance Reminders

One of the staples of The Watch column is performance. Many of the posts here are directly or indirectly related to this key subject. In recent posts, I’ve referenced how optimizing front end performance can lead to major improvements in browser response, leading to a greatly enhanced user experience. So, just what does it mean to optimize front-end performance?

Here is a partial guide to some of the steps that you (or your webmaster) can utilize to tighten up the front end performance of your browser. Using Keynote KITE is a great first step. Record some common user interactions with KITE, run the scripts a few times, and then analyze the logs. The analysis may very well yield some interesting trends in the code. Many of these tips are pretty well known, but not followed consistently (according to developers I cross paths with). For specific details, take a look here (Christian Heilmann's blog), here and here. Here are some of the areas that are worth looking at:

Optimize your Java Script (JS) – A common performance bottleneck is often in the Java script. Here are four techniques that can help:

• Cache your objects and scripts: Caching objects means the storing a repeatedly accessed object inside a user defined variable, and using that variable instead in subsequent object references. This is far more efficient than calling the object repeatedly, thus dragging down browser performance. For nuts and bolts on the coding click here.
• Be aware of the cost of JS objects. Some are more expensive in system resources than others.
• Make the Java Script code “external”: If users of your site have multiple page views per session and many pages reuse the same scripts and stylesheets, then make JavaScript “external” (i.e. keep the code outside of the HTML document, and have the script called from inside of the HTML code.)

Reduce DNS lookups: Every DNS (Domain Name System) call takes from 20-120 milliseconds to look up the IP address for a given host name. The browser can’t download anything else until this lookup is completed. For better performance, DNS is cached by the OS and the browser (30 minutes is the windows default, Firefox is 1 minute). Performance guru Steve Souders is among the many who suggests reducing the number of unique hostnames, which of course will lower the number of lookups.

Compress Your Images: Compression and using smaller sized images when possible is a natural inclination, but there are a few other tricks that can be applied to improve efficiency of your images.

• Christian Heilmann suggests using Yahoo's Smush.it to compress images without a loss of quality.
• Convert a GIF to a PNG file when possible. Often PNGs are far smaller than their GIF versions, which will improve performance when being loaded.

Avoid Redirections: If you’ve ever typed in an outdated web link, you may have seen the 301 or 302 status code. This will take the user to the URL that is specified in the location field defined. Redirects slow down performance time because nothing else can be done, no page rendering or component downloads – until the HTML document has arrived.

A common redirect problem is a rather subtle one:The hanging blackslash (“/”) on a URL address. For instance, going to "www.foo.org/NewPage" maybe incorrect, but will send the user to " www.foo.org/NewPage/" instead. The delay in the redirection can degrade the user experience due to slower performance.

Ditch the 404s – This close relative to redirection issue, the dreaded “404” is the dead link that is not redirected. Mr. Souders is fond of this one. Getting a dead link is a bit like taking a $50 cab ride to your favorite restaurant – and finding a vacant lot where it used to be. Any HTTP request is considered an expensive one in resource terms, so you can imagine that making a HTTP request and getting a 404 response is particularly heinous. Check your links while coding and ensure that dead ends are removed as soon as possible.

Don't forget to Flush the Buffer, please – It can take from 200 to 500ms from the time a user requests a page to the back end server delivers everything needed for the user to see it. Since the browser can sit idling while waiting for the information to arrive, a flush action (PHP function flush()) allows for a partial response. In this way, the browser can fetch components for what you have downloaded, while the rest is on the way.

Good hunting!

UPDATE: The links for the sources of this article have been re-added. My apologies for any omissions.