Three web performance SLAs every site owner should consider
1 Apr 2013
In recent podcast chats with Tim Morrow, Mark Jennings, and Geoffrey Smalling, the topic of performance service level agreements keeps coming up, and I think the topic merits a post. Here’s why.
With a good SLA, 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? A bunch of reasons, all of which are pretty understandable, such as: fear of accountability, inadequate tools for reliably measuring performance, lack of management buy-in, negative past experiences with poor/unrealistic SLAs. But if we truly care about delivering a top-tier online experience, we need to get over these obstacles.
There are three key areas that would benefit from having a solid service level agreement in place:
1. Customer-facing performance SLA
I’m not the first person to champion this idea. People like Jonathein Klein and Stephen Thair have been making eloquent calls for this kind of public performance contract over the last couple of years. To be frank, I don’t think most customers would ever read it (though if asked, the average person would probably tell you they think it’s a good idea because speed matters to them).
But I think the real value of this kind of performance SLA is internal: making a public declaration is a potentially great motivator for making your team accountable for delivering on your promise.
Back in 2011, Jonathan shared an example of what I still think is the best performance SLA I’ve come across:
“The homepage of our site will load in under 3 seconds measured at the 80th percentile via synthetic tests running in New York, LA, Seattle, and Miami every 30 minutes. We will measure this SLA at 8:00AM every morning and base it off the last 24 hours of data.”
This is a perfect yardstick — it’s short, snappy, and quantifiable. 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.
2. Third-party provider SLA
Third-party scripts are one of the most common points of failure for sites. At best, unoptimized scripts can slow down your load time, sometimes by many precious seconds. At worst, third-party outages can stall page load completely.
The average top ecommerce site contains 7 third-party scripts, with some sites containing up to 25 scripts. Yet despite this proliferation, most third-party providers don’t offer real-time monitoring of their scripts, nor do they offer meaningful service level agreements (SLAs). In my experience, the only way most people discover third-party SPOFs is by accident, when they visit their own sites.
Sure, you can defer many of your scripts so that they load last, but this isn’t always an option — for instance, when it comes to your third-party ads.
I dream of a world where all third-party providers offer clear performance service level agreements to site owners. In my ideal world, these SLAs would:
- Express their annual uptime guarantee as a percentage (ideally, as close to 100% as possible).
- Describe the process for reimbursing site owners (if site owners are paying for the service provided by the script) if uptime drops below the SLA guarantee.
Tag management companies have been jumping into the fray, with several vendors stating a clear focus on performance. This is a great start. My hope is that, as site owners become more educated about the importance of page speed, they’re going to start demanding properly optimized scripts, as well as better monitoring, reporting, and accountability.
For more detailed tips on how to create a meaningful third-party SLA, check out this great post over at Catchpoint.
3. Cloud provider SLA
The cloud offers huge benefits, but it also introduces a huge new area of vulnerability. It’s understandable that we’re tempted to demand control over the performance of our cloud-based applications, because this (or at least the illusion of it) is what we had before the cloud.
This demand is ultimately unrealistic. However, it is realistic to expect that, in exchange for losing some of the infrastructural control you used to have before you deployed your apps to the cloud, you should be able to ask your provider for more visibility and assurances in how their infrastructure will perform for you.
Here’s what it’s fair to ask from your cloud provider:
- Analytics tools – You should continue to use the performance monitoring tools you already use to monitor your app performance with (WebPagetest, Keynote, Gomez, etc.), but you also need a new visibility toolset (that your cloud provider should help you with) so you can do root cause analysis over parts of the infrastructure that you don’t have control over or visibility into.
- Detailed performance clauses in your service level agreements – Some cloud SLAs contain a performance clause that addresses availability, but speed is every bit as important as — and possibly more important than — uptime. This clause needs to spell out how your concerns about site speed will be addressed, should they occur.
I’m very curious to learn about other people’s successes and failures with performance SLAs. Have you come across an SLA that rocked your world? Is there another type of performance-related SLA I haven’t considered? Feel free to share in the comments, or email me directly at joshua [[at]] webperformancetoday [[dot]] com.
As I wrap things up for the holidays, I thought it would be fun to see which posts over the past year have most sparked people’s interest. I wasn’t too surprised to see that some of the most popular pieces were about sexy topics like page growth, business metrics, rogue third-party content, and the psychology of web performance. But it was really cool to see that people were reading and passing along “Performance 101″ type pieces about latency and terminology. I take this as a great indicator that there are a lot of people out there on a mission to preach the gospel of performance.
