Speed Equals Dollars

I recently returned from a conference where I was told by an attendee that as a result of listening to me talk at a conference a few months back I had made his company “millions of dollars”. I’d helped his team reduce their website’s average page load time from 6 seconds to 2 seconds. Now I can only assume he was referring to the future benefit of the impact of my recommendations but it’s led me to write this post and share some of my thoughts.

Website speed is the most underrated and least prioritised thing in eCommerce. Companies are starting to focus on user experience but are forgetting that speed is one of the cornerstones of user experiences.

Speed Equals Dollars
According to Kissmetrics, 47 percent of visitors expect a website to load in less than 2 seconds, and 40 percent of visitors will leave the website if the loading process takes more than 3 seconds.

There are further studies that show the correlation between conversion rate and load times. Our own real world experience has shown that by decreasing page load time by 1 second we were able to achieve a 1% increase in conversion rate. If a company has annual revenues of $10 million this would equate to an additional $100,000 revenue. Small improvements in speed can yield significant results to your bottom line.

So what are my recommendations?
There are countless websites / blogs dedicated to explaining technically how to speed up your website so I’m not going to repeat any of that here. However I do have two recommendations for the non-technical and if followed makes much of those technical instructions less important.

Use a Content Delivery Network (CDN) and Content Accelerator
A CDN allows your website to be cached on servers around the world and closer to the users. This means that load times are faster regardless of where the user is. However, more importantly using a CDN means that your server is not being contacted for a high percentage of requests and therefore under periods of high load you don’t need to worry about having to scale.

A content accelerator optimises your website content on the fly. So what the technical website will tell you to do can mostly be done by a third party content accelerator meaning less of your developer’s time spent worrying about speed optimisation and more time building out new functionality. (A content accelerator will only speed up your front end (HTML, CSS and Javascript). Your developers must still ensure the backend is optimised for speed and efficiency)

We use section.io for both our content acceleration and CDN. I highly recommend them. They are very hands on and provide a great level of support at all hours of the day (and night).

Educate Your Graphic Designer
Make sure your Graphic Designer understands the importance of website speed and is optimising all the images that are being loaded onto your site. Do not rely on third party plugins to reduce images sizes. Make sure your images are the correct size and quality for your website.

Speed Equals Dollars

Click Frenzy 2012

In the lead up to Mother’s Day Click Frenzy 2013  I was going through my notes from last year and found some of our statistics on how the Booktopia servers performed.

I thought it would be interesting to share this with those of you who are also busy getting ready for the hopeful onslaught.

Peak requests per minute: 19 000
Average requests per minute: 10 000
Average response time: 240ms
Average database calls per minute: 100 000

Good luck to all those involved this year!

Click Frenzy 2012

Do you really need support for your website?

Before you read this and think, “but my website isn’t big enough for all of this”, think what will happen if your site is down for an extended period of time, the door to your store is closed. Not only do you lose sales, but also potential customers who may never come back and may even go social on the matter (think Click Frenzy). The below tips are for websites of all sizes, and should be read in the context of your site’s needs, however I do believe the following relates best to a new site starting from ground zero.

One of the things most commonly forgotten when launching a new website is support. And its never thought about until its too late.

It’s that frantic “My website is down!” call to your developers on the busiest day of the year only to be told, “The application looks fine, there must be something wrong with your servers”.

Now this may seem absurd to you that the person who wrote the code is taking no responsibility for the site being down, but rightfully so, if they have done their job correctly your infrastructure should be decoupled from your application. That is, the application is in no way tied to the infrastructure. So if they tell you the application looks fine, what they are really saying is they can see no errors on the website relating to the code they wrote.

So what can we do about it? How can we make sure this doesn’t happen to you?
Based on my past experiences I have come up with the following list of do’s (and don’ts) when launching your new website and thinking support.

Don’t rely on your developer to setup your production environment’s infrastructure unless they will be supporting it, and even then make sure you get a second opinion.
What a developer uses on their development environment in “single-user-land” doesn’t always suit the real world of concurrent users. The people supporting you should know your infrastructure inside and out, before problems arise. It should be your support team who is designing and building your infrastructure so that when the problems do arise (and they always do), they know what to look for and more importantly can’t pass the buck.

There are two types of support: application and infrastructure.
As I have already alluded to above different people have different areas of expertise and in my experience your infrastructure support team will not take on the application support, it’s a different skill set. Make sure you have a support agreement in place with your developers at the time you sign off the website which outlines their responsibility should there be any problems with the website code.

Make sure backups and maintenance are part of your infrastructure support agreement.
Backups are obvious and understood by everyone but for some reason many people don’t think servers require regular software updates. Servers run on Operating Systems (OS) just like your personal computer does. Now think how often you are being prompted to update your computer’s OS. Servers also require these updates otherwise it leaves them vulnerable to all kinds of issues most importantly security vulnerabilities. Any support agreement should include the regular maintenance and software updates of your servers.

Know your Service Level Agreements (SLAs).
Your SLA is the agreed amount time your support company will take to respond to different types of issues. The time normally is dependent on the severity of the issue and can range from hours to days. SLAs can also include the hours that support will be available. Eg. 9 -5, 24/7 etc. Some support companies may offer significantly cheaper support than others, but this normally comes at the cost of worse SLAs. Think about the cost to your business in lost revenue if your website is down and then check to see if your agreed SLAs match your expectations.

Don’t put a Ferrari engine inside your Datsun.
Infrastructure support teams love to over engineer. It’s the way they can be sure your site will “never go down”. While it’s hard for non-technical people to know what they need and don’t, getting a second opinion is always useful. In general if you are starting up a new site and start hearing terms like “auto-scaling”, “multi-availability zones”, “replica databases”, “reverse proxy cache” you are probably venturing down the over-engineered path. Remember there’s no such thing as a free lunch and these features come at an additional cost. Again, you need to make sure the cost of your infrastructure is relative to the revenue that will be lost should your site have a problem. My advice, if you are just starting up a new site and have no idea what these terms mean, it’s probably too early to be implementing them.

Size matters!
The size of the team / company supporting you matters. When you are first starting out, a single operator who charges by the hour may be the most cost effective way to have “peace of mind” support, but as you grow you will need to be looking for a larger team / company to help support your site. Having the support of a larger team / company means that you have access to a greater brain trust on a wider variety of technologies. Remember a database issue is very different to a web server problem and requires different skill sets.

As you can see I am a big believer in being proactive and having what I call “preventative support”. I see support as more than just insurance that’s there when something goes wrong. It’s better to not have the problems in the first place, than to have a team who can solve them.

In general when selecting the right company for your support make sure they have experience in supporting your application “stack”. Whether your site is written in Java, PHP, Ruby or any other language, ask them about other applications they are supporting that are similar. While cost is obviously another important factor, make sure you trust the company you choose and that their values and professionalism match those of your website.

So who does Booktopia use for support and why?
At Booktopia our infrastructure is supported by Anchor who always go over and above to help us out. We use them because of their experience in hosting applications like ours and because they have a large team whose brain trust has helped us get out of a wide variety of tricky situations in the past. They are also constantly maintaining our servers and advising us of improvements we can make to our infrastructure. We were one of the few major websites that stayed up during Click Frenzy and that’s a tribute to the relationship we share with Anchor.

Do you really need support for your website?