Having a fast website isn’t just to win you bragging rights.

Speed matters online!

The evidence from large online retailers like Amazon clearly shows this. But this doesn’t just apply to only billion dollar mega companies like Amazon. It applies to anyone who is serious about getting more traffic to their website and then converting those visitors into paying customers, whether via online payment, direct through the site or offline.

Speed matters for two critical reasons.

First up is Google. They have said often enough that website load speed is a ranking factor. Enough said. If you genuinely care about your website you need to pay attention to Google.

This is what Google has to say:

Admittedly, it’s not the only factor.

If you prioritise speed over great content, an engaging blog and serious customer service, you’re not going to get the best results.

Second, visitors love fast websites. If you are honest, you know that yourself. How many times have you given up on a website that takes forever to load?

Plenty, I bet.

Here are a couple of statistics that reveal why website loading time is important for users -

• 51 percent of online buyers in the U.S. affirmed if a site is too slow they won’t complete a purchase. [Radware]
• 47 percent of online users expect a website to load within two seconds. [Aykira]
• During peak traffic times, 75 percent consumers are eager to visit competitors’ sites rather than dealing with a slow loading web page. [Search Engine Journal]
• A one second delay can lead to a loss of 7% sales. [The Strange Loop]

But, how do you make your website load faster?

In addition to using super fast SSD Hosting, you should step into Yahoo and their Developer Network that has kindly thought over all of this through and come up with 35 Best Practices for Speeding Up Your Website.

The only problem is that they aren’t written for the layman, which is OK because the layman isn’t usually developing websites. That’s for the developers. But often the business owner or the entrepreneur may understand the business benefits of a faster website, but not how to achieve it.

So we’ll look at each of the 35 rules or best practices, and translate them into good old plain English for those of us who are not developers.

Rule No. 1: Make Fewer HTTP Requests

When your computer (via your browser) connects to a website, it has a conversation with the web server that hosts the website using Hypertext Transfer Protocol (the HTTP you may be familiar with).

It goes something like this:

Your computer: Give me the home page file.

The web server: Here’s the home page file.

The trouble is that the homepage file may be quite large and that’s exactly what this rule applies to. Things like images or scripts slow things down.

Aside from having a really plain website with minimal design and plain text, there are other ways to address this issue. You can combine scripts and style sheets for example, starting with your home page. There are techniques that any decent designer can use such as CSS Sprites (CSS = Cascading Style Sheets) or image maps. These group together backgrounds and images to reduce the number of http requests.

This is definitely a quick win.

Rule No. 2: Use a Content Delivery Network (CDN)

Your website will appear faster to your visitors if they are closer to your web server from a network perspective and usually this will mean geographically closer. If you’re a local/national business, you may be interested in traffic only from your own state/country. In this case, this is not such an important issue if you host your files in your country.

But if you run a large eCommerce website, you may be selling to customers across an entire continent or across the globe and distance does matter.

In the latter case, it would make sense to have your files closer to your customers. A Content Delivery Network (CDN) allows you to achieve that. A CDN is a service that places servers between the person browsing and your website. It stores (caches) locally so that your website is presented much faster.

Therefore, if your main website is hosted in the UK and someone from Australia views it, the copy they view will be the one closest to them (remember, this doesn’t necessarily mean geographically close, but close in terms of the network).

An example of a CDN that is affordable for many small businesses is Cloudflare.

Rule No. 3: Add Expires or Cache-Control Header

When someone visits your website, their browser can store content like images, scripts and anything else that is unlikely to change during their visiting span. If this didn’t occur each time they went to a new page they would have to start the whole process over again for certain content that they have already viewed, such as your company logo.

This can be controlled by the use of a) Cache Control Headers which switches on the cache control and sets the main parameters and b) Expires Header which determines the point in the future when the data should no longer be considered valid. This can be set years into the future.

So you just need to check that these are activated to save your client’s browser from having to repeatedly download content that appears from page to page.

It will also save your bandwidth too!

Rule No. 4: Gzip Components

OK. Remember the conversation in Rule No. 1 between the browser and the server asking for the file. If the file is too big, this will have a negative impact.

