How to Create a Meaningful Web Performance SLA
A good performance service level agreement drives your real user monitoring (RUM) program and ultimately ensures your users consistently enjoy the best possible experience. Here’s how to get started.
With a good service-level agreement, everyone wins. Clients are protected from poor service, while also gaining a clear understanding of what to realistically expect from their supplier. Suppliers are protected from unrealistic client demands, while also benefiting from having a consistent yardstick for meeting expectations, as well as an incentive for exceeding expectations.
Sounds great, right? So why haven’t more companies adopted this practice? There’s a host of reasons, all of which are pretty understandable. These reasons include:
- fear of accountability;
- inadequate tools for reliably measuring performance;
- lack of management buy-in; and
- negative past experiences with poor/unrealistic SLAs.
If we truly care about delivering a top-tier online experience, we need to get over these obstacles. Creating a meaningful performance SLA for your website or web-based application is a key step.
What is a performance SLA?
While a performance SLA is about your customers and their experience using your site, this is primarily an internal document. At a philosophical level, it’s an open declaration within your organization — and a potentially great motivator for making your team accountable for delivering on your promise. At a hands-on level, it’s an actionable document that you can use to drive your real user monitoring (RUM) program.
Here’s a good example of an actionable performance SLA:
“The homepage of our site will load in under 4 seconds measured at the 95th percentile via RUM tests running in New York, LA, and London every 30 minutes. We will measure this SLA at 8:00AM every morning and base it off the last 24 hours of data.”
Short, snappy, and quantifiable — this is an ideal yardstick. Whether you’re a developer or an executive, this is something you can get behind. If you’re looking for a template for your own SLA, this is a great place to start. (Note that I’m not suggesting you use these numbers and test locations. Consider this a fill-in-the-blanks SLA.)
How does a performance SLA complement your ADC solution?
As an example, let’s look at performance SLA from the perspective of a company using one of Radware’s application delivery solutions alongside our FastView solution, which accelerates page load, and our application performance monitoring (APM) solution, which offers real-time monitoring of issues such as performance and resource allocation.
After you determine your performance SLA, you define this SLA within the APM solution. The APM solution tracks, in real-time, the response times of your pages and defined transactions, constantly monitoring these response times against the SLA yardstick that you created.
Every time a page or transaction deviates from this SLA and underperforms, you’re notified. You can immediately identify where the problem is and take corrective measures, such as tweaking resource allocation via the ADC.
Everything comes back to the SLA that you define.
Your performance SLA is a clear target. By combining application delivery, acceleration, and monitoring solutions, you have 100% visibility and control. You always know where you stand in relation to your SLA and what you can do to stay on track.
