In my previous article (Performance Tuning Resources For Web Clients) I discussed why you should care about the of your web client and then listed out some of the better places to go on the web to find information on how to go about tweaking your web clients to get that better . In this article I am going to dig a little deeper and call out specifically what I think are the Must-do-No-excuse-not-to-do-them-You-are-really-being-unprofessional-if-you-are-not-doing-them tweaks that you should be performing on every single one of your web development projects.

This list by no means represents all of the tweaks you might want to consider doing to your web clients to make them perform better, they are just what I consider to be the absolute bare minimum. If you are already consistently doing all of them, firstly congratulations, and secondly you should stay tuned for a future article about what I think are some of the more advanced tweaks that you should also be considering.

#1 – Declare A DOCTYPE And Validate Your

This one doesn’t show up in many other resources on this topic, but I think it is a critical first step in shaping a document to be as lean as possible. I cannot guarantee that this tweak in isolation will do much for your performance, but it will help you achieve some of the later tweaks.

One important point about using a DOCTYPE is related to what is called Quirks Mode. Basically what it means is that depending on whether you have a DOCTYPE present or not, and which one you use if it is present, the browser will behave differently in terms of how it renders the page. I suggest you use a DOCTYPE to lock down browser behavior and allow you to eliminate much of the need to detect the type of browser being used and adapting to that browser’s own nuances, which only slows your page delivery down.

There is a great discussion of Quirks Mode here if you want more details.

Validating your document will also help you eliminate incorrect and superfluous tags. The World Wide Web Consortium (W3C) provides a tool called the Markup Validation Service that will automatically validate your document based on the DOCTYPE you used. There is also an equivalent CSS Validation Service.

So, make sure your HTML and your CSS are compliant with a recognized standard, because forcing a browser to process slightly invalid documents and styles cannot possibly help with your rendering performance.

#2 – Reduce Elements

This is just common sense – don’t put any more tags into your HTML than you absolutely have too. More tags means more bytes to download, which is obvisouly a bad thing. Use the validators from #1 above to help identify unnecessary tags.

Additionally once your page has downloaded, if you are using to traverse your DOM, less tags and less nesting will also improve your script performance and hence .

More information is available on this Yahoo! page on how to further reduce the number of elements you are using.

#3 – Move JavaScript And CSS Into External Files

There are many opportunities for caching of static content, particularly within the browser itself, but also within intermediary proxies that might be part of your client’s network.

If you have a blog front page that changes regularly with each new article that is published, then your clients are going to have to likely download that whole page each time they visit your site. However, it is really only the article content that is changing, the page layout, the main styles, the main images and logos and many other pieces of the page are not changing at all – and yet your client has to download them as well.

So by moving all of your CSS styling information and JavaScript scripts to external files (now with their own unique URLs), you not only reduce the total size of the main page that gets downloaded each time, but if those CSS and JavaScript files are not changing, then they can be cached and not downloaded by your clients each time (you can exert some control over the frequency at which they do get downloaded, however I am leaving that for the more advanced tweaks list).

Notice that this does actually increase the number of individual resources that need to get downloaded the first time someone visits your site, but with a good caching setup it will result in increased performance for your client over subsequent visits.

Some more information from Yahoo! on this topic.

#4 – Avoid HTTP 404 (Resource Not Found) Errors

This applies at the whole page level, but also for the individual resources that a page references. Having a page try to load style sheets, scripts, favicons and other resources that are not available at the supplied URL wastes a lot of resources (both on the client and the server) and slows down the page loading and rendering, even if the page is still functional without those resources.

However, please do remember to have a useful and informative 404 error page setup for your site just in case something does go horribly wrong otherwise you may lose that visitor (money?) forever.

Yahoo!’s take on this topic.

#5 – Adjust Image Format And Quality For Web Delivery

Images that are intended to be displayed on a web page should be specifically created for that purpose. Reusing high-quality images that were intended for various print mediums are likely going to hamper your website performance.

The basics:

  • Use an appropriate color depth for your image. The higher the color depth, the larger the image file. If you have a black and white image, but have 256 bit color turned on, you can optimize this easily.
  • Use the correct file format for what you are trying to display. PNG is often smaller than GIF. Only use JPG for complex images or photographs.
  • Consider removing any superfluous meta-information embedded in your files (like EXIF tags).
  • Don’t use images to achieve layout effects – like leaving whitespace around the main image to create a padding effect. Trim your images to within a pixel of their lives and then use CSS to get the layout effect that you want.
  • Consider using various image manipulation tools to compress the files even further.

Don’t forget that these rules also apply to your site’s favicon image (see Yahoo!’s notes specifically on favicons).

