There have been rumours around since November last year that Google either were already or were about to include the speed of your website as a criteria in their ranking algorithm.

A blog post Google fellow Amit Singhal and principal engineer Matt Cutts from the 9^th April now confirms that this is the case with the post stating that "Speeding up websites is important -- not just to site owners, but to all Internet users. Faster sites create happy users and we've seen in our internal studies that when a site responds slowly, visitors spend less time there"

Website owners now have another incentive to make sure that their sites perform at an acceptable level. A survey conducted by Forrester Consulting at the end of 2009 to examine eCommerce web site performance and its correlation with an on-line shopper's behaviour confirms Google's view . The most compelling results reveal that two seconds is the new threshold in terms of an average on-line shopper's expectation for a web page to load and 40 percent of shoppers will wait no more than three seconds before abandoning a retail or travel site.

Additional findings indicate that quick page loading is a key factor in a consumer's loyalty to an eCommerce site, especially for high spenders. 79 percent of on-line shoppers who experience a dissatisfying visit are less likely to buy from the same site again while 27 percent are less likely to buy from the same site's physical store, suggesting that the impact of a bad on-line experience will reach beyond the web and can result in lost store sales.  52 percent of on-line shoppers stated that quick page loading is important to their site loyalty.

I posted a couple of blog articles covering things to consider to improve your websites performance take a look here and at this one.

Do you know how fast your website is ?  How well does it perform during busy periods.?  As well as monitoring your key pages every, say, 15 mins. you need to also check your site more comprehensively to ensure there are no "problem" pages within the site.  So something that spiders through your site (in a similar way to the way Google does) that will report your average speed and identify any offending pages would be a useful addition to your armoury..

Further to my pointers about how to improve the performance and quality of your website and my blogs on Google's musings about a website's speed affecting it's rankings I thought a few more pointers about things to consider when looking at improving the speed of your Webpages might be helpful.

Reduce File Sizes

You can find out the sizes of your files by looking at the "Site Inventory" page in your Sitemorse Audits or looking at the "Page assets" info of a Snapshot report and see the impact on performance by looking at the "Performance" info.

Use a HTML Compression tool

There are multiple methods of reducing the time it takes to send a file from the server to the client. Gzip is a compression tool used on servers to compress files in order to save those precious kilobytes. It is the most popular and effective compression method at this time, reducing the response size by about 70%. It can be used to reduce the size of any type of file, however as images and pdf files are already compressed, it is typically best not to attempt to compress these with gzip as there may be loss of quality and can potentially increase file sizes.

Don't Scale Images In HTML

Just because you can set the width and height of an image in HTML does not mean you should! If you want to display an image that is 100px wide and 100px high, then the image should be 100×100px rather than a scaled down 500×500px image! This will reduce the size of the image therefore make it load faster.

Optimise your CSS and JavaScript

Removing unnecessary code from JavaScript and style sheet files will reduce the file size, thereby improving load times. Minification takes this a step further by removing all comments, new lines, tabs and spaces. This improves response time as the size of the downloaded file is reduced drastically. A popular tool for minifying JavaScript code and CSS is YUI compressor.

Reduce Server Calls

You can find out the number of CSS and JavaScript files by looking at the "Site Inventory" page in your Sitemorse Audits or how many are on a particular page by looking at the "Page assets" info of a Snapshot report.

Combining style sheets (and JavaScript files for that matter) into as few files as possible will reduce the number of calls being made to the server. Combining files is more challenging when the style sheets and scripts vary from page to page, but the improvement in response times makes it well worth the effort.

CSS Sprites combine background images into a single image, reducing the number of image requests, and using CSS can show only the parts as desired using the background-image and background-position properties.

Script Locations

You can find out the sequence of how files are loaded by looking at the "Performance" info of a Snapshot report as well as seeing the impact they have on the page's load times.

Where you import your CSS and JavaScript can make a huge difference on how long a page takes to load, and how long it appears to take.

CSS At the Top

Moving style sheets to the HEAD makes pages appear to be loading faster as the page will render progressively. Not only is this stated in the HTML specifications, but by placing them near the bottom of the document, many browsers will be unable to render the page correctly as these browsers block rendering to avoid having to redraw elements of the page if their styles change.

JavaScript At The Bottom

Browsers are able to download from multiple sources at the same time (usually two downloads in parallel per host) allowing a page to load a smidgen faster. The problem with JavaScript is that they block these parallel downloads. Moving them to the bottom of the page gives everything else time to load. Sometimes this is impractical as some script may be needed in order to insert content into the page, for example if the script uses document.write. A work-around for this is to create a function at the bottom of the page and use an on-load command, where you want the content, to call a function when the page has finished downloading.

Flush

In PHP the function flush() allows a partially ready HTML response to be sent back to the browser. This is useful while the back-end is putting together the rest of the HTML page and is most noticeable on busy back-ends, where a script requires a lot of time to pull together a lot of resources and complete making the page before sending it to the browser. A good place to consider flushing is right after the HEAD as this is usually the easiest part of the page to create and allows the browser to start including any CSS and JavaScript files the browser requires while it waits for the rest of the HTML page, which the back-end is still constructing.

