When things go wrong they always go wrong at the worst possible time.  A rather glum view put somehow always works out to be true.  And it's true for people responsible for controlling their organisations websites.

So last week would be a bad time for a link on the Dept. for Culture, Media and Sport (www.culture.gov.uk) with a title of process of a General Election (which links to a page on the www.parliament.uk website) to go wrong.  And if that link was on the Home page it would probably be noticed and fixed pretty quick, right ?  Well, actually this link first failed at around 1pm on Friday 7^th May - yes that's right, just around the time when everyone would be looking for any info they could find about elections and hung Parliaments.  It was eventually fixed a little over four and a half hours later.

There's a couple of things that are a little alarming about this.

From a culture.gov.uk view point, this link wasn't buried in the depths of their website - it was right there on the front page.  Now most sites use some sort of monitoring service to measure availability and performance of their sites and it would be strange if they didn't use their Home page for this like most organisations do.  To mitigate this a little, the problem with many of these services is that they only measure availability and performance and they don't check the quality of the page the site serves up. So you can end up serving up rubbish with 100% availability with superb performance when what is actually needed is something a little more sophisticated which checks that the page is OK as well.

Now, looking at this from the www.parliament.uk site, I'd say that a page covering how elections are run would be a pretty key page on their site.  And if someone decided to move or rename such a page then you'd expect them to put what's called a "redirect" in place so that if anyone has a link to the original page any clicks on those links will automatically be redirected to the new page.  This is normal practice and happens all the time.  And indeed that's exactly what they did four and a half hours after making the change to solve the problem.

The people at culture.gov.uk probably blissfully unaware that the problem existed because they didn't solve the problem - the people at www.parliament.uk did.

The truth is that at end of the day, or in this case late afternoon, neither set of people come out well in this.

And, of course, the problem occurred at one of the most inconvenient of times possible.

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..

It's all very well creating league tables and making claims about who is best and who is worst.  But the measures used need to have some context and there might be another league table that casts a different light on the sites. 

In the Bowen Craggs Index of corporate website effectiveness league table we have Shell and BP in first and 2nd place.  And yet these two sites fail on a range of very basic quality and compliance measures that must surely call into question their effectiveness.  AstraZeneca, the only other UK site in the top ten, has clear performance issues which again must have an impact on its overall effectiveness.

And it's all very well looking at what "facilities" are available on a website for visitors and the sites use of Social Media etc.  But if the sites are littered with broken links, have basic accessibility issues and poor performance then surely they can't be claimed to be the most effective sites in the world !

To validate our reasoning and our capability to question these findings  we have taken 3 very basic requirements of a corporate website and, looking at the highest rated UK sites in the table, we offer some of the actual issues (we are more than happy to share exact details - the market needs far greater transparency) which we found on the 3 sites:

AstraZeneca - website performance

When looking at performance one of the key tests is 'time to wait' - how long does it take for anything to happen after you click a link.  In checking the top pages of the site, the average wait time of the slowest 10 items was just under 3.75 seconds.  One item leaves you sitting there for over 6 seconds before anything happens!

A 2009 survey by Forrester Consulting showed that 40% of visitors will wait no more than three seconds before abandoning a website.

Shell - website accessibility 

How can they be the top site when looking at accessibility, which Shell make great claims about on their website, they have basic failures like missing alt text on images and missing page titles ?

It's generally accepted that making sites accessible for people with disabilities not only fulfils your social responsibilities (and meets your legal obligations) but also makes your site much easier to use  for those people without disabilities.  A great win-win scenario.

If a site doesn't meet even the basic accessibility requirements then it is ineffective for a significant minority of the population.

BP - basic quality issues - broken links 

Again looking at the top pages of their website we found Webpages and some important IR documents (an area that should be key to a corporate website used for investor communications) contain broken links, and some have out of date links to pre-launch/staging servers. 

I found one link that just displays a completely blank page.  I would count that as pretty ineffective on lots of counts !

We are in the final stages of testing a new feature for the Sitemorse service that will test the syntax of any JavaScripts we find as we spider through a site.

JavaScript is in increasing use on all types of web sites, ranging from simple rollover
images and form validation scripts, to complex "Web 2.0"-style dynamic AJAX interactive web applications. These scripts are no less susceptible to coding errors and mistakes than the HTML code that makes up the rest of the web pages they appear on.

Up until now, there has been no way of automatically checking a web site for these errors. Sitemorse's new Javascript testing feature examines the Javascript code used on your site, be it "event handlers" processing keypresses and mouse clicks, or in-line or included scripts, and comprehensively examines it all for syntax errors.

Unlike syntax errors in your HTML that a browser might compensate for, these types of errors will prevent your scripts from performing their intended operation - with results ranging from faulty image rollovers, to missing analytics data, to forms that cannot be submitted, to pages whose major functions fail to operate correctly.

We're finalising the report layout of the results at the moment.  There will be a new section to cover JavaScript and the results will be formatted in a similar way to the Code Quality section.

Initially the results wont affect your Overall Score and will therefore not influence your ranking in our surveys.  Once we have the results from across the many hundreds of sites we audit we'll be in a better position to understand when we should look to include them.

