Nobody likes a slow website, and now officially Google doesn’t. And by “now” , I mean a couple of months ago. Yes ironic I know, a slow response with this post.

Google is constantly checking your site’s performance and all indications point to this being a ranking factor in future. This was reported a late last year by WebProNews, after an interview with the venerable Matt Cutts from the Goog.

By their own admission Google is all about the ”user experience”, with their prime SEO mantra being; “make websites for users, not for the search engines”. And page load time is one if the most important user experience issues that you’ll encounter when browsing the web.

It’s a well known “statistic” that if a web page does not load in less than 3 seconds a user will ”bounce” from the site, return to the search results and probably pick one of your competitors. So, how can you speed up a slow site?

Examine your site’s performance

First off, you should analyze all information available about how your pages load using some readily available tools. As a good SEO or webmaster you’ve probably already signed up for Google’s Webmaster Tools. A recently added feature is the “Site Performance” section, which is found under the “Labs” menu item.

This will give you a general indication of whether Google sees your site as being fast and provides a few tips on how your pages can be improved for speed. We can also see over time how your work in improving web site speed is taking effect.

For a more immediate read-out of a webpage’s performance we use the Yahoo YSlow plugin for Firebug (a Firefox plug-in). YSlow can be run on a live page that you are viewing and gives instant (depending on page load time of course :) ) feedback on what areas you can address to improve load time. It will also give you an indication of the “emtpy cache” (first time visitor) and “primed cache” (repeat visitor) performance.

For an advanced metric of page load time, Google Analytics can be configured to record a page load time metric and gives a reasonable representation of the issue from the user perspective. Analytics can be made to track the load time based on internet connection speed in so giving a broad indication of your site’s performance.

Enable GZip Compression

All modern browsers support webpage GZip compression and are able to decompress the data sent from your server. The less data that is transferred for each page, the less time it takes for a page to load in a browser. For those site owners who have a restriction on the amount of traffic with their host, GZip compression will reduce the amount of data that you have to serve.

You can use a GZip compression test to check if your pages are currently compressed and if not, this tool will estimate of the size of savings to expect. If GZip compression is enabled, the actual % of data saved during compression is shown. This tool can also test CSS and JS files.

Apache and Microsoft IIS web servers both support GZip, and quick and dirty instructions for enabling GZip compression is shown below:

Apache Server

The module that deals with GZip compression on an Apache server is “mod_deflate”. Create an “info.php” file and add the code <?php phpinfo() ?>, upload to your server and browse “/info.php” to get a readout of the Apache modules installed. If mod_deflate is loaded on your webserver then the following .htaccess declaration will enable GZip for a lot of file types.

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript application/x-httpd-php application/rss+xml application/atom_xml
</IfModule>

If mod_deflate can’t be loaded by your host or server admin (it requires a core recompile for installation) then the following .htaccess declaration will enable GZip compression for php files only. The “gzhandler” is not as efficient at compressing data than “mod_deflate”, so will be marginally slower and the savings will me slightly less but for most sites will suffice.

php_value output_handler ob_gzhandler

If your pages are .htm or .html (as opposed to .php) add the following lines at the top of your .htaccess to get Apache to parse those files as .php so that they will be compressed.

RemoveHandler .html .htm
AddType application/x-httpd-php .php .htm .html

Microsoft IIS

If you’re running a Microsoft IIS server, the following document will explain how compression can be activated: http://g.www.ms.akadns.net/technet/prodtechnol/WindowsServer2003/Library/IIS/25d2170b-09c0-45fd-8da4-898cf9a7d568.mspx?mfr=true

Reduce Image Size

These days websites are very graphicy, with most sites having appealing header images, product images and so forth. Unfortunately the more graphics on a site, the more data needs to be sent to the user’s browser leading to longer load times. This is especially an issue for first time visitors who don’t have the images cached.

Most competent web designers keep this in mind and will try to maximize the JPeg compression versus the image quality to speed up page loading. But there are some cool tools out there that can further improve things.

One of the most useful image tools that we use is SmushIt (found in the YSlow plugin that is mentioned earlier in this post). SmushIt is able to examine the images on a web page and compress them even further with no noticeable degradation in image quality. Smushing your header and background images is a must, and the data savings are often surprising.

One of the big no-no’s that we often come across is using the browsers image scaling to fit a large image into a small space.  We often find this is the case in product catalogs, when a large product image is used for the shingle thumbnail on the category listing pages. In this case, use a small thumbnail in the shingle instead of scaling.