For example:
...<!-css, js->
</head>
<?php flush();?>
<body>
...<!-content->

Here's an article I picked up on from Lawrence Jones in businesscomputingworld.co.uk on 20th Jan 2010. It reinforces the stuff that's been coming out of Google recently which I blogged on "Does speed affect your website" and my blog on improving the speed of your web pages and how Sitemorse can help you.

Speed was identified as a key factor in Search Engine Optimisation for 2010 at a recent round table discussion in Manchester.

Confirming Google's recent findings that there is a direct correlation between Web site speed and business results, the panel of industry experts identified the speed at which Web site content is delivered as an increasing factor in improving user experiences.

I think it is a given that content is very important but now it is about the delivery of that content. I think Google is putting it higher up the search engine in its priorities and as far as I'm concerned it is about location, location, location - where the server is located and how ISPs can deliver that packet of information faster than anyone else.

Following on from Google's Matt Cutts' comments at the PubCon 2009 event, page load time was identified as an increasing concern in relation to Google's potentially changing priorities in 2010. With speed already a factor in the AdWords quality score and Google's increasing focus on it in relation to Chrome and Caffeine, faster Web sites were thought to be a future rankings winner.

Panelist and commercial director of High Position Terry Heffernan agreed: "By talking to our technical teams certainly we see that speed is going to be more important and it could be a window of opportunity."Speed is one of the elements of SEO but it is about fine-tuning the whole machine to deliver the best performance."

In addition to the speed at which content was accessed, the quality of the content itself was also credited as an essential SEO factor by the panel, which included Craig Stone from CSI Media, Tom Cheesewright, strategy director of And Digital, and Matt Rycroft, technical director of Oomagoo.

The use of social-networking and displaying richer, more varied content across a variety of channels was also thought to optimise business results and search rankings. Adopting a combined approach by using Twitter feeds, blog posts, press releases and video content was encouraged to achieve the ultimate universal search effect with links aiding customer flow.

Fundamentally, identifying and educating clients to understand that SEO is not simply a one-stop-shop but requires a multiple approach over time was collectively agreed to be the most effective way of climbing the Google rankings in 2010

I saw this on the techradar.com website on Monday 16th.  It looks as if it is clearing up the confusion and then confirms, in the last paragraph, that the confusion still exists.  But useful as it does mean that if it isn't already, then speed will be an issue for 2010.

Google has stated it is considering using the speed which a website loads in its search algorithms, with slower sites set to be pushed further down the results page in favour of quicker ones.

Google's Matt Cutts revealed the news in an interview with WebPro, admitting that 'a lot of people' within the company favoured adding a speed factor into the way in which a page is ranked.

"We're starting to think more and more about should speed be a factor in Google's rankings," said Cutts

A good experience

"Historically, we haven't used it in our search rankings, but a lot of people within Google think that the web should be fast - it should be a good experience," he added.

"So it's fair to say if you are a fast site maybe you should get a little bit of a bonus and if you're a slow site then, you know, users don't want that as much."

Already a factor?

The speed of a website and the way in which it is affected by Google rankings is already a hot topic on the web, with .Net editor Dan Oliver explaining to TechRadar that many believed it was already a factor.

"It's great to hear that speed is going to play a part in Goggle's algorithm for 2010, but we think it may have been a factor for some time.

"In fact, Google's communication and public affairs department told .net magazine months ago that 'all other things being equal, it's fair to say that a speedy site will rank better'."

Because we often mention that we check Metadata as part of our tests we sometimes have people saying that they don't need Sitemorse as they already have an SEO tool or an agency handling SEO.  I wont start down a sales training course here about objection handling, false objections etc.  But if there is genuine confusion about what our Metadata tests do then it's worth just visiting the subject briefly.

What we do provide is:-

This is what we do currently.

Like all of our tests we are looking from a browser's perspective therefore we are looking at what content is there and if it meets the related standard(s).  So with Metadata we are looking at what types of Metadata are present on the page i.e. is there a Title, a description and keywords present on the page.  We then present this as a percentage of pages in the test that did NOT have the data present.

We also take account of the Government's eGMS standard for all the .gov.uk sites and present information on how well the site is doing in achieving compliance with the mandatory and recommended items and if they are present are they correct.

We'll also check the spelling and report any issues.

To get a detailed list of what Metadata is present on which pages we have a chargeable report that will provide this information.  Please discuss this with your Account Manager if you would like one of these reports.

 For further info on this take a look at http://www.sitemorse.com/d/guides/Meta_Data_Guide.pdf

What we do NOT do:-

We do not look at any type of page ranking that the pages achieve in the various Search Engines.

We do not look at the links to see how these might be improving the ranking

We don't look at who's bidding the highest for your keywords

These are all things that the SEO community do for you using an array of techniques and is, to some extent, a whole different industry sector from what Sitemorse focuses on.

As I said earlier this covers the current situation.  We are always looking at what we can do to improve Sitemorse (indeed our Annual Client Survey is a useful source of ideas from our Clients on what we can do to improve our service) and we have some ideas we are working on that will enhance our reporting on Metadata.  As soon as we have something more concrete I'll post something on the blog.