One thing worth thinking about in 2008, is fixing the DNS entry to your website. Most here are probably set up just fine, but here’s one of the most common problems we see:

Go to a website – eg, http://www.marketsafeuk.com and it should all work fine.

But take out the www and go to http://marketsafeuk.com and it doesn’t.  You just get a time out as the DNS fails to resolve the request.

This happens on a remarkable number of sites, even those belonging to some web designers. And it’s poor because a lot of users have got used to not typing the www subdomain to many addresses. They expect the null subdomain to point to the normal website. How many customers would Amazon miss out on if going to amazon.co.uk didn’t work? Lots….

So – if your site experiences this problem go into your domain’s control panel and set up a new A record where the subdomain is left uncompleted. The ip address should be the same as your usual one. Most control panels should allow this.

Your webserver, in most cases, will be set up by default to serve a blank subdomain the same way as the www one. If not, you may need to talk to your hosts about resolving this.

Create a “.htaccess” file in the folder you want to be cached and add the following to it.

# Cache files for a week.
<IfModule mod_headers.c>
<IfModule mod_expires.c>
<FilesMatch ".(jpg|jpeg|png|gif|swf|css|js)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>
</IfModule>
</IfModule>


This will have the effect of caching your site for a week. The number 604800 refers to the number of seconds in a week you should also see the file types mentioned in the line above. Change them as you see fit.

You will need mod_headers and mod_expires enabled in your apache htpd.conf for this to work, but with the ifmodule statements in there there should be no problem if they aren’t installed. If it wasn’t for the two ifmodule statements your site would be dumped to a 500 server error if it couldn’t find them.

To check the expiration times I find the easiest way is to load the page in Firefox, right click somewhere and hit “View page info” then go to the media tab. You will see date and time for the expected expiry of the image files on your site.

We’ve had some clients recently who’ve been burned by other web designers and their hosts. At first we wondered how… our own uptime so far this year, removing planned outages, has been 99.966% – ie, we had three hours downtime on a Sunday morning due to a routing problem at our hosts.

It’s unusual to have even that much downtime, but it can happen. Machines can break, drives fail, and availability isn’t always easy to guarantee.

But if it’s happening a lot, or you run a mission critical website, then this can be a major issue. Imagine spending £200k on a national advertising campaign, and the day it goes live the web server’s having a nap. The developers are on an office day out, and the hosts put you on hold when you call.

In web hosting there’s an awful lot of people making false economies – they run major companies on cheap, consumer level hosting that costs perhaps £15 a month… or less! This may be fine if the site isn’t generally that busy, but any spike in traffic and the machine won’t have the resources to keep the site going. Not only that, but because you’re sharing a box with possibly thousands of other websites, the poor server may well be over-stuffed and overworked anyway.

There’s a few steps to consider when dealing with this:

1. Properly assess risks. If you could lose £100,000 of business when your website fails, it’s obviously wise to spend more than a few hundred pounds a year on it. But there’s no point spending £10k a month on a site that generates very little trade, just for the sake of avoiding ten minutes of downtime.
2. Make sure what goes on the server is only ever fully tested code written by people you can trust. Our own web consultancy, Interconnect IT goes to great lengths to make sure the code supplied is reliable.
3. Consider bringing in house code-reviews and creating your own testing requirements.
4. Load test your server with the predicted maximum level of traffic. If you don’t, how do you know its adequate? And you can’t predict the load just on raw visitor numbers either – some websites are much more demanding on server resources than others.
5. Make sure the site is suitably protected from attacks by hackers and even malevolent rivals.

Ultimately any website is a reflection of your business – if it’s cheap and unreliable, it’ll say that to your potential clients.