A Faster Connection ≠ A Faster Website
I am what you might call a man obsessed. I'm obsessed with speed; especially speed online.
In our modern world of high-speed, broadband, ultra-quick, super-fast Internet connections you might think that speed isn't a concern anymore; we have our content-rich websites and the speed at which to download them.
Interestingly though, the faster the connection gets, the less patience we seem to have waiting for a page to load. For businesses this can have a detrimental effect. Lower conversion rates. People who abandon your site for its perceived slowness doesn't make them customers.
The keys to making the content come to us faster in my opinion are as follows:
Compression
At it's most basic, compression can be achieved by enabling it on the server. This is pretty straight forward on Apache but much more involved on IIS 6. I'd like to cover how to do this in a future entry.
Just turning this on, can see speed gains in my experience of 200 to 300%, of course that's just a number and mileage may vary but let's say in most cases the load time for a site is cut in half. Minifying content like CSS and JS files will also help, as this process removes elements such as whitespace and line breaks that make it human-readable but a computer doesn't need in order to process it.
Making Fewer Connections
The benefits of making fewer client connections to serve content should be fairly obvious but doing so gets the client the content faster which means more conversion and you can do the math on that.
Serving Content From Multiple Subdomains
Parallelize the download of your content. To do this put images on their own subdomain, put scripts and CSS on its own subdomain. This is my preference as it means my browser can open 3 connections to grab content which means the browser doesn't have to wait. Three connections to the server is better than one queueing up all that stuff people are waiting to look at. If it works for FTP, it can work for your website too.
One thing to keep in mind, scripts block. This means that the rest of your page will not render until the scripts you've just included are completely downloaded and evaluated. For this reason put your scripts at the bottom of your page just before the closing </body> tag.
Caching
How often does your logo actually change? Make sure it gets cached. Cached content is hands down faster than getting it over the wire. If your vistors are always downloading the same elements with each page they visit they have have to wait. Luckily this is easy to do. Set an Expires header on your content. Set it a year in the future. Done. Visitor visits site for the first time, gets logo image, and doesn't download it again for 365 days. Now I know what you might think, what happens if we do change the logo? Simple. If the Last-Modified header of your logo image is newer than the one in the visitor cache it caches the newer image for another 365 days.
Combining Content
Going along with the previous points, combining CSS files or JS files together into one will limit the number of connections we make, require us to cache only one of each file, with compression we can make these combined files very lean.
As an example this is how I combine CSS files in ColdFusion:
<link href="/styles/site.cfm" media="screen" rel="stylesheet" type="text/css" />
(Yes that is a CFM file)
In /styles/site.cfm:
<cfheader name="Content-type" value="text/css">
<cfinclude template="file1.css">
<cfinclude template="file2.css">
<cfinclude template="file3.css">
The server combines all the files together and serves only one file, which the browser sees as CSS. One HTTP connect versus three.
This can easily be achieved in your server-side language of choice. And can be done with any of text content, JS, etc.
Another way to limit the connections and combine files is to use CSS sprites. This is especially useful for graphic content that rarely if ever changes. Things like your logo, UX elements, navigation, etc. One file, many graphics, one connection, one cache item.
Testing
The biggest thing to all of this of course is testing. What may seem fast to you might not be so for someone else, and that someone else may have been a potential conversion.
I use many tools to test the speeds at which my pages load. Some of the ones I can't live without include:
To test the speed of a site at 28.8kbps, 56kbps, ISDN speeds (and yes people still do connect at those speeds) never be without Sloppy. This Java application will allow you connect to your content at these speeds. What is great on a ultra-sleek, blazing connection might not be so hot at dial-up rates.
Take this advice with as much salt as you like. This is what we do and it works for us.
In our modern world of high-speed, broadband, ultra-quick, super-fast Internet connections you might think that speed isn't a concern anymore; we have our content-rich websites and the speed at which to download them.
Interestingly though, the faster the connection gets, the less patience we seem to have waiting for a page to load. For businesses this can have a detrimental effect. Lower conversion rates. People who abandon your site for its perceived slowness doesn't make them customers.
The keys to making the content come to us faster in my opinion are as follows:
- Compression
- Making fewer connections
- Serving content from multiple subdomains
- Caching
- Combining content
- TESTING!
Compression
At it's most basic, compression can be achieved by enabling it on the server. This is pretty straight forward on Apache but much more involved on IIS 6. I'd like to cover how to do this in a future entry.
Just turning this on, can see speed gains in my experience of 200 to 300%, of course that's just a number and mileage may vary but let's say in most cases the load time for a site is cut in half. Minifying content like CSS and JS files will also help, as this process removes elements such as whitespace and line breaks that make it human-readable but a computer doesn't need in order to process it.
Making Fewer Connections
The benefits of making fewer client connections to serve content should be fairly obvious but doing so gets the client the content faster which means more conversion and you can do the math on that.
Serving Content From Multiple Subdomains
Parallelize the download of your content. To do this put images on their own subdomain, put scripts and CSS on its own subdomain. This is my preference as it means my browser can open 3 connections to grab content which means the browser doesn't have to wait. Three connections to the server is better than one queueing up all that stuff people are waiting to look at. If it works for FTP, it can work for your website too.
One thing to keep in mind, scripts block. This means that the rest of your page will not render until the scripts you've just included are completely downloaded and evaluated. For this reason put your scripts at the bottom of your page just before the closing </body> tag.
Caching
How often does your logo actually change? Make sure it gets cached. Cached content is hands down faster than getting it over the wire. If your vistors are always downloading the same elements with each page they visit they have have to wait. Luckily this is easy to do. Set an Expires header on your content. Set it a year in the future. Done. Visitor visits site for the first time, gets logo image, and doesn't download it again for 365 days. Now I know what you might think, what happens if we do change the logo? Simple. If the Last-Modified header of your logo image is newer than the one in the visitor cache it caches the newer image for another 365 days.
Combining Content
Going along with the previous points, combining CSS files or JS files together into one will limit the number of connections we make, require us to cache only one of each file, with compression we can make these combined files very lean.
As an example this is how I combine CSS files in ColdFusion:
<link href="/styles/site.cfm" media="screen" rel="stylesheet" type="text/css" />
(Yes that is a CFM file)
In /styles/site.cfm:
<cfheader name="Content-type" value="text/css">
<cfinclude template="file1.css">
<cfinclude template="file2.css">
<cfinclude template="file3.css">
The server combines all the files together and serves only one file, which the browser sees as CSS. One HTTP connect versus three.
This can easily be achieved in your server-side language of choice. And can be done with any of text content, JS, etc.
Another way to limit the connections and combine files is to use CSS sprites. This is especially useful for graphic content that rarely if ever changes. Things like your logo, UX elements, navigation, etc. One file, many graphics, one connection, one cache item.
Testing
The biggest thing to all of this of course is testing. What may seem fast to you might not be so for someone else, and that someone else may have been a potential conversion.
I use many tools to test the speeds at which my pages load. Some of the ones I can't live without include:
To test the speed of a site at 28.8kbps, 56kbps, ISDN speeds (and yes people still do connect at those speeds) never be without Sloppy. This Java application will allow you connect to your content at these speeds. What is great on a ultra-sleek, blazing connection might not be so hot at dial-up rates.
Take this advice with as much salt as you like. This is what we do and it works for us.
posted by Adam Doherty
at
11:37 AM
1 Comments :
Whats your take on tools that can automate much of the good practice you mention - we're trialling one at the moment (aptimize) and are v happy with the results we are seeing - your opinion on website accelerators would be valuable.
Agree with you about Sloppy, fantastic tool.
Post a Comment