News Flash: It is March 1st which means there are only 268 days until Black Friday and the start of the holiday shopping season. Will your site be ready for the impending traffic? Will you be able to handle the volume? Will you be able to deliver a positive customer experience that translates into revenue? Does your organization even know what performance means?
There’s a chance that you read the opening paragraph and are saying to yourself, it’s too early. We have other releases to get out before we can start thinking about holiday readiness. Even if this is is the case, I invite you read on and see if the information I share changes your mind.
I am not a big fan of late blooming holiday readiness testing efforts. The organizations that operate in those modes are usually the ones I read about in the “Which websites are choking” articles written every Friday after Thanksgiving.
I generally have a good chuckle when I read about the root causes of the site outages. There are always the sites that make that infamous last minute itty, bitty change that was not supposed to affect anything. Or, my real favorite, we did not think the third party call out was going to be an issue. Ironically post holiday articles typically only include websites that have outages. If sites are just plain slow, there usually is little or no discussion about how poorly these sites performed from a revenue generation perspective. Not to state the obvious, but is that not the main reason a company operates its website?
Website performance is not a seasonal activity—it is a year-round activity that ensures your site continues to operate and generate revenue throughout the year. In my experience, organizations that subscribe to this theory are usually the ones driving revenue.
The goal of this three-part series is to share best practices on how to put this theory into action. One more point before diving in; my topics are method agnostic, thus I do not care if you are Agile or Waterfall or use DevOps, a good basic strategy will work for all.
Specifically, I am going to discuss performance related activities that go to the left of the line (discussed in detail in part two of this series) and to the right of the line (discussed in detail in part three of this series). ”The line” being defined as when code is handed off from the development side to the (traditional) QA testing side. Note I say traditional QA testing. Testing is an activity that should be happening on the left and right-hand sides of the line.
Part one: The first step is understanding that one cannot simply test performance into their site. Site performance is a program that must be addressed and supported throughout the company.
Regardless of what side of the line we are working on, I believe there are three major areas that affect site performance: hardware, software and network. In these three areas, there are things that we can control and things we cannot. In my experience, the two areas we (Dev, QA and Ops) can best control are hardware and software. We do not have as much control over the network. Latency is not a friend. Yes, we can deliver content through a Content Delivery Network which is a great tool that most leverage today. However, we cannot cache everything. you are going to make some calls back to your site origin and likely out to a third-party credit card company when your customer checks out. Did I mention third party marketing tag callouts? Those never affect anything, do they? The bottom line is, once the bits hit the network, things are left to the mercy of network conditions. So we better do what we can to ensure the best user experience wherever we can.
I subscribe to the notion that the left side of the line is where we can achieve the highest and least expensive ROI on performance impact. Part two of this series will discuss the methods organizations can implement to achieve faster performance and counterbalance what happens when we pass control of delivery off to our customers.
Until next time, if you are not planning yet, please start preparing now!!
About the Author
Director of Solutions Architecture at Akamai