With more users, global audiences, and large enterprises as customers, SaaS companies must keep performance and uptime of their applications top of mind.  A downed application or slow pages within an application can mean frustrated users and loss of business.  The market is only getting more competitive, and users are only getting more impatient.

Growth of web apps drives APM sector

Reflecting the need for fast and consistent app performance, there has developed a market of Application Performance Management (APM) solutions.  These solutions monitor the full stack, from backend (servers and databases) to the application layer, to the front end.  And while monitoring the backend is important, end-user experience (EUE) monitoring is the main focus of APM.  (It’s said that 80% of the value of an APM solution is in EUE monitoring.)  And with good reason: optimizing the user’s experience is the whole point of performance.

Currently, EUE monitoring methods center around capturing data on actual users’ experiences through Real User Monitoring (RUM).  With RUM, each time a user logs into the app, data is captured on the timing of the page load events, along with the user’s location and connectivity type.  This data is very valuable: it’s like an automatic customer satisfaction survey for every user.

There are some big holes in this approach, however. 

Mainly, responses to RUM are necessarily retroactive.  Only after users have encountered a problem can the problem be identified and solved.
A further complication with a RUM-only approach is the fact that pages within SaaS apps often vary in performance, and if particular pages get less traffic, there will be less known about them even if they are equally crucial to the user experience when they are requested.  This can leave a SaaS team in the dark as to the full breadth of the application’s performance.

There’s another way?

A more robust approach comes from using real browser monitors to track performance of SaaS apps.  This way, user experience data can be captured without a real user having to be the guinea pig.  Plus, each page within the app can be monitored individually, leaving no rock unturned.

In this post, we’ll show you how to effectively monitor your SaaS app web performance by setting up and interpeting trend data.  We’ll also equip you with actional steps to take to get started.

Let’s look at some examples.

Using Yottaa Monitor and our GoToMeeting (GTM) account, we set up monitors for several pages of the GoToMeeting app.  These pages are fairly simple in terms of content (very few images, very little media) so it makes a good test case for the particular challenges of a SaaS application compared with a regular web page, which is more likely to be altered by the nature of the content on the page.

This trending chart shows the time to interact (a measure of the page’s total load time based on when the user can interact with elements on the page) of four pages from the GTM application.  The data points are averages of a dozen global locations: each time a cycle has completed, including one collection from all locations, they are averaged into the sample plotted.

From this chart it’s clear that there is wide variability in page load time across the seemingly similar pages.  The Meeting History page is very consistent in taking less than 2.5 seconds to load.  That’s a good score for nearly any page on the web.  On the other hand, the home page takes over 5 seconds in almost every sample, and has variability, with spikes up to 10 seconds.

This graph shows the same data, but North American locations were isolated. The spike in load time that occurred at 3:00 on 4/5 is clearly present in the North American samples, as the spike was even higher than the global figures at nearly 15 seconds.  The ‘Schedule a Webinar’ page performed noticeably worse.

This level of insight can only be achieved by real browser monitors. Samples taken at regular intervals regardless of transaction volume provide a detailed trending view, and are much less likely to miss hiccups in performance.

What your next steps should be

1. Establish which performance metrics are most important to you, and create a page load performance service level agreement (SLA) to set standards for optimizing your app.  If you need help starting one, check out our blog post: Best Practices for Creating a Page Load Performance SLA.

2. Set up monitors for your key app pages, some of which might be the user portal, account creation steps, home page, etc.  This will allow you to track page performance over time and log comparative data. Try our free Site Monitor account!

3. Using your monitor account, set up alerts for key user experience issues (such as: “”Time to Interact exceeds 10 seconds””). By setting up critical error alerts on the most important page performance data, you’ll be able to solve any issues in real time.

For more tips on monitoring, read our blog post on 8 Monitoring Tips to Keep your Site Up & Performing Well.

What’s up next…

In Part #2 of this crash course series, we’ll demonstrate ways to drill into the user experience sample data within a waterfall chart and how to identify exactly where the bottlenecks and pefromance problems are.