For all other cases browser image scaling should be avoided, as the web browser is slow at scaling, not to mention the extra time spent downloading the large image. Always  ensure images are scaled to the correct size before use on your pages, and you’ll notice an improvement in load time.

If your website template uses a lot of background images, header images and image buttons  then the number of HTTP requests for a webpage will be quite high. Each request takes time and can slow down a page. To reduce this delay combine these template images into a CSS sprite image. This is basically one “big” image that contains all of your template images and using CSS classes you can pick out the correct part of this image that you need for each of the graphic elements on the page.

CSS and JavaScript Code

There are a few strategies for improving CSS and JavaScript file load time. At a minimum you should externalize all CSS and JS files so that they can be cached by the users browser. In addition, if you have more that one CSS or JS include file, combine all the CSS includes into one file, do the same with the JS includes, and this will reduce http requests. For the hardcore guys out there, try to Minify the CSS/JavaScript which will remove unnecessary white-space and line-breaks. Minify can be also found in the YSlow plugin for Firebug.

Reduce the amount of database calls in your application

A lot of websites out there rely on an SQL database to store information that is shown to your users. If your site runs a product catalog or a CMS systems then the odds are that a database is involved. Every time a page is requested by a browser, the database is queried for the information that the user will see on the page. This back and forth takes time and can be a bottleneck.

To speed things up, only run the minimum database queries that are required and only request the actual table fields from the database that you need. Avoid “SELECT * FROM” in your SQL queries. Optimizing things in this way can get quite quite knarly, so be prepared for a lot of hard work. For large sites that get a lot of traffic this can help in page load time tremendously and is worth the effort.

Wordpress

Wordpress is the most popular blogging software out there, and due to it’s flexibility is increasingly being used as a CMS system. Wordpress uses an SQL database to store all your posts and pages.

Hundreds of “plug-ins” are available for Wordpress to help customize it in countless ways. Unfortunately the more plugins that you install the slower Wordpress becomes. The less plugins that are activated the faster your Wordpress blog will be. You should also go as far as removing all unactivated wordpress plugins from your “plugin” directory.

A useful addition to Wordpress are “Widgets”, which allow for “real time updated” areas within your template. There are Widgets available to show latest posts, most popular posts, dynamic menus and much more. The problem is that each one of these widgets will poll the database to get the information required, thus increasing the load time of the page. Try to reduce the number of widgets that you use and if a widget is showing content that doesn’t change too often, try to hardcode the HTML with what the widget would display.

Summary

There are many more things to look at to speed up a website and those listed above are the areas that we initially tend to look at for our search engine optimization clients. Depending on the size of a site and the amount of traffic it gets, even the simplest change can have a significant effect.

If there are any other ways you have found to speed up a site, we’d love to know of your experiences.

This outlines the importance of frequently logging into Webmaster Tools to keep up to date on your sites search health and not assuming that this useful tool is “set and forget”. Google seems to be having periodic website verification and Sitemaps errors of late, has anyone else has noticed this?

The website concerned has around 4000+ article pages indexed, with each article page consisting of templated boilerplate sections and the main article text pulled from a HTML include file. Unfortunately on this particular day the directory containing the article include text files was accidentally deleted from the web server. Every article page subsequently served reported an ASP sever execute error as the article text include file directory was missing. The article include directory was only restored from a backup around 12 hours later.

Within several hours of the problem being reported it was obvious that the search engines had taken notice. According to the Enquisite search metrics data for the site, there was a definite and almost immediate reduction in search referrals. As it turned out, there was around 50% less search engine referrals that day compared to the preceding and following days. This demonstrated that the article pages had a temporary reduction in ranking, resulting in the loss of search traffic for that particular day. So what happened from a search engine point of view?

We can assume that if the search spiders visited that day they noticed that the article pages lacked content and provided no value. It is also possible that the search engines took into account the users’ probable immediate and quick bounce from every article back to the search results page. Either of those explanations could result in the temporary loss of ranking witnessed for the article pages. What is certain is that the search engines reacted quickly to the problem by punishing each articles’ ranking which resulted in a devastating loss of traffic.

As long as you provide a HTML alternative of the same content for the spiders, and non-JavaScript enabled browsers, then the search engines will not have a problem with your Ajax pages. This will also allow you to reach an audience who have accessibility issues, such as the visually impaired or those using mobile devices.

As part of our initial examination of a client site our SEOs turn off JavaScript whilst browsing or use the Lynx text only browser to determine if all of the content and links can be seen by the spiders. Although I find Lynx to be quite useful for browser accessibility issues, it does not give a true representation of how a search engine spider will see a web page. By not displaying linked images that have a blank or missing alt attribute, Lynx can give the mistaken impression that some links are not spiderable. To get the most realistic impression, there are many “Search Engine Spider Simulators” that will show the text content and links that are visible to a spider after all of the HTML and JavaScript is removed from the page source code.