To address this, you can zip your website files too in the same way you zip large files you want to send by email. Gzip is just a way to compress the files so that instead of sending 200KB of data, for example, it can be compressed to say 20KB, passed from the server to the browser and then re-opened.

Nice!

Rule No. 5: Put Stylesheets at Top

A stylesheet is a way of identifying the fonts and various elements used in a web page or website to ensure a consistent style. Rather than specifying the styles on the fly throughout the website, a more elegant way is to specify them in a stylesheet template.

This rule states that your website’s stylesheets should go at the top. This way they are accessed first and therefore they’ll start to display the content and the style of the page before other elements like scripts are actioned. To give an analogy, it is standard practice when drafting a contract to include any terms that are frequently referred to throughout the contract (eg: The Customer, The Supplier, The Service, etc.) in the “Definitions” section at the start of the contract to avoid having to repeat them in full throughout the contract.

It’s pretty much the same here.

The result of this rule though is that the visitor starts to see the page quickly rather than staring at a blank screen.

Rule No. 6: Put Scripts at Bottom

This is the converse of Rule No. 5. By putting scripts lower down the page, they are referenced once the visual aspects have been delivered first. It results in a better browsing experience for the user.

Rule No. 7: Avoid CSS Expressions

CSS Expressions were used to allow dynamic functionality in web pages. But this rule is to some extent redundant because CSS Expressions are no longer supported by any major browsers.

Rule No. 8: Make JavaScript & CSS External

This is a balancing act. JavaScripts add functionality while CSS defines the look of the page. So, both of them are needed for most websites.

There are two main ways of accessing them:

i) Inline (i.e. within the html code)
ii) External (i.e. in external files cached/stored by the browser, eg: Firefox)

Each has its own advantages and disadvantages, in terms of speed. With inline (option i), you make less http requests, thus respecting rule no.1, but at the expense of making the html code heavier.

With External (option ii), it is the opposite – smaller html file size, more http requests.

To some extent, this is a grey area and Yahoo admits as much in their rules. But the caveat is that it depends on behaviour of the visitor. Are they staying on your site, visiting many pages and therefore accessing the same style sheets and CSS? If so, External should be opted for.

Overall though, it is considered that nowadays External JavaScript and CSS is the way to go.

Rule No. 9: Reduce DNS Lookups

DNS stands for Domain Name System. Computers recognize each other by their unique IP addresses and the DNS matches these IP addresses to their physical location.

When you are browsing the web and you want to go to a new website, your browser needs to find out the correct IP address from the DNS and then fetch it. This is called a DNS lookup. Nothing can happen until this has been performed. In the jargon, this period between making the first DNS request and getting the page to start loading is called Time To First Byte (TTFB). Now in itself, this happens extremely quickly, usually in the tens or low hundreds of milliseconds – faster than the blink of an eye.

If your website was fairly basic and had very few resources (just some text), this wouldn’t be such a problem. But websites these days tend not to be so simple and the problem starts when your browser opens the page up and it starts to see a whole new load of web resources it needs to look up again.

It could be a social media button or a link to a supplier or an embedded YouTube or Wistia video.

If you are determined to reduce the DNS lookup, a couple of options are to either review the content of your site after you have run a full speed check and remove any non essential resources that are taking up time or else implement DNS prefetching on your website. With DNS prefetching this requires code on the page which instructs the browser (eg: Firefox) to speculatively pre-fetch DNS in the event that the user clicks on a link and can reduce load times considerably.

Rule No. 10: Minify JavaScript & CSS

Similar to Rule No. 4 (Gzip Components), this rule is concerned with reducing the size of the code on a website by removing unnecessary characters. This could be the removal of coding comments or whitespace. There are off-the-shelf tools available to perform this task.

Here are a few you can use -

i) Refresh-SF
ii) CSS Minifier
iii) Avivo Minifier
iv) JavaScript Optimizer
v) Packer

Rule No. 11: Avoid Redirects

Redirects are a type of status code that the web server generates when requested to provide a web page.

There are 2 main types:

• 301 Redirect – a permanent redirection, i.e. this page has moved permanently, please go to this location
• 302 Redirect – a temporary redirection, i.e. this page is not here right now, but it may come back (eg: our Christmas offers page).

The only issue with this rule is that both the 301 and 302 do genuinely serve an important purpose (although it is worth noting that the 302 has been open to abuse and can indicate spammy search engine manipulation techniques). That said, the point is clear that you should try to avoid using them unnecessarily. In case you do employ it, make sure you do it correctly.

Rule No. 12: Remove Duplicate Scripts

It can happen and it does happen. Scripts can get duplicated particularly when more than one developer is working on the same page. The problem is that unnecessary scripts make extra HTTP requests (refer to Rule No. 1 again).

There are more elegant ways to deploy scripts such as Script Management Modules but ultimately this boils down to vigilance on the part of the developer(s).

Rule No. 13: Configure ETags

An Entity Tag (or ETag) is a way to increase the efficiency of the user’s browser cache by reducing the amount of bandwidth it consumes when presenting entities (i.e. scripts, images) that are usually static.

An ETag is a string of alpha-numeric characters sent from the web server to the web browser of the user.

This allows the browser to validate if any changes have been made in subsequent visits to the same page. If no changes are detected using the ETag, this can significantly reduce the download time and hence improves the performance of the page.

Rule No. 14: Make AJAX Cacheable

Asynchronous JavaScript and XML or AJAX for short is a technique for creating fast web pages by updating only parts of the page rather than reloading all of it.

It achieves this by communicating asynchronously with the web server that the page is hosted on.

You may unknowingly be familiar with AJAX – it is the way that the Google Suggest feature works when you type in your search query in Google it offers suggestions.

So it works invisibly in the background between the browser and the web server to offer a much richer experience for the user.

So far, so good.

However, to get best use out of AJAX it needs to be optimised and ideally to respect Rule No. 3: Add Expires or Cache-Control Header. The key point here is not that AJAX is going to necessarily have a huge effect on performance, but rather that you should take care to optimise it for best performance.

Rule No. 15: Flush Buffer Early

In Rule No. 9 (Reduce DNS Lookups), the key point is Time to First Byte (TTFB). This is sometimes referred to as the Back End.

After this is what is known as the Front End and this covers many of the other rules involved in speeding up the load time by addressing scripts, CSS, etc.

What this rule is interested in is to make the browser more efficient by using a “flush” command to start sending content during the Back End period when otherwise it would be idle. This allows the browser to start preparing the page whilst the Back End completes.

Rule No. 16: Use GET for Ajax Requests

Remember Rule No. 1: Make Fewer HTTP Requests? This explained how HTTP allows for communication between the browser and the server that a website is hosted on.

The two most common methods for this two-way communication to occur are:

• Get – i.e. request data
• Post – i.e. submit data

The reason that this rule exists is purely because GET is a faster, single step process whilst POST is a two-step process that takes longer.

Rule No. 17: Postload Components

This is concerned with prioritising content (e.g. images) or functionality (e.g. scripts) which are required immediately over those that aren’t.

For example, when a visitor comes to your website, they’re unlikely to go down to the bottom of the page straight away. You could, therefore, prioritise loading images at the top of the page over those at the bottom.

Rule No. 18: Preload Components

Now that you understand the benefits of delaying loading certain components (Rule No. 17), why not make use of your idle browser time whilst your visitors spend time on a page before moving to another page on your site.

Rather than having your browser sitting there twiddling its thumbs waiting, you can keep it busy by pre-loading components (images, scripts, etc.) that will be required on other pages they may visit.

There are three types of preload:

• Unconditional Preload – just go ahead and start fetching, regardless
• Conditional Preload – an educated guess (your most popular pages that link from the current page maybe?)
• Anticipated Preload – useful when redesigning your website and prior to launching you can preload new content in people’s browsers in “anticipation” of when the new site launches so that they get a really fast experience

Rule No. 19: Reduce the Number of DOM Elements

When a visitor accesses a web page, the browser (i.e. Firefox) builds a Document Object Model (DOM) of the page – a hierarchical view of the page’s HTML (Hyper Text Markup Language) elements.

