Website Optimisation Measures

1. Move Scripts to the Bottom of the Body
2. Ensure the Site Works With JavaScript Off
3. Provide Proper Fallbacks for Flash Content
4. Clean Up the Head
5. Styleheets First
6. Add Height & Width on <img> Tags
7. Reduce HTTP-Requests
8. Imitate Background Images With Colours
9. GZip What You Can
10. Compact Images
11. Write / Output Cleanly Indented HTML
12. Drop Internet Explorer 6 Support
13. Do Not Block Browsers for ‘Compatibility’

Jens Mieret publishes a list of general tips on optimising websites for in his opinion speed, simplicity, accessibility and user friendliness.

This presents a lot of valuable information in a very simple way, and therefore as a good idea, it should be stolen borrowed.

Here are, in my opinion, a number of key optimisation tips for your website:

Move Scripts to the Bottom of the Body

When the page loading hits a script tag—everything stops. Scripts have the right of way. A script can’t change the DOM until the HTML has loaded, so more important things like stylesheets are held up loading a script file that’s no actual use until the HTML has finished loading! Get your HTML structure and CSS to the user as quick as you can. The browser will be able to render the page much quicker and then scripts can be loaded, rather than leaving a blank page for the user stare at whilst they wait for scripts to download.

	⋮
	<script type="text/javascript" src="js/main.js"></script>
</body>

Moving the script tags to just before the </body> tag alone will make your website noticeably snappier! However, doing this brings added responsibility. Because the page will render before scripts have initialised, particularly quick clickers will be able to interact with your site before your Javascript is ready! This brings us on to the next tip:

Ensure the Site Works With JavaScript Off

I cannot stress this enough, and how much it makes a positive difference—even when Javascript is enabled! Firstly, more and more people are now browsing with Javascript switched off by default thanks to the security benefits and flexibility provided by NoScript. It increases browsing speed, frees up bandwidth, increases privacy by blocking all sorts of third party scripts, and helps mitigate XSS attacks.

Just as your HTML and CSS should be separate, so should your Javascript. If you code your site to work without AJAX first, all your server-side events are done, you can just veneer the site with event-bound Javascript to replace REST events with AJAX ones based on the URLs already in the HTML. Google doesn’t run Javascript, so it still needs to get around!

Having the site work without Javascript increases user trust, increases the platforms you support without any extra work, increases SEO, reduces maintenance and best of all, allows people to click through your site at super speed when they know where they want to go.

Provide Proper Fallbacks for Flash Content

Assuming everybody has Flash doesn’t cut the mustard any more, there are more diverse platforms in use—that don’t support Flash—than there were years ago; iPhone for one. People are blocking Flash with AdBlock, NoScript and FlashBlock.

If people can’t see your content then you lose out. There are almost always better ways of presenting content to users without using Flash, and if you have to use Flash then don’t provide a lame cop-out excuse like “Install Flash” as the only fallback message. Describe what the actual content is, why you can’t view it and provide it in an alternative format (such as an image).

This especially applies to videos. I don’t have Flash installed, telling me to install Flash is just annoying, when there’s plenty of other ways you can give me the content. How about falling back to a QuickTime embed? Why don’t you provide a download link for the video file in the fallback text, huh? Even better than that, modern browsers support HTML5 <video> that requires no plugin at all—use that instead!

If you are embedding video you should be using Video for Everybody—a comprehensive solution that uses native HTML5 <video> in browsers that support it, then falls back to Flash for other browsers, then QuickTime if Flash is not installed (e.g. iPhone) and if all else fails shows a fallback message allowing people to download the video.

There is no reason anybody should be staring at a broken plugin icon.

Clean Up the Head

You can really fill the head element with junk if you want to.

Don’t use a favicon link:

<link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" />

/favicon.ico is assumed by default, putting this in the head is just extraneous bytes. If you need to store your favicon somewhere else (why? No why? No really, why?) then just mod_rewrite it to /favicon.ico to avoid 404s and wasted HTTP-requests from browsers / aggregators assuming the default

Don’t use keywords / description:

All SEO is bunk. Paying for SEO ‘specialists’ to wave their magic wand over your site is no more material than a pair of emperor’s clothes. If you have clean, tidy, semantic markup, have avoided text in images and have a sensible and clear system of navigation that doesn’t depend on Javascript, then Google will have no problem understanding your site.