Although Ajax facilitates powerfully interactive web sites, the same old problems occur for the search engines as with Flash or JavaScript presented content. “Web 2.0″ may be the latest buzz word in web site design, but having already dealt with Flash and JavaScript for some time, SEOs know what is required.

Do you have a multitude of sites that you administer through Google Webmaster tools? We all know it can sometimes be difficult to keep all the sitemap.xml files up-to-date and uploaded to all those seperate web-server FTP accounts, especially if you do not have any sort of automated system to do it for you.

In the past you could only store a Sitemap on its respective host, but this restriction has now been lifted. As long as you can ‘prove’ you control the host, by the verification process in Webmaster tools, you can store the Sitemap on any other host that you control. This means that you could store all the individual Sitemaps on your own server or even have URLs for multiple websites contained within one Sitemap file.
There is one caveat however, in that this will only work for Google at the moment, although they do assure us that they are talking to the other search engines that support the Sitemap Protocol.
I would imagine that the simplest implementation would take the form of a change to the Sitemap declaration within the robots.txt file. As the site ‘owner’ would legitimately have access to the robots.txt anyway, this would neatly resolve the security issue that Google was concerned about. Check out the original Google Sitemap Cross Submissions post.

You can now control the country association of your content on a per-domain, per-sub-domain or a per-directory level. It’s as simple as adding a new website entry to your dashboard for the domain, sub-domain or directory that contains the international content, then using the “set geographic target” interface from the “tools” menu to specify the country.

Although this will work well for sites that determine their international pages using a separate domain or directory structure, it will not help dynamic sites that use a URL parameter for this purpose. Perhaps this is a future addition that we can look forward to. For more information read the Country Associations for your Content post from the Google Blog.

Conversely, Google seems to be doing the opposite and reducing the amount of competing pages. As an example here’s some data for the search phrase “search engine optimization“.

October 2007 – Google: 19,800,000 MSN: 41,644,219
September 2007 – Google: 38,200,000 MSN: 2,200,250

It seems that Google is refining its index to produce more relevant results; Is MSN bloating its index or just trying to play catch up? For those who have also picked this up, please share your thoughts.

All programming languages have semantic and syntactic rules that must be followed if the program is to run correctly, and HTML script is no exception. Unlike ’strict’ programming language compilers, web browsers can be very ‘loose’ in their interpretation of HTML, leading many web developers to take short cuts and ignore HTML code compliance. From the very beginning of the WWW, the W3C has defined the HTML script language and provides the W3C Validator to aid developers in creating compliant code.

HTML validation can be helpful to SEOs as it can outline code errors, missing alt attributes, incorrect and elements and tags and character encoding issues. A web page that successfully validates will have a better chance of displaying consistently across compliant web browsers. For the search engines, processing time and resources will be saved when extracting markup and reduces the chance that content will be stripped out along with the markup.

Code bloat is a double whammy, causing an increase in page load time for users and increasing the time for SE spider crawls across a whole site. Spiders only have a certain amount of time on a site during a crawl and anything that can be done to reduce the amount of code per page will increase the number of pages that can be indexed during this time.

There are a few simple steps that can be undertaken to make sure your code and resulting page size is as small as possible.

1. Remove your JavaScript code from the main HTML source into an external include file.
2. Externalise CSS in the same way (where appropriate).
3. Use CSS to format content instead of HTML font tags, table elements and other markup.
4. To reduce page load time on dynamic websites, reduce the amount of queries to the database per page and reduce the amount of records returned during each query.

The direct results of these methods in reduction of page size can be seen using the following example from Google Webmaster Tools. If we examine the crawl rate data for a website that has around 3500 pages, each of which originally contained many hundreds of lines of JavaScript code and large amounts of CSS declarations. The pages also had multiple sections and incorrectly defined elements. After removal of all of the unnecessary code and correcting the HTML syntax errors, the pages validated and were around 20% of their original Kb size.

As can be seen in the graph below, the time spent downloading a page has reduced (red), and consequently the GoogleBot has been able to crawl more pages per day (blue).

Up popped a result for a current promotion that gave a 20% discount on my flight, saving me nearly $CAD 100.
I will now use the cash to buy the happy couple a wedding gift, on-line of course using another promotional coupon :), and I maybe have some cash left over to buy a few drinks at the wedding reception. ( I’m sure the bar will not be free, the groom is renowned for keeping his wallet closed)

So whenever you are about to make an online purchase of any kind, do a search in Google (or any search engine for that matter) for a promotional code (or coupon) associated with that company and save your hard-earned. You may have to try a few codes to find one that is current, but there are many sites and blogs out there that keep track of these promotion codes so it shouldn’t be too hard to find success.
Happy Shopping.

Alt attributes for images are mandatory within the W3C HTML specification and are a Priority 1 checkpoint in the W3C’s Web Content Accessibility Guidelines (WCAG) . Alt attributes are essential in conveying the ‘meaning’ of images for the visually impaired through their use of talking browsers, screen readers or text only browsers. The most important consideration for SEOs is that Google strongly recommends the use of alt attributes for images.

From Google Webmaster Help

“If your site contains elements that aren’t crawlable by search engines (such as Flash, Javascript, or images)….

…. you should consider visitors to your site who are unable to view these elements as well. For instance:

* Provide alt text that describes images for visitors with screen readers or images turned off in their browsers.

Including substantially different content in the alternate element may cause Google to take action on the site.”

Alt attributes should be present within every image element in the HTML code and should describe the content of the image. For spacer images use the null alt text, alt=”", as these images offer no useful information to the user. If the image is active or performs a function, within an anchor link for example, then the alt text should describe the function. If the image is not active, but conveys information, then the alt text should contain the same information. For SEOs the alt attribute is useful as it can contain relevant keywords, however be careful as keyword stuffing alt attributes will have a very negative effect (note the Google excerpt above). Optimization of images is increasingly becoming an important factor and will have an effect within image searches, universal search (news article images, organic image results) and product search (Froogle / Google Products).

The alt attribute is one of the more neglected aspects of web site design and it will be interesting to see if web designers and developers take note of the outcome of the Target lawsuit. Depending on the success of this class action, the California courts may end up saving SEOs a considerable amount of time and energy.

Resources

W3C Validator – Check HTML validation and discover missing alt attributes on your pages.

Use the excellent Web developer browser plugin to outline images that are missing the alt attribute as you browse your pages; (not for Internet Explorer)

An accessibility checking tool will outline a web pages’ issues with accessibility, privacy and quality.

The snippet is the short text ‘preview’, that also includes the page title and URL, which appears as part of each search result. A good snippet can influence the amount of clicks that a web page attracts and can be a way of separating your site from the competition. Google’s “Snippet algorithm” is completely automated and in order to increase relevance for the user the snippet shown can depend on the search query. Here is an example of a Google snippet for the BBC News web page.

One way which SEOs can exert some influence on the snippet and reduce the likelihood that Google will dictate how it appears is through use of the Meta description tag. The Meta description is a ‘conversion’ rather than a ‘ranking’ factor, and they should be written more as an advertisement for the page to attract a user click. That said, you should not get overly promotional with the language and avoid such phrases as “the best”, “the webs cheapest” as they don’t provide any useful information for the user. Targeted keyword phrases can appear within the description but be careful, as an excessive number of keywords will make them appear too “spammy”. If Google feels that a Meta description does not accurately relate to the search query then it will be ignored and the snippet will contain text from within the page content. This can be seen in the two examples below.

For the search query “reverse mortgage”, the snippet below is formed from the Meta Description tag (interestingly enough the page title is not used as the on-page title does not mention “reverse mortgage”).

For the same page, when the search phrase “home mortgage” is used, the snippet below is returned. On-page content that relates to “home mortgage” is shown within the snippet, this time the on-page title is used as it shows some relevance to the search query.

The most important factor is that the Meta description should be unique to each page and ensuring your descriptions reflect the content of each page will prevent any duplication issues. A good way of checking if your descriptions are unique across the pages on a site is to use the “site:domain.com” command within the Google search box.

For sites that have static pages, writing the descriptions manually is usually quite a straight forward task. If you are syndicating content by publishing articles or blog posts, the synopsis written for the post can be used as a description, perhaps also including the author and publication date.

For dynamic pages, such as product catalogs and other database driven pages, automatically generated descriptions are the preferred method and is condoned by the search engines. It should be a simple programming task to pull suitable information from a product database and insert it into a Meta description tag for each of the product items. Including the product category to which the item belongs, the colour, price and perhaps an extract of the description associated with the item would be suitable. Remember to keep the total length of the Meta description below 250 chars, ideally less than 150, as this is usually all that will be shown within the search result.

As a final thought; you know your pages best, and by creating good Meta descriptions you will take snippet control out of the search engines’ hands for this important traffic generating element.