by Sven Hammar, CEO, Apica
Sven Hammar is co-founder and CEO of Apica, a provider of load testing and performance monitoring for cloud and mobile applications and one of Europe’s fastest growing technology companies. Mr. Hammar he has decade-long experience and expertise in web performance and web optimization, e-commerce, cloud services, IT entrepreneurship and the Internet. He is also a serial entrepreneur who has founded several successful IT companies over the years. See http://www.apicasystem.com/.
Recent public and embarrassing web site crashes of Amazon, Groupon and even Google accentuates the need to take web and mobile performance more seriously. Unresponsive web sites and mobile applications is comparable to a physical shop throwing out its customers and locking its doors. Luckily, there are ways to minimize the risk of slow response times and site crashes. Web performance expert Sven Hammar, CEO of Apica, tells you how.
The web site (and mobile application) is nowadays a hugely important and business critical channel for almost every corporation and organisation. It simply must not slow down, fail or malfunction. Slow response times are as irritating as long queues and lazy cashiers in a physical shop. Even worse, slow response times affect your Google ranking, something surprisingly many marketing managers and web masters fail to understand. Slow response times leads to a lower ranking. And vice versa. So the first task of your SEO program should always be to speed up the web site’s response time.
A slow response time (the time is takes for a web site to fully load) is normally due to the web site’s content managers not being able to resist the temptation to fill the site with cool (?) images, videos or third party content that they cannot control. It might be cool but it comes at a heavy price.
What about downtime, i.e. completely unresponsive (or “crashed”) web sites? Well, that is even worse. An unresponsive web site or mobile application is like throwing out your customers and closing your doors without even putting up a “closed – will be back in…” sign. For a public site, news of the crash will spread like wildfire in social media and traditional media with serious risks to the brand. For any company selling stuff on the web – and there are many – a site crash also means lost revenues. The 40 minute web site crash of Amazon in August is reported to have cost the company $5 million in lost sales.
So what can an organization do to optimize the quality and security of the web site, speed up its response time, minimize the risk of crashes and facilitate business via the Internet?
1. Put vanity aside and reduce the amount of high-resolution images and videos on your site in order to minimize response times. If you still want the bulky images, then be sure and invest in systems that can handle short response times despite a high-resolution content. Use a CDN / accelerator service to speed up the delivery of rich content such as images and videos to customers.
2. Cache as much static content as possible in the browser. If the page content does not change, customers will not have to download it again from the network the next time they hit the page. This is a cost-effective way to speed up web traffic and gain performance improvements.
3. Perform load tests to verify the site’s performance during various load levels. Measure performance during normal variations in traffic. Test the site frequently before, during and after peak season to ensure the availability of reliable information about the site’s normal performance.
4. Analyse the site’s performance. Detailed information about what really takes time is necessary to enable a discussion about which functions can be speeded up (alternatively improve conditions for). Commercial considerations may decide if it makes sense to increase the server capacity. Tests and evaluations show if desired results are attained.
5. Periodically test, monitor and optimize your site to ensure a great consumer experience. Web testing companies can test and optimize your site, simulating peak loads by using ‘synthetic traffic’, and then suggesting improvements. These companies often offer complimentary surveillance services. These services are cloud based.
6. Establish where the maximum performance point for the application lies (i.e. the number of users per minute) in a typical scenario. Additional users create a greater need of URL’s/second and will have to wait or, in a worst case scenario, do not get a response at all at peak load. The key question is: how likely is it that you will experience loads larger that the maximum performance point? Do you need to ramp up the system?
7. Instability during untested operative situations is a common cause for downtime. It is difficult to foresee what will happen at heavy loads, components that function flawlessly at regular loads may all of a sudden become bottlenecks. Do a ”damage control”, a test of what it takes for the site to crash and how the course of events look like. Secure that the site comes up and running again – even at full load.
8. Use a queuing technique; Do only allow the volume that you have tested the site for, and block all / direct to a wait loop ( other traffic above this volume. (Compare with what is allowed into a ”real” store.) Otherwise all users will get poor response times and in a worst case scenario the site ceases to function for all users. It is better to serve the customers who are already in the site and let the others get a polite error message.
9. Verify your Internet capacity and check that your estimated maximum traffic volume does not reach your ordered capacity. If that is the case, do a commercial evaluation; What is it worth to be able to let additional customers into your “store” with a good performance? Make sure than you get what you pay for from your Internet supplier and buy more capacity if you need to.
10. Check that the load sharing is working properly. Load sharing distributes loads from different users onto underlying systems in an even way. However, sometimes there might be errors due to reconfigurations et al. Therefore one must verify that the load sharing really functions properly and that the underlying servers receive an even load.
It should be noted that a web site doesn’t have to be poorly designed to slow down or crash. It can also just become too popular. Groupon’s Indian web site crashed when too many customers wanted to get their hands on a cut-price deal on onions. Conduct a risk analysis using load testing and external performance measurements of service quality to ensure that your site can handle a massive influx of customers without crashing.
To avoid public and embarrassing crashes, preparation is key. Generic website failures and performance problems can be minimized greatly by simply conducting on-going testing and monitoring of the site and its applications, and having a contingency plan that includes system backup.
Analyzing, testing and optimizing your web site and mobile applications is both so easy (with affordable and easy-to-use cloud services) and so valuable that it can be compared to checking your spare tire or fastening your seat belt before a long road trip. You can end up looking really silly if you don’t. If Amazon and even Google can go down, so can your site.