Why Optimize?

A few minutes of painless website optimization is well worth your time. With a properly designed site, a few simple optimization and compression techniques will result in reduced bandwidth requirements and faster load times. If you want to survive the digg effect, or just make your site more efficient, you owe it to yourself to try all five of the following techniques.

1: GZip compression

GZip compression is a commonly-used method of reducing the total number of bytes transferred to a user. Compression reduces the data transferred at the expense of an increase in CPU load; however, hosting companies charge based on bandwidth, not CPU load. The benefits of reducing file size by compressing the data before sending it far outweighs the delay produced by compressing and decompressing the data.

The compression ratio of gzip will vary based on the data — but it may compress as much as 70% (according to Maximum Compression).

There are several different methods of enabling gzip compression — the following two examples are for apache and PHP users, respectfully.

• Apache’s mod_gzip: Instructions for the average user or the more advanced user.
• PHP: GZip is enabled if ob_start(“ob_gzhandler”); is included as a header (before any text is sent to the client). This method works best if you have a single PHP file that is included in every webpage on your site.

One advantage of mod_gzip is that you can specify what files you want to compress (ie – you aren’t limited to files ending in .php), which is why mod_gzip is the more popular method.

2: Scrap table-based layouts

There is a strong push in the Web 2.0 world to get rid of HTML table-based layouts in favor of CSS-based layouts. The primary reason for this switch is to separate content from presentation, but as an added bonus, it also greatly reduces the total size of your markup. Consider the following two examples:

1. <table style=”border-collapse: collapse; width: 800px;” cellpadding=”0″ cellspacing=”0″> <tr> <td colspan=”3″> [header image] </td> </tr>
2. <div id=”header”>[header image]</div>

Both examples can essentially code for the beginning of the same layout. Obviously the second example will require an external CSS file, but that CSS file will be cached. As a cached file, it will be accessed once per unique hit, whereas an HTML-based layout will require an entire transfer of presentation/layout with each page request. Additionally, the above examples are a small portion of an actual layout — in a practical example, the amount of data reduced is extremely significant with a CSS-based layout.

3: Take advantage of caching

The biggest advantage to CSS layouts is that the bulk of the presentation portion of the code (the CSS file) is, by default, cached by browsers — this provides an extreme reduction in bandwidth.

If you reuse Javascript code or CSS layout, it is almost always to your advantage to include the code as an external link, rather than inserting the code directly into the HTML markup itself. Remember that browsers cache by default — so take advantage of it!

The following code demonstrates how to link a CSS file (two methods) and a Javascript file:

http://www.peterbe.com/plog/blogitem-040406-1/compressor

<style type=”text/css”>

@import url(yourcssfile.css);

</style>

<link rel=”stylesheet” type=”text/css” href=”yourcssfile.css” />

<SCRIPT language=”JavaScript” SRC=”yourjavascriptfile.js”></SCRIPT>

4: Online code optimizers

Online CSS code optimizers do reduce the size of your CSS files, but the primary gain is attained by removing tabs, excess spaces, and new line characters. There are a wealth of different optimizers online, many of which will essentially do the same thing. I’ve found Peterbe.com’s compressor, and I’ve been very happy with it. Keep in mind, however, that there are probably at least one hundred different optimizers online.

The primary criticism of CSS optimization is that it obscures CSS code, and that it has little influence over total bandwidth because it is a cached resource. My recommendation is to keep TWO files — mystyles_readable.css and mystyles.css — which will allow for easy editing and an optimized CSS file. Although the CSS file is cached, if you receive a large number of primarily unique visitors (ie – digg effect), then it will be to your advantage, even though it is a cached file.

Most of the time, developers don’t make frequent changes to their CSS files. Given that it is an infrequently edited file, and the fact that it takes less than a minute to optimize CSS, there is little reason to not optimize.

Whichever optimizer you pick, make sure it doesn’t break your CSS — test the optimized version! Even if your CSS is ‘broken’, it’s often a small change that you can manually do to fix the problem.

If you’re interested in a comparison of popular CSS optimizers, I would recommend checking out CSS Optimization: Make Your Sites Load Faster for Free. You might also be interested in XHTML/HTML or Javascript optimizers — all of which you can find on google.

5: Beware of Server-Side Code Optimization

It might seem odd that I’m encouraging caution for script optimization, but please hear me out first. It is not uncommon for PHP (or other language) gurus to promote ridiculously minute methods of optimize code and compiles times. Typically, you can optimize your code to an almost zero second compile time, and it probably still won’t affect your load time in a significant way. Why? If you had a transfer speed of 150 kbps (19 KBps), it would take 1.05 seconds to transfer 20KB of data. If you optimized your code by 5KB, it would reduce your load time to 0.79 seconds (a 25% decrease). My typical compile time is about 0.005 seconds — which is 0.6% of 0.79 seconds. A 0.6% decrease in load time is absolutely insignificant.

In other words, the total amount of gain from PHP/script optimization isn’t worth your time at all. It’s good to have good coding practices and be efficient, but it’s a waste of time to encourage extreme, picky optimization techniques.

With all of this said, however, I do need to include a caveat. There are some instances where optimization of code is necessary (ie – a CPU-intensive script) or a database-intensive script. In these cases, your load times are probably more hefty than 0.005 seconds, meaning that you might be able to benefit by optimizing your database transactions or code methods.

Most importantly of all, keep in mind that web hosting companies typically limit users by bandwidth, not CPU usage. It’s much more effective to focus on reducing the total amount of data transferred to users, rather than CPU optimizations.

Final Thoughts

Hopefully this article will encourage you to spend an hour and optimize your website — it will be an hour well spent. Below are a few final misconceptions that need to be addressed:

• 10KB of optimization is insignificant – Even small amounts of data optimization are significant. You might not cut your bandwidth bill in half, but it will make a dent, especially over time. At the very least you’ll help out your load times. A reduction of 10KB for 100,000 hits translates to 1GB of saved bandwidth.
• CSS is cached and only accessed once — it’s a waste of time to optimize it. – Optimized CSS will make a huge difference if you have a large number of unique, one-hit visitors (ie – like a digg effect). It’s worth the two minutes to optimize it.
• Optimization of CSS makes it uneditable – Make two copies — it’s not that big of a pain, especially if you don’t make frequent updates to your CSS.
• Optimization isn’t worth my time – These painless optimizations shouldn’t take more than a half hour — TOPS. It is worth your time, and will save your visitors’ time too!
• CSS optimizers are shit -Yes and no. The best way to optimize your code is to write it correctly the first time. CSS optimizers excel at stripping white-space characters from your CSS, which dramatically reduces the size of your CSS (especially in large files).