has a good reference on this topic called Optimizing web graphics.

also has a good reference.

#6 – Resize Images And Declare Image Dimensions

The IMG tag supports a height and a width property that are both optional. If you don’t declare values for the width and height properties, the image is rendered at it’s native pixel resolution.

Unfortunately this means the browser does not know how much screen real estate to reserve for the image until it is fully downloaded, so it initially just creates a placeholder on the page. This leads to the unsightly shuffling phenomenon as elements on a page are moved around to accommodate the images as they finish downloading and the browser discovers their true size. So by setting the height and width properties, the browser can know ahead of time how much real estate to reserve for the image and can continue confidently rendering the page even if the image has not finished downloading yet.

The second issue occurs when you leverage the built in image scaling functionality that offer. For example, if you have an image that is natively 400 pixels wide and 400 pixels high, but you set the value of the height and width properties of the IMG tag to something smaller like 200×200, your browser will conveniently scale the image down on the fly.

This seems like a nice helpful feature, but in reality, in the previous example your client just downloaded about 120,000 pixels worth of data that was of no benefit to them. It is much more efficient to resize the native image to the size you need it to be on the client.

So manually resize your images to match the size you want to display them on the client and then also declare values for the height and width properties of the IMG tag to match.

Yahoo!’s thoughts on image sizes.

#7 – Put All CSS In The HEAD Of Your Document

As the HTML standards have evolved, many of the presentation related tags have been removed (or just frowned upon) in favor of using CSS to control the presentation of a page. The natural extension to this is to remove all of the CSS information from the main body of your page to achieve a complete separation of content and presentation (which has many additional benefits unrelated to site performance).

If you must include CSS information within your page, make sure it is within the HEAD tag (however you should strongly consider tweak #3 above first). By moving all of the CSS information to the HEAD (whether it be inline or external) the browser has all of the style information it needs before it starts processing the body of your page and can then render the page progressively.

BTW, if you didn’t know, linking to an external stylesheet outside of the HEAD tag is actually a violation of the HTML DOCTYPE.

Yahoo! elaborates on why this is all a good idea.

#8 – Move JavaScript Files To Later In The Document

Depending on specific circumstances, a browser can download multiple resources in parallel. The one exception is external JavaScript files, which block the download of other resources until the script has finished downloading (for good reason, see discussion of non-deferrable scripts below).

Most JavaScript files (particularly in these days of large libraries) are deferrable – in other words they don’t need to be downloaded and available until the very last moment – effectively just before the document.onLoad() function is called.

An example of a JavaScript file that can not be deferred would be one that contained a call to the document.write() function, that was outside of any other function – in other words it is intended to be executed as the script is read by the browser for the first time and write a portion of the current page.

So if you have scripts that can be deferred, move the reference to them to the bottom of your page so that all other resources are loaded first. Keep in mind dependency resolution – like an inline script early in a page that refers to a JavaScript function defined in an an external file, in this situation the external script can’t be deferred no matter what.

Yahoo!’s take on why this is a good idea.

#9 – Merge CSS And JavaScript Files

There is an overhead associated with requesting and downloading each external resource referenced by a page. In addition the HTML standards limit the number of parallel resources that can be downloaded from the same server at the same time. So it is a good idea to reduce the number of client-server requests that are necessary to render your page.

So, take a look at your CSS files and your JavaScript files and look for opportunities to merge them. Obviously the ideal situation would be one CSS file and one JavaScript file referenced per page. However, in most large web development projects this 1:1 ratio is likely to be impractical, but it is still worth attempting to reduce the overall number as much as possible. In particular look out for the same JavaScript file being included more than once (probably by different developers) which is a common problem in large projects (it is such a problem that Yahoo! calls it out directly).

There is an analogous technique for merging images together called CSS Image Sprites, to further reduce the number of individual external resources referenced by a page, but I am leaving that for a future more advanced list of tweaks.

#10 – Use As Few Unique Servers As Practical

For each different server name referenced in your page a lookup has to happen – whether it is available within various caches available to your client, or it has to be loaded from a server, there is a performance penalty involved (obviously worse in the 2nd case).

It is a common technique to use resources hosted on 3rd party servers, like logos of companies, banner ads or even AJAX libraries (see Google’s AJAX Libraries API). The upside to this is that the 3rd party server may be faster or more reliable than your own. Or it may be just that the 3rd party server is the only place the resources is available for legal reasons etc. The downside is that it adds an extra DNS lookup to be able render your page. So be aware of the trade-off and make an informed decision.

Yahoo! talks about the issue of too many DNS lookups here.

Stay tuned for a list of more advanced tweaks coming soon.