We'll keep you posted on the launch date.

Following on from the previous post, looking at responsibility of providers, the twittering at Sitecore was a little frantic - we weren't trying to offer their client services people 'free' re-tweets, but we acknowledge their thanks for the assistance via this tweet from SitecoreUK to Sitemorse: "thx. agency has bn notified". Shame the Chairman was so aggressive and threatening - something to protect or worse, to hide?... a reminder of the email exchange.

We also noticed there were a number of questions around the capability of the CMS to support accessibility - based on their own marketing (http://www.sitecore.net/en/Products/Sitecore-CMS/Sitecore-feature-comparison.aspx) which states (under the "Site Control Tools" section) that they have an accessibility checker, the most basic of needs we would have thought would have been covered - missing "Alt" text for an image - especially on the home page of their international award winner... come on Sitecore, time to be a little more accurate in your products capability - advise clients of the limitations....

Here's the site, www.stokke.com/​en-us/​, that won Sitecore's International Site of the Year award for 2009.  That's quite an accolade !

So I did a quick Sitemorse Snapshot of the site's Home Page and found that the 3 main product images were missing AltTxt (that's a basic Priority 1 (A) Accessibility failure) and there were 3 associated links to separate product info pages which all said "Read more" (so those are all Priority 2 (AA) Accessibility failures (linktarget).  Both these errors are basic and should be identified by any Accessibility checking, which most CMS vendors claim that they do.

Oh, and from a usability point of view the page also has lots of Flash, so that won't look good on the new Apple iPad ! (or in the Opera browser that's used by the Wii and is probably problematic on several other platforms)

Here's the bottom of the page where the errors are

Here's a larger version

Back to my point on other blogs on this topic.  Are the people responsible for the site aware of these errors ? Would they be happy if they knew they existed ?  I wouldn't think so.  So perhaps they are under the misapprehension that these types of problems can't exist on their site.

More about Sitemorse at www.sitemorse.com

My blog postings over the last couple of days talking about who needs to take responsibility for the quality of an organisations website seems to have stirred up a bit of a hornet's nest.  Sadly it wasn't the reaction I was aiming for but it does reinforce my message that the only people really looking out for the customer is the CUSTOMER,

Our CEO, Lawrence Shaw, emailed the Chairman of Sitecore directly (after being hit with rather a terse response previously in trying to advise them of matters).  In his email he linked to the blog article about Toshiba's Business Communications Division  http://blog.sitemorse.com/2010/02/who-ends-up-in-court---you-or.html, who are a Sitecore reference site, pointing out why our companies should work together.

We haven't had any joy in engaging with them in the past and although we were expecting anything in the range of "yes, let's meet" to "no thanks".  We did not expect the response we did get.

Here are the two emails firstly from Lawrence and then the response.

Lawrence Shaw at Sitemorse [mailto:lshaw@Sitemorse.com]
Sent: 04 February 2010 09:47

Subject: Not the best reference site article Dear Mr Sondergaard,

I've just noticed this on our blog (below), is was posted after something was bought to our attention that we don't think is either correct, or factual -  your sales team claiming that your CMS wouldn't allow broken links etc & external checking services are of no value.

One of our marketing team has now checked your key clients, and we may end up with with some very unhappy people (internally and at the clients) if they have been given a false sense of security, the findings may not be what they want - its also not about shooting the messenger.

We did meet at Internet World a couple of years ago, I did look to follow-up with yourself but your staff were very dismissive of the need for external testing / verification tools.

Yours sincerely,


Lawrence Shaw
C E O

http://blog.sitemorse.com/2010/02/who-ends-up-in-court---you-or.html

And the reply

We have noticed your unauthorized usage of our brand, logo, protected name and trademarks.
The usage not unauthorized by Sitecore and you are instructed to immediate stop using our brand, logo, protected name and trademarks in the marketing of your company.
 
We have asked our lawyers to prepare a lawsuit against you for your slanderous behaviour as well as for your unauthorized usage of our protected intellectual property.
 
Also we noted that thus you have no permission to use Toshiba's brand and intellectual property in the marketing of your boutique you are using this in the public room.
We have advised our customer Toshiba and involved web design agency to both seek legal advice and possible take legal action against you immediately with no further warnings.
 
Best regards

Laust Sondergaard
Chairman

So, no mention of the fact that the customer has a problem.   No mention about how we might help the customer solve the problem.  No "thanks, we'll get straight on to it".

