9 Tips to Slim Down Your Website

The New Year is here and people are hard at work on those resolutions to slim down their budgets, their waistlines… but what about their websites?

Back in the days of dial-up and 14.4k modems, a page that was more than 100kb would be considered extremely bloated. Now things have changed; broadband is evermore ubiquitous and so is the demand for internet candy like Flash and Javascript. And just like the American waistline, the size of the average website has been expanding.

As busy website owners, it’s easy to get lazy and let our pages start putting on a little weight, so here are 9 tips for getting that website back in shape and able to fit into those skinny jeans again.

Reduce HTTP Requests

As a web page is loads into the browser, the HTML is parsed progressively. When a request for an asset is reached, the browser attempts to download it. Each of these assets (external files, images, Flash, etc.) is an HTTP Request with it’s own communication latency. Standard browsers are only configured to handle two HTTP Requests in parallel, per domain.

You can use a free tool like this one from Website Optimization to check how many HTTP Requests your web page makes. It will also give you the estimated download times for different web connections, and a few other things to help you decide what you need to trim.

Minimize HTTP requests by combining external scripts into a single file. Do the same with CSS files, merge them into a single stylesheet. For images, use CSS Sprites to reduce the number image requests. Using sprites has the added benefit of reducing overall download size as well.

Optimize the HTML DOM

Hopefully optimizing the DOM was done at the development stages of the site. Take a look at all the HTML tags in your website… are you looking at nested DIV and TABLE hell?

Parsing the DOM is the most processor intensive task when loading a web page. So the more DOM elements(HTML tags) the browser needs to parse through, the longer the process of loading the page is going to take. Ask yourself, do you really need all those divs for that flashy navigation? Are nested tables really the only way you can achieve that particular website design?

Watch out if your website was created with a WYSIWYG editor or rendered out by other software that writes the HTML for you. The code created by some of these programs is notoriously bloated. Some are better than others, but there is no substitute for a clever human with mad HTML skillz.

A bloated DOM will also slow your page when Javascript is used to modify or access the DOM, as is the case with DHTML and AJAX applications. Simply put, the more HTML elements you have, the longer DOM access takes.

Optimize the CSS

After the browser finishes parsing, it renders the page to your screen. As it does this, it renders the CSS in parallel. Speed up rendering time by consolidating and eliminating CSS rules.

Use a tool like Firebug to help you track down and eliminate any redundant CSS. Maximize the inheritance behaviors of CSS and trim any unnecessary rules that could be handled with inheritance instead.

Optimize your Javascript

Javascript is unique among other programming languages in that the source code is downloaded, parsed and executed with every pageload. So there is a performance cost for every line of code you write that doesn’t exist in other languages.

The obvious solution, write less code. Especially be on the lookout for Javascript bloated with third party scripts and script libraries. Lightbox and Scriptaculous for example. When you include these scripts in your HTML document, it’s not likely you will use each and every line of code. Delete any Javascript statements and functions that aren’t being called.

If you really want to geek out on optimizing Javascript, here is a great talk by Joseph Smarr: High-performance Javascript: Why Everything You’ve Been Taught is Wrong.

Externalize Javascript and CSS

Externalizing your Javascript and CSS files allows them to be cached by the browser. There is a trade-off to consider however because this means additional HTTP Requests. Once the these files are in the cache however, subsequent pages will be much faster. If the typical user behavior for your site is to visit multiple pages, the overhead is probably worth it. Verify your user behavior with a metrics tool like Google Analytics.

LINK instead of @import CSS

Just as important as reducing the actual download time of a web page is reducing the perceived download time of a web page. Users are much happier waiting 10 seconds for a page to download if they can see the page is doing stuff.

@import gained popularity as one of the hacks in a web designers bag of tricks for hiding CSS from legacy browsers. Thankfully, with major sites beginning to drop support of these older browsers, we can all follow in suit and do the same. At this point the drawbacks for @import outweigh the benefits.

Using LINK instead of @import does two things: allows for progressive rendering, thus lowering a page’s perceived download time, and speeds up the rendering of the DOM.

Already mentioned is that CSS renders in parallel to the rendering of the DOM. But progressive rendering only occurs up until the point of where a CSS request occurs and then rendering starts over from the top. With a slow internet connection you can see this as an unstyled page that loads, then is quickly replaced by the CSS styled content.

For this reason it’s good practice to not only LINK to your stylesheet, but to place it as early in the HEAD section of the HTML document as possible.

It’s important to note that IE treats @import like a LINK that occurs at the bottom of the page, even if @import appears in the HEAD section. Another reason IE is the bane of existence for all web designers.

If you absolutely can’t get away from using @import, here is a great BlueRobot article on the FOUC problem.

Place scripts as low as possible

Scripts are problematic to the page load process for a couple reasons. First, they block parallel downloads, meaning that while a script is downloading, nothing else can download. Scripts also prevent any elements below them in the DOM from rendering while they are downloading and parsing.

Sometimes it isn’t possible, but in many cases a script can be placed just before the part of the DOM where they are required. Doing so allows at least part of the page to render, giving the user the impression that the page is doing something. Again, reducing perceived download time is as important if not more so than reducing actual download time.

Set the Cache Controls

Most web designers are probably happy to let browser defaults handle caching, or may think that because their website has dynamic content they don’t need to bother with caching. But, why not take advantage of the built in capabilities of the browser and network to create a faster experience for your most valuable visitors? Repeat visitors and conversions.

The simplest thing you can do is set the cache using a META tag that looks like this.

<META HTTP-EQUIV="expires" CONTENT="Wed, 26 Feb 2011 08:21:57 GMT">

Set the expires date to some far off date to be sure that caching is utilized.

It’s probably not a good idea to rely solely on this method however as it has the drawback of being ignored in many instances. For more precise control of caching, set an Expires or Cache-Control HTTP header. This involves messing your server a bit, but here is a great caching tutorial to help you get it done.

Avoid Dynamic Properties (CSS expressions)

Finally, where the previous tips have been centered on the trimming the page loading process, this tip is about trimming runtime performance.

CSS expressions are a proprietary property in IE 5-7 that allow you to assign a Javascript expression to a CSS property. It evolved as another hack in the bag of tricks to make IE work like a normal browser, for instance by faking support for the min-width CSS property. Did I mention IE is that bane of existence for all web designers?

Basically this hack was a short way to get CSS to respond to a browser event. The problem is that the Javascript expression is called on every browser event, causing it to be evaluated thousands of times during normal page interaction.

Rightly so, Microsoft has dropped support for CSS expressions with IE 8. The better choice is to use proper event handlers. Here is a great article further exploring the problem with CSS expressions.

There you go, 9 tips to trim your website. Feel the burn while you’re making these changes, and remember, no pain, no gain!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.