Posted by & filed under Accessibility and Usability, Search Engine Optimisation.

Yesterday, I posted about a blog post from Conversion Marketing, listing the 59 things you should be doing but probably aren’t.  I thought it was a great list but could do with a bit of expansion on why you should be doing those 59 things (and how to do them right!). Yesterday, I wrote about the first few in the list.

Today, I’m going to cover a few more of the issues Ian discussed in his post.  First of all, error pages.

Get Your Errors Right!

From time-to-time, every website has an error.  Whether you’ve got a typo in your code, or a user mistypes a URL, or maybe your database server decides that it’s out to lunch – every site has had to deal with such things.

From a user’s point of view, there’s little more irritating that getting an error page.  Even worse, getting an unhelpful error page with technobabble and no real help.

Therefore, it helps to create a useful, on-topic error page to handle different kinds of error.  If a 404 error is encountered, give a helpful, friendly error message inside a corporate themed web page.  If possible, try to link to what the user might have been looking for – if they seemed like they were looking for a product page, show them some product categories.  Show them a search box. In short, do what you can to help them find what they were actually looking for.

The more you help a user who encounters a problem, the less chance there is that they’ll turn round, head out, and buy their red widget from some other website.

Go For Diet HTML!

Yesterday, we mentioned page loading speed.  One of the factors of loading speed is the amount of bulk in the code on a page.  There are two competing factors that can affect this – DNS lookups (Ian doesn’t talk about this though) and JavaScript/CSS code.

Ideally, all JavaScript and CSS code should be in external files. That is, in your HTML code, you only reference the JavaScript or CSS as being in a separate file, you don’t include within the HTML itself.  This reduces the amount of code in the actual HTML page.

However, each time you request a new file from a server, the browser has to go and fetch it, which slows down the rendering of the page. Additionally, if the file is on a different domain, the browser also has to lookup the address of the server to find where it is before it can fetch it, which slows down the process further.

There is a balance to strike clearly. Look-ups and fetches slow the process of displaying a web-page down.  However, once you have downloaded a file, unless the server instructs the browser NOT to cache the file, it will be cached so that next time (within a reasonable time period) it doesn’t need to be downloaded again.  This means that when you view the next page of the same website, if it uses the same JavaScript files, and the same CSS files, they are already downloaded, and the page will render much quicker.

Ideally then, the balance must be to keep as much JavaScript or CSS as possible in just one or a few files that are shared across all pages of a website.  In this way, few look-ups and fetches are required, but the majority of the CSS and JavaScript is download on the first page and cached for later use – the total code downloaded over the space of a single multi-page visit can be dramatically reduced.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>