And what is slanderous about pointing out that two very important links on Toshiba's Home Page categorically don't work ? And the use of their trade name comes about because they have a "Powered by Sitecore" at the bottom of the Toshiba webpage (which I didn't notice when I grabbed the screen).

We also spoke to Toshiba again yesterday and though they were angry about the problems existing in the first place they were NOT annoyed with Sitemorse for finding them.

When I checked again this morning the problems have been solved.

It seems to me that this reinforces the message that YOU need to take control and responsibility for ensuring the quality of your Website, you can not rely on the assurances from others.

Access to the Sitemorse Surveys has changed over the years with different levels of access to different people.

A while ago we changed the Public view of the Surveys to be a simple alphabetic listing so that people could easily find themselves in the list, with our coloured blobs showing how well or how poorly the site had performed.  Customers, as always, retained access to the ranked listings so they could see where they were and whether they'd moved up or down the survey rankings.

However, we've found that our Customers not only wanted to see for themselves how they were ranked but were also very keen that everyone else could see how well they were doing in the survey rankings.  So we've decided to change the Public access view of the surveys to show the rankings but to also allow them to sort the list alphabetically so they can find entries easily. (simply click on the column headings)

Hopefully this will satisfy everybody's needs.

It's all about who's ACTUALLY responsible for what goes on with YOUR website.  Marketing blurb and SLAs are all very well but how do you actually measure whether your Design Agency actually delivered the error free, accessible and standards compliant website they said they would ?  Or that your new CMS system delivers on the same promise.

And if they don't come up to scratch what are the legal implications for them ?  Well very limited as these things are so difficult to prove - look at he long running (i.e. years and years) between companies and some of the big consultancies regarding failed projects.

But what about if your Home Page has failing links to content that are a legal requirement.  Who ends up in court then ?  Not them.  YOU.

If we take a look at a page we've mentioned before, the Toshiba Telecoms Home Page, we find 2 broken links. But not just any old broken links. The "Terms and Conditions" and the "Privacy Policy" links don't work, which are a bit more of a problem than the normal run-of-the-mill links as these are both legal requirements.

It's no defence to say "but my CMS vendor said this couldn't happen" or "but my Design Agency assured me that the site was perfect".  It wont wash.  At best it's a plea for leniency.

And if it's reported widely in the press - your reputation is in tatters and your brand is damaged.  Who'll bother to use your site when there are plenty of others to choose from ?

How about the internal Web Team ?  Is anyone telling the CIO/CEO that everything is fine with the site and that they are compliant with all the legal requirements placed on organisations with a website ? I suspect they are because I'm sure no one is saying "we're fine apart from these 2 crucial links on our Home Page".

It's time to raise the game and take quality a lot more seriously.  Take responsibility and take control.  Remember the visitors to your website didn't read the marketing blurb or hear the assurances your Design Agency gave you and there is ALWAYS an alternative for them to use.

Oh and it's worth pointing out that the links have been broken since at least the middle of October 2009 when we first spotted them. (that's over THREE months ago)

Take a look at the full size view

Not even a nice friendly Toshiba branded error page apologising for the inconvenience.

Who told the Hiscox CIO that their website was OK ?

This is a theme we touch on a lot in our conversations with customers, the press and in our blog.  There are things we find through our testing that are clearly unacceptable yet they exist on the websites of organisations and they are there each time we test the sites, not just an unlucky one-off.

So in Hiscox's case we find that their Accessibility Webpage on which they say they are going to work with the Shaw Trust to get their site to meet AA compliance.  That's a good thing to be doing it's just that on this page the main navigation buttons across the top of the page are images and 3 of the 5 don't have AltTxt defined so even on their Accessibility page they fail the most basic of the Accessibility guidelines.  I just can't imagine that anyone with responsibility for the Hiscox website would find these sorts of failings acceptable.  Working with specialist Accessibility organisations like The Shaw Trust is not about solving such simple problems.  That would be a shameful waste of money and the specialist skills of the Shaw Trust consultants.

So why does this situation arise ?  Is this 'accessibility' page simply paying lip service to a legal requirement, are the company kidding themselves or are they being told lies by those testing the site ?  When discussions with the in-house web team or the external design agency take place are either of these groups explaining the exact state of the quality of the website ?  (And, yes, let's broaden it out beyond just accessibility now as we find in our surveys that sites that score low on one category, say Accessibility, of our tests often also score low under our Function and Code Quality categories as well.)

I would doubt that any real, tangible information is disclosed and in its place are mere platitudes and generalities that are intended to placate those asking the questions (assuming that the questions are asked, of course)

So in place of relying on this I'd suggest that regular reports that independently assess and report on the quality of an organisations web estate is the only viable way for those responsible to really know what's going on.

The image below shows the Sitemorse Instant Snapshot view of the page showing Accessibility issues by drawing blue boxes around the problems.  The hover box tells you that there's a missing AltTxt  (which is true of the 3 middle tabs.  And the black arrow shows where they say they will always have AltTxt)  The other blue boxes mostly relate to the use of Deprecated code.

View  full size image

We're not targeting Hiscox in any malicious way, it's just the irony of having such blatant Accessibility issues on their Accessibility page.  If we take a look at a page we've mentioned before, the Toshiba Telecoms Home Page, we find 2 broken links.  But not just any old broken links.  The "Terms and Conditions" and the "Privacy Policy" links don't work, which is a bit more of a problem than the normal run-of-the-mill links as these are both legal requirements.

Again is anyone telling the CIO/CEO that everything is fine with the site and that they are compliant with all the legal requirements placed on organisations with a website ?  I suspect they are because I'm sure no one is saying "we're fine apart from these 2 crucial links on our Home Page".

Oh and it's worth pointing out that they've been broken since at least the middle of October 2009 when we spotted them. (that's over THREE months ago)

Take a look at the full size view

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->