How To Improve Single Page Application Health Monitoring — CB Insights Research
We dig into the difficulties of monitoring the client side of a web application along with suggestions on how it can be done to enhance your application’s reliability and end user experience.
Here at CB Insights, we’ve opted to build our web application as a single page application (SPA) using a modern JavaScript tech stack.
In a nutshell, this means that we rely on the user’s browser to use JavaScript to create a webpage and render new states dynamically without reloading the page. There are many pros that come with using SPAs, including improved developer productivity, overall site responsiveness, cacheability, and more.
But one thing that doesn’t get enough attention is monitoring. Since all of the processing is done on the client’s device instead of a web server, there isn’t an easy way to capture events and timing metrics without building something custom or relying on a vendor solution.
Below is an overview of the challenges related to monitoring the client side of a web application along with suggestions for how it can be done to improve reliability of your application and the experience for the end user.
Defining the problem
As a professional web developer, you’ve probably heard the following:
- A customer complaining that the transaction page doesn’t seem to be working in IE11
- Tweets that a site is slow and/or unresponsive
- Blank pages rendering with little to no steps to reproduce
Now let’s say you were deploying new code to production. How confident would you be that it wouldn’t cause any of the aforementioned issues?
Sure, you could do as much synthetic testing beforehand in your staging environment, but without real user monitoring (RUM), you don’t know what your users are truly experiencing.
There are usually outside factors that are difficult to predict like third party vendors, browser plugins, unique user data, and more.
So what exactly should you be monitoring to capture client side errors that may be different from user to user?
To answer that, we have to define what makes up a healthy application.
What makes a healthy application?
There are 3 main components that make up a healthy front-end application:
Few JavaScript errors
Uncaught exceptions can slow or break the experience of your application. If they do occur, you want to be notified immediately so that you can react to it before hoards of customers start complaining.
Acceptable performance
The slower your application is, the more frustrating the experience is for your users — and the higher the chance for abandonment. In general, it is a good idea to at least measure page load time so that you can track it over time and be able to pinpoint application versions that may have inadvertently added in large libraries.
No Functional regressions
In other words, is the application working as intended?
Truth be told, this can be difficult to track depending on your business model, and we recommend working with product and the customer care folks to better understand it.
An example of this could be tracking conversion rate if you are an e-commerce platform.
Considerations when choosing a solution
Every business has different needs, and there are plenty of vendors and open source libraries at your disposal. While we won’t recommend that you use one specific tool to solve all your problems, the bullet points below should help guide you in your decision making process.
Real time metrics
A common idea is to store this data into an existing platform like Google Analytics. While it is a powerful tool, it does come with the caveat that data will not be fully available until 24 hours later, which means you can’t be 100% confident your last deployment was healthy.
It is important that you can retrieve and get alerted on real-time data so you can resolve issues as soon as possible.
Custom metadata tagging
This is the ability to add your own custom data to events so that you can draw from system changes. A few examples include:
- Application version: By adding application version, you will be able to correlate issues with deployments, which will help with identifying offending code changes and resolution.
- Internal user flag: This is helpful in understanding the scope of an issue and if it is customer facing. This flag also pairs well with alerting systems since it could help prevent false positives.
Reasonable alerting system
An alert that fires too often is an ignored alert. Having fine-tuned controls makes all the difference.
Web UI to access data.
If you do decide to build something in house, how much time do you want to dedicate to also build out an internal web app with charts and graphs?
Cost
Most vendors put a quota on the data that you send them, so be sure to take that into account.
If you are unsure of how much you are sending their way, try setting up a trial and getting a baseline first.
It’s important that whatever solution you do decide on, that you avoid being locked into a specific ecosystem. Costs and features can change over time, so you want to make sure that you can handle any vendor changes with little to no disruption to your regular development process.
Originally published at https://www.cbinsights.com.
