It should be obvious that your site's not working if it's offline or showing error pages - but did you know that problems like this can have an impact long after site is back to normal? And are you aware of the impact slow page load times can have even when the site is otherwise working perfectly?
Selling tickets, taking donations and other e-commerce is just like any other sort of commerce. Success depends heavily both on trust and on you having something to sell when the customer wants to buy it.
If your site is offline or not working properly, it's a mistake to assume potential customers will try again later. At least some will find something else to do with the money they were ready to give you - particularly if they were coming to make a donation. Others will come back, but any regular problem is likely to quickly damage their trust for your site if not your overall brand.
If you're lucky, those who start to lose faith will phone your box office - slowing the gradual move to online and keeping your overhead costs higher for longer. And there's the cost - both of time, and of the opportunity to talk to them about something else - of responding to those more loyal audience members who email for help or write to complain after the fact.
And it's not just UK working hours that matter. For a start, we're all used to the idea that the internet is always there, we always have a connected device in our hand and our lifestyles and shift patterns are changing. Beyond that, search engine crawlers might arrive at any time to keep their indexes up to date - if your site is broken they'll miss out on your latest content and some may even apply a penalty to your search rankings.
But poor uptime is only one way to damage your business. Slow response times - both for the initial page request and the overall time to load all the pictures, scripts and the like - can cause even greater impacts, not least because they can be less immediately obvious.
Numerous studies have shown that users quickly give up on slow sites - especially the 50% using mobile devices where a site that's sluggish on desktop can be unbearable. They visit fewer pages, come back less often and are much less likely to complete a transaction.
In 2006, Amazon found that speeding up their site by 100ms increased revenue by 1% and in 2008 the Aberdeen Group found that a 1 second delay in page load time reduced conversions by 7%. It gets worse - the same Aberdeen Group report found that same 1 second delay gave a 16% decrease in customer satisfaction. The customers that persevered to order were less happy - and less happy customers are less likely to donate and less likely to come back.
Users also find slow sites harder to use - if pages take anything more than 1 second to load they feel less in control and can't so easily keep the whole login, registration or booking process in short-term memory. Users have to concentrate something like 50% harder to use a slow website. If your support staff find they're constantly helping customers who seem to have made bizarre errors or failed to follow a simple process, page load times may be the culprit.
For mobile users in particular, slow response and load times significantly increase the amount of time the user is reliant on a stable internet connection. If the user is on the move, they're far more likely to see error messages and broken pages if their phone has to get a clear window of several seconds to transmit all the data. With social media in particular heavily used on mobile devices, if you're spending time and effort linking from social media to a slow site there's a chance you're doing your brand more harm than good.
Page response time is so critical to user experience that major search engines now apply a ranking penalty for slow sites.
These issues are just as important on sites that aren't facing customers and selling tickets. Participant registration portals, internal staff systems, job application pages - all of these systems can become more confusing, less trustworthy, less productive and more likely to be worked round if they are slow or unstable.
Then there are the direct costs of poor performance. A server that takes three seconds to serve a page has 1/3rd the capacity of a server that can do it inside a second - so you'll need 3 times as many. If your site is configured to scale automatically when the servers get busy, your slow site will be scaling far more often than it would if it was working more efficiently. If you're serving images and static content inefficiently, you'll also be using more bandwidth.
So what can you do?
Engineering a site for performance and uptime is a huge area and can require considerable expertise, and there are companies that specialise in that sort of work (like us!). But there are some basic steps you can take that don't require you to be particularly technical.
Use a content delivery network
Providers like Amazon Cloudfront or Cloudflare sit between users and your website, and accelerate their visit by providing copies of images and other static downloads from data centres near them. For best results, you'd build your site with CDN use in mind, but even just adding them to an existing site can make a dramatic improvement. Cloudflare will even tweak your content as it goes through to fix some of the most common server-side performance issues, and you don't have to be particularly technical to set it up.
Audit your performance
Tools like WebPageTest can give a good overview of performance and should be a vital part of your user acceptance testing for a new site. Run them yourself, and make sure any warnings and recommendations are followed up.
Limit the number of pictures
If you have a carousel on your homepage, don't use it. Pick the one big thing you want to tell your customers, and put that image there. There's now lots of research showing that carousels look pretty but deliver really poor usability and appallingly low clickthrough for the space they take up. If you must keep it, absolutely minimise the number of images you put in it. Each one will slow down your homepage load time.
Use pictures that are the right size
Your CMS should ideally automatically resize the images you upload. If it doesn't, make sure you scale images down to the size they'll be shown on the site. Sending a full-quality photo that will only be displayed as a thumbnail wastes enormous amounts of time and bandwidth. For bonus points, run your images through a compression tool to squeeze out every spare bit of data.
Tender for performance
Response time and availability targets should be part of your tender for any new site, and you should ask bidders to demonstrate the results they've achieved on past projects. Don't be fobbed off with the service level agreement of the hosting provider they've chosen - the vast majority of issues we've seen are more to do with how a site is built than the servers it's hosted on.
Run WebPageTest against the portfolio sites they send you, and quizz them on any failings at the interview stage. Ask about their process for setting up and configuring servers - if they can deploy your site onto a brand new server with almost no human interaction, there's a good chance you can get the site back up and running (potentially triggered by an automated system) with barely a minute or two of downtime. Servers are only computers - they all crash eventually, or the data centre goes on fire, or.... - if your machine has to be rebuilt from scratch by hand you could be offline for hours, or days if your supplier has more than one client and others are shouting louder.
Isolate third-party systems
If your website integrates with any other service - your box office, Flickr, Youtube, Twitter - be sure that you specify and test that it should work reliably and fast even if those services are broken. External services all break at some point, and your users should still be able to browse your site (though there may be some things they can't do) when that happens.
Measure and monitor
Most importantly, you can't improve or manage what you don't measure. You should be routinely monitoring the uptime and response time of your website as one of your key performance metrics. You can get some basic data (and suggested fixes) from Google Analytics - check the site speed section under the behaviour menu. While this is useful for measuring real-world overall speed, it's skewed by the browsers, network connections and geographic locations of the users who happen to be on the site at the time. It's also based on sampled data, and won't give you the sort of 24/7 ongoing coverage you need.
Services like pingdom can check your site as often as every minute, from a wide variety of locations around the world, and log availability and response time. You can set up simple "load this page" tests, or more complex scenarios that cover more of your systems perhaps involving logging in or putting a donation in the basket. Not only does this give you easy access to reporting, but they can also be set up to alert you any time the site goes offline.
Whoever runs support and maintenance for your website really should be using one of these tools - and they should share the regular performance reports with you and be able to explain any outages or increases in response times. If they don't, or you don't have an active support contract, you can set up pingdom easily yourself for about £80 a year to cover a single website and perhaps a couple of microsites. It's a small price to pay compared to the potential costs of a slow or broken website, and means you'll know about and have a chance to fix problems before your customers find them.
As you might have guessed, we take performance and stability pretty seriously. If you've been on our homepage, you'll see that we publish realtime charts of availability and response times averaged across all our active client sites. The figures are taken from our pingdom monitoring systems, with a quick and dirty script that we wrote and plotted using the excellent open source cubism graphing library using another quick and dirty script. Bear in mind that not all of the sites we support are public facing, and they don't all have 24/7 support contracts all year round. We also sometimes have to take a site offline for planned maintenance, which will (rightly) show as downtime on the charts. There'll also be occasional blips if one of pingdom's monitoring servers somewhere in the world can't get a network connection back to us.
We thought about tweaking the data to hide those sorts of planned or "not-really-downtime-downtime", but then decided that would be a lot of hassle and not very transparent. So we've published the figures as-is, without moderation, and hope you'll take it as positive that we're confident and rigorous enough to show almost 100% uptime rather than focusing too much on the "almost".
Thanks to strangeloop networks for the infographics used in this post.