An HTML element is just a way to describe the basic building blocks of HTML and they are anything that has a start and an end tag. For example, the HTML tag for the first Heading on a page (the H1 Element) looks like this:

<h1>Heading Goes Here</h1>

Basically, this rule is all about looking under the hood at the HTML and making it as elegant and lightweight as possible, and replacing unnecessary elements without losing the visual appeal or functionality of the page.

Rule No. 20: Split Components Across Domains

If we refer back to Rule No. 15 (Flush Buffer Early) we looked at the Back End and how that relates to Time to First Byte (TTFB) and then the Front End where all the components (images, scripts, CSS, etc.) are accessed.

This rule looks at how to speed up the Front End by allowing the components to be accessed in parallel (at the same time) rather than sequentially (one after another). This can be achieved by hosting the components in different sub domains.

So, instead of all your images being on www.myhomepage.com, they would be on images.myhomepage.com.

Yahoo does caveat this rule by saying that you should not consider more than 2 to 4 domains, or you could violate Rule No. 9: Reduce DNS Lookups.

Let’s be honest, this one is probably for very busy (usually eCommerce) websites.

Rule No. 21: Minimize Number of iFrames

An iFrame is an easy way of embedding content from one website to another.

This is useful for including things like an advert from another page or website.

Great news! However, remember DOM Elements in Rule No. 19? Well an iFrame is twice as heavy as most other DOM Elements.

The result is that it can slow down what is know as “Onload”. This is like a green light to say everything is loaded. If the browser has to wait for the (heavier) iFrame to load, it can give the impression that the page is loading slower as the Onload has not completed.

Rule No. 22: Avoid 404s

We’ve all seen a 404. A 404 is a standard HTTP response that appears when a page is missing. They are sometimes called broken links and are used as an SEO technique to surreptitiously build links.

But remember Rule No. 1 – Make Fewer HTTP Requests? Well, 404s break that rule because they are unnecessary and will slow down response times.

The fix?

When you find them, link them correctly or even create the content to replace the broken link.

Rule No. 23: Reduce Cookie Size

When used well, cookies are great tools for enhancing the user’s experience on your website by recording useful information that can be used in subsequent visits.

But there is a flip side to it.

A cookie is a file and that takes up space. They may seem innocuous enough. But if you are not careful, they can start to eat into the load time. Some Yahoo research on the effect of cookies on download speed is that a 500 bytes cookie loads at 79 milliseconds (ms) and every subsequent 500 bytes adds approximately 16 ms to this.

The main point here is to balance the return you get from using the cookie to the hit in terms of page load.

Rule No. 24: Use Cookie-Free Domains for Components

This rule aims to reduce the overhead caused when your browser requests static components (e.g. images) from the web server. When a browser makes a request for static content, it sends cookies too and these serve no purpose whatsoever in terms of the request. So, they are just dead weight, slowing things down.

Similar to Rule No. 20 (Split Components Across Domains) you can improve page speed by removing the need to send the cookies by storing your static components on a sub domain, or for belt and braces you can even host them on a completely separate domain.

Rule No. 25: Minimize DOM Access

If you cast your mind back to Rule No. 19 you will remember how the browser builds a DOM of the page it’s visiting. Unfortunately, accessing DOM Elements via JavaScript is slow so your developer needs to try to minimize this type of access.

Rule No. 26: Develop Smart Event Handlers

You might not know what an Event Handler is (yet) but you will recognize what they do. When you click on a button on a web page, hover over a link etc., it’s the Event Handlers that do it. They make web pages dynamic and are often scripted in JavaScript.

The problem arises when there are too many Event Handlers being executed unnecessarily. Again, elegant programming is required and Yahoo recommends Event Delegation which is a technique that allows a developer to create event “listeners” that are called upon only when required.

Rule No. 27: Choose Over @import

This rule is aimed squarely at Internet Explorer (IE) only. First, let’s understand what an @import mean. When building a page you can use external CSS (see Rule No. 8: Make JavaScript and CSS External) and both the @import methods will allow you to achieve this. There isn’t really much difference between the two, except that some older browsers didn’t recognise @import.