To that end, I have found that filling the head full of keywords is a waste of time. Camen Design appears on Google without any issue. Seriously, drop the voodoo and witch doctors, it’s not the ’90s anymore

Camen Design’s head element looks like this:

<head>
	<title>camen design</title>
	<link rel="stylesheet" type="text/css" href="/design/" />
	<link rel="alternate" type="application/rss+xml" href="/rss" title="all content" />
</head>

Quite refreshing.

Styleheets First

To give a feel of snappiness, you want to get the structure rendered as soon as possible, ideally before any images have even loaded. It’s critical therefore to get the stylesheet to the user as soon as possible. Any HTTP-requests before the CSS sheet are wasting valuable time!

Therefore, don’t place any <link> or script elements above the stylesheet in the HTML head. If you really want to save a few milliseconds more for dial-up users, put the stylesheet above the <title>!

Add Height & Width on <img> Tags

One thing that really annoys me is when you view a site with a lot of images and as you’re reading, the page is jumping all over the place as the images load. If you define the correct height and width attributes on image tags, then the page will render faster (less reflows) as well as allowing your users to get on with reading without disturbance whilst the images load.

If your HTML is outputted by a CMS and the height and width attributes are not added, then either modify the code to look up the image size (getimagesize in PHP), or hound the developers until they do.

Reduce HTTP-Requests

Bandwidth is not the problem when it comes to speed, even on dial-up. The browser can only do a limited number of simultaneous HTTP requests (usually 2). That is the bottleneck that you are fighting against.

By whittling the number of HTTP-requests down to an absolute minimum, you will make the time between one page and the next almost instantaneous.

Think of it this way: in a worst case scenario, a single HTTP-request could take up to a second alone if the server is under heavy load or if the bandwidth is already saturated.

Combine print stylesheet with main stylesheet:

Even if a stylesheet in the head uses media="print" the browser will still download it regardless. When printing or in print-preview, nothing new can be downloaded, it has to already be in cache. Therefore having a print link in the HTML head is wasting an HTTP-request!

If you include the CSS print declarations in an @media block in the main stylesheet then the same amount of data is being downloaded, but the number of HTTP-requests is reduced, allowing the browser to be busy downloading something else. If your CSS sheet is gzipped then the size of the combined stylesheet will be less than two separate sheets

Use CSS sprite sheets:

Essential, basically

Combine Javascript files:

Again, being brutal with HTTP-requests, merge JS files into one when publishing.

I once wrote a build-system that ‘compiled’ a web-app by searching through Javascript files and finding instances of a function called $import (which just loaded in the named Javascript file), and replaced the function call with the contents of that file.

Use the YUI Compressor to compress the combined file by removing extraneous whitespace and comments &c.

To give you an idea of the savings that’s possible, I managed to compress 319 KB of JavaScript in 15 files, into 141 KB in just 2 (library / app).

I used this same method to replace @import statements in CSS sheets with the imported sheet to combine multiple sheets into one.

If you’re writing swathes of code that have to be spread across many files, it’s well worth investing time in scripting a decent build system to ‘compile’ the site before uploading to a live environment

Imitate Background Images With Colours

An effect that adds to the perception of speed is to use the CSS to closely represent the page’s design without images. If you view the page without images, is the page layout still communicated via the same colours?

For everything with a background image, set a matching background-colour to act as a ‘placeholder’ for the image, and where possible, design your HTML structure, such that background colours can be used to represent the layout of the site when images are not present.

On Camen Design, background images are used for gradients and an approximate background colour is provided. CSS borders do the rest. On Tripology, without images, everything just turns a light shade of blue, and no structure is communicated.

Simply put—the website should look almost as good without images, as it should with them.

GZip What You Can

Save bandwidth for both you and the user by compressing text-based content such as HTML, CSS and Javascript files.

On this website, the publishing script saves each web-page as a zip-compressed file, (using PHP’s gzencode function) with a “.xhtml” extension. The CSS file is compressed similarly into a “.csz” file, and the RSS files as “.rsz”. Apache’s mod_rewrite is then used to serve the correct content-encoding header to the browser.

Here’s an example of some ‘.htaccess’ commands that could be used:

AddType text/html .htmz
AddType text/css .csz
AddType application/rss+xml .rsz
AddEncoding gzip .htmz .csz .rsz

If you don’t want to have to compress your files every time you publish, you can get the server to compress files during output. Bear in mind though that this will increase CPU usage on the server and might not be ideal under heavy traffic; it’s always better to pre-compress your files.

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/css text/javascript text/plain

Compact Images

All imaging software—and especially Adobe Photoshop—output inefficient JPEG and PNG files that waste sometimes even hundreds of kilobytes in needless information. There are a number of tools out there that can losslessly reduce the file size. I’ve seen as much as 1 MB or more saved from a gallery of thumbnails.

Yahoo have put together a website that combines these tools into one at smush.it. If however you want to do things locally for scripting purposes, the individual programs they’re using can be found on the bottom of their FAQ page. I use a simple Dashboard widget called PNGPong.

Write / Output Cleanly Indented HTML

The HTML on this site, in fact, every site I’ve written—CMS or not—has had clean HTML, nicely indented and human-readable. Whilst not necessary for all kinds of site, this particular site is very much designed to encourage reading of the source.

There are other benefits though of outputting clean HTML. It greatly helps with debugging HTML / CSS issues, but really the benefits are not the result, it’s the fact that it takes a keen eye, patience and a lot of love to get a big, heavy 10’000+ line CMS to output perfect HTML and that careful consideration whilst achieving that will ensure that you’ve gone over your codebase with a fine-toothed comb and probably end up fixing and improving tons more than just HTML.

Clean HTML makes for a clean codebase too.

Drop Internet Explorer 6 Support

A number of websites, including Apple’s Mobile Me have already taken the lead in dropping support for Internet Explorer 6. The trend is unavoidable.

Think of it this way:—given that there are more people using Firefox 3 (which passes Acid 2 and supports <canvas>) than IE6, the only users of IE6 who can’t upgrade to a newer version or a better browser entirely are Win9X users and frozen corporate desktops. Anybody at home using IE6 is doing so out of a lack of knowledge that they should install updates, or simply use a better browser.

You are working your arse off, wasting large amounts of time banging your head against IE6 bugs, for a group of people who only need to be shown how to install a better browser. It’s like spending tons of money and effort in healthcare dealing with the effects of a disease, when all the time you have the cure in your hand and just need to give it to the people, or tell them where to get it.

The lack of + and > selectors mean that IE6 won’t go near an element without a class or ID in sight. This is insane to be writing code this way. This website has no IDs, no classes and no DIVs to show that crazy tag-soup is not necessary.

You will be able to produce far greater things if you throw away the millstone around your neck that is IE6 and start learning everything that’s been possible for the last five years.

Do Not Block Browsers for ‘Compatibility’

This is going to be quite controversial coming from me when I’ve just said to you above to drop IE6 support and even my own site does not display correctly with Internet Explorer, but don’t bring up a splash screen that outright blocks Internet Explorer (any version), or any browser for that matter from accessing the content of your site—no matter how pretty said screen looks.

If you don’t like IE6, don’t waste your time writing messages (or drawing pictures) for it (you haven’t got Stockholm syndrome have you?). Would you outright block Lynx users, or Dillo users or any user of an alternative browser that isn’t ‘compatible’ with your site? Why attack only IE6 when the list of browsers that will be compatible with your site is smaller than the list that are not?

The fact your site looks wrong is besides the point, somebody’s life could depend on being able to access the content on your site when all they’ve got is IE6 because of whatever reason. I’ve had to access stuff on my site using IE when on other people’s computers or at a public library. You yourself should know that all that matters is the raw text in those kinds of desperate situations, not how it looks.

Completely blocking any browser—IE6 included—goes against the very nature of HTML and CSS, formats that are designed to be universally accessible and still be readable with even the littlest of support.

If you are really concerned about how your website looks on an eight year old browser (would you honestly still use and support Netscape 6?), then place a message at the top of the page telling the user to upgrade their browser, but don’t hide the content, the text still matters to the user.

If the layout and content is totally broken by IE6’s partial CSS support, then consider using “Universal Internet Explorer CSS”, a stylesheet that provides a back to basics design for IE6 that can communicate the text clearly and forego your complex layout completely, allowing you to focus support on better browsers.

Any suggestions or comments, send them my way; hit the name link below.