A service-level agreement (SLA) is a contract or commitment between a service provider and their customers that defines the service standards the provider is responsible for. Agreements can be legally binding, or in the case of web page or application performance SLAs, an agreed-upon standard within an organization to its users or customers. Implementing a performance SLA reinforces your organization’s commitment to the user experience and ensuring a (hopefully) happy customer and many return visits.
Creating a Performance SLA
For legacy sites and applications that have been in production for an extended amount of time, it’s a bit easier to determine SLAs. You can look back historical customer data or recent user behavior. For example, when you see spikes in customers suddenly abandoning their shopping cart, or just jumping off your site or application at a specific point, it’s likely they encountered a performance issue of some kind. Factors like these can be used to form the base of your SLA parameters.
Obviously, new applications and web pages don’t have the convenience of having tons of usable data at your disposal. It can be difficult to know where to start. How are you really going to know how your page or application responds to actual traffic, without having any real data behind to begin outlining SLAs?
It is important that your SLA be as specific as possible from the start. A quick Internet search can bring up a lot of examples, but you’ll want to ensure that your SLA is specific to your customers, their location, time of day, the devices and/or browsers they use, etc. Tie those pieces together with your page or application load speed metrics, such as time to last byte (TTLB), time to display, or DNS resolution time, along with acceptable thresholds, and you’ve got yourself the beginnings of a performance SLA.
Baseline Performance Metrics
In today’s world, most users will abandon your site after just a few seconds. Ensuring you set appropriate performance SLAs is critical. Thankfully, there are few places to look that can get you started on the path to defining the various parameters that go along with your performance SLA.
- Internal Teams. Obviously, one the easiest, and most convenient methods to help define your SLAs is using your own teams. They’ve more than likely been down that road before, so they are more likely to give great real-world insight into what exactly to include and/or avoid.
- Industry Benchmarks. Tools like Google Analytics can give you insight into how your current site compares to other sites in similar industries. Additionally, various marketing/SEO agencies have loads of industry data that they publish regularly.
- Competition. Competitiveness breeds excellence, right? At least that’s how the saying goes. So, look to your competitors for insight. One easy, non-intrusive way to do this is to run a free speed test against their site to get quick insight into the various performance metrics. If it’s transaction-based timings and real-user behavior you’re after, like for web applications, you can create a script and spin up a small number of virtual users against their application. But be careful not to go overboard. Too many virtual users could cause their applications to fail, alerting their IT team and potentially get your IP blocked. Not good. Worse yet, you could unintentionally cause a DDoS attack, which is illegal. Don’t do anything potentially illegal. Always good advice to follow.
Validate Performance SLA or Non-Functional Requirements
Once baseline performance values are known, you can increase the numbers to something that might be realistically expected during a visit to your site or application during a sample period. The LoadView platform gives users several different load test curves to choose from. One of those options is called the Goal-based curve. It’s ideal for validating SLA and non-functional requirements.
For example, if you already have a predetermined transaction goal, or know (approximately) the number of visitors you expect on your website or application during a specific time period, running a Goal-based curve test will help confirm your site or application meets the pre-defined requirements. Furthermore, generating increased load on a websites or applications can help predict application performance for heavier user load in the future. This is typically done for capacity planning.
Performance SLA Review and Continuous Monitoring
Interested in learning more about real browser-based testing with LoadView? Schedule a demo with one of our performance engineers today to see LoadView in action. Our team will walk you through the whole platform and process, from setup and scripting to execution and reporting. View and analyze actual performance of your sites, applications, and APIs under load. The LoadView platform provides several different reporting metrics and reports, such as test summaries, individual session reports, waterfall charts, and performance by devices.
Or try the platform for yourself today. We’ll give you up to 5 free load tests with LoadView load tests.
Website and Application Performance Monitoring
After your website or application goes into production, the scripts that you created during performance testing should be uploaded into monitoring platform for continuous monitoring. This ensures you’re meeting your SLA and provides data when it comes time to review and make any necessary performance improvements and changes over time. More importantly, setting up continuous monitoring allows you to get alerted the second issues arise, ensuring a small issue doesn’t end up causing big problems. Also, if you are launching a new application, implementing monitoring can provide you and your teams with data need to make small performance adjustments that may make all the difference to users.
The LoadView solution is just one part of the full Dotcom-Monitor suite of performance testing and monitoring solutions that includes monitoring for web pages, web apps, infrastructure, and web services (SOAP/REST APIs). Set up monitoring devices for all your business-critical sites and applications so you get notified if uptime, availability, or performance thresholds are not met or if errors occur. You don’t want to have to hear your site or application is down from customers or visitors. By then, it may have impacted many potential customers, costing the business significant revenue.