The problem with using @import though is that in IE it treats this command as if it were a at the bottom of the page. What’s the problem with that? Well that would contradict Rule No. 5: Put Stylesheets At The Top.

Rule No. 28: Avoid Filters

This is another rule which is to some extent aimed at Internet Explorer (IE) users. It relates to the use of a colour filter called AlphaImageLoader which was implemented in IE to address an issue with semi-transparent true color Portable Network Graphics (PNG). PNG is the most popular compression format for images on the web.

The issue here is that the filter can cause pages to freeze whilst the image is downloaded and it increases memory consumption. To make matters worse, it flies in the face of Rule No. 19 (Reduce the Number of DOM Elements) because it works on an element by element basis thus increasing the problem.

The workaround suggested by Yahoo is to avoid using the filter altogether and rather use gracefully degrading PNG8 instead of semi-transparent true color PNGs.

Rule No. 29: Optimize Images

Whilst images take up space and will slow down a page, they also make our site more appealing to our visitors. Therefore, it’s important to ensure that any images used on your site are as lightweight as they can be, without compromising quality.

Yahoo suggests four main methods of achieving this:

• Check the pallet size being used for each image & how many of the pallet are being used. If there are 256 colours in the pallet & 4 are being used then this image can be improved.
• Convert GIFs to PNG (unless they are animated GIFs of course) & check if the size reduces without losing quality.
• Try compressing or optimizing your PNGs using a PNG compression technique.
• Likewise for JPEGs, make sure they are optimised for best performance.

Rule No. 30: Optimize CSS Sprites

If you can cast your mind all the way back to Rule No. 1 (Make Fewer HTTP Requests), you’ll recall that one of the suggested methods was the use of CSS Sprites. This is a technique that reduces http requests by grouping images into one main image and then just referring to the position of the required image to display any one particular image.

Well done, if you are doing this! But it can be improved even further in the following three ways:

• Reduce the file size by positioning the images horizontally in the Sprite rather than vertically
• Keep the colour count low by combining colours used – under 256 will fit in a PNG8 (the 8 stands for 8 bit which usually means a smaller file size)
• Leave as little space as possible between the images on the Sprite; this is more related to memory use than to file size though

Rule No. 31: Do Not Scale Images in HTML

All this rule means is that it’s more efficient to use the correct (i.e. smaller) size of an image rather than using HTML instructions to scale down a larger image.

Rule No. 32: Make favicon.ico Small and Cacheable

Whether you like them or not, favicons are a necessity due to the way that many browsers work because they request them when they visit your site. It’s better to display one than to offer a 404 (page not found) error.

Yahoo recommends that the best practice is to make them small (ideally less than 1K) and to respect set an expires Header to a reasonable point in the future (see Rule No. 3: Add Expires or Cache-Control Header).

Rule No. 33: Keep Components Under 25KB

This rule mainly exists to satisfy iPhone users because this mobile device won’t cache elements greater than 25K in uncompressed format.

Whilst compression (Rule No. 4) is important, minification (see Rule No. 10) can have a bigger impact here.

Rule No. 34:Pack Components Into a Multipart Document

Again, a mobile related rule. It allows you to respect Rule No. 1 (Make Fewer HTTP Requests) by packing components together so that several can be fetched with one request rather than individually.

Rule No. 35: Avoid Empty Image SRC

SRC stands for “source” in HTML and is an attribute which means it’s a command (inside a command). When a browser loads a page, it gets the image from the server and inserts it into the page. It is the SRC attribute which specifies the URL of the image.

Rather than being down to poor coding, this could be down to a conflict caused by a Content Management System (CMS) generating content on the fly. In best case scenarios, you may get a processing spike on your server, but for busy sites with many tens of thousands of daily pageviews, this could bring the server down and take your site offline.

This is technically a browser issue that should get fixed in time. However, in terms of addressing this yourself, other than taking care to manually check that you don’t have any of the offending code on your site, you should get your site re-designed using HTML5 which addresses this issue.

Conclusions

OK, we’ve covered a lot of ground here. One way that you can speed up your website though without hiring a developer is to make sure you have super fast hosting. With our SSD Hosting you will definitely have a faster website.