By Theo Despoudis
What do E-commerce, news media, travel, high-frequency trading, and social media platforms have in common? They all compete aggressively for user engagement and rely on great user-experience with performant and sleek websites that look beautiful and run smoothly. To create such websites, web and mobile developers have to make some really hard design and engineering decisions. However, simply deploying a site or new feature isn’t enough, website and applications are living things under constant change as engineering, product, and marketing teams make constant change to satisfy, track, and measure their user-experience. Maintaining a high level of uptime and performance over time, and amidst constant change, gets even more challenging as companies experience success and need to scale. As companies increase deployment velocity, introduce new design and feature components on the frontend, and make major shifts with their cloud infrastructure, increased change can have detrimental effects on the user experience.
Modern engineering teams utilize Real User Monitoring (or RUM) to see how end-users experience their applications in real time. RUM is also known as “field data,” as it’s experienced by real users, across multiple combinations of devices and locations. The addition of RUM within any monitoring suite has two functions: 1. It provides visibility into client-side performance to measure latency experienced across web browsers, within distributed tracing, for example, which visualizes complete web transactions that span browsers, to backend services, to database calls, and back; 2. It helps benchmark and improve user-experience and page performance, giving developers insight into site speed, interactivity, and visual stability, key characteristics of page health. By understanding where latency exists across end-user paths and requests, RUM completes the “end-to-end” view across within the full stack.
This article will explain how using RUM to track performance metrics and user interactions can help organizations troubleshoot errors, and it will also examine the similarities and differences between RUM and synthetic monitoring.
How RUM Can Improve Performance
RUM measures the performance of a website based upon actual user interactions. For example, when a user navigates to the website on the browser tab and hits enter, the tool monitors the whole HTTP request from start to finish. This can include:
- All static files (CSS, JS, images) requested as the page was loading
- Site load metrics (Time to First Byte (TTFB), Time to Interactive (TTI), and core web vitals like Largest Contentful Paint))
- Sessions (an end-user enters and navigates a web page)
- Any errors thrown when loading requests
Benchmark end-user experience:
In order to satisfy customers, you first need to measure customer experience. RUM helps engineering teams measure user-experience, and set performance guidelines as they continue to introduce change
Optimize page performance:
You can measure which page resources and third parties negatively impact end-user experience, and start work and communication across teams to optimize.
Track down and resolve all frontend errors:
Establish and enforce user-centric SLO targets:
With RUM, you can observe the actual, real-world performance of your applications and verify SLO targets. Then, you can set the bar even higher.
Compare new technologies with the existing ones:
For example, you could use HTTP/2 or HTTP/3 for some portions of the traffic and determine if there are any improvements.
The holy grail of frontend web performance is to correlate performance to business outcome. While precise correlation of page speed to customer conversion isn’t possible, performance does significantly impact business outcome and is increasingly seen by users as a feature. Google recently found that sites that met their core web vitals for web health had 24% less abandonment. Understanding the end-user impact of new features and site improvements isn’t possible if RUM isn’t in your monitoring stack. For latency of page resources, bottlenecks in backend service dependencies, or errors, RUM helps engineering teams ensure improvements, design changes, or marketing updates, result in both speed and performance improvements to end-users.
How RUM Compares to Synthetic Monitoring
Now, let’s compare RUM to synthetic monitoring. As you will see, the two actually complement one another.
Synthetic monitoring, otherwise known as “lab data,” simulates end-user requests, typically by spinning up a web browser, and pointing it at a URL or API endpoint. You essentially create artificial requests, at periodic frequencies (eg. 1, 5, 10 minutes apart), targeted at specific endpoints. This proactive approach to 24/7 monitoring helps IT Ops or engineering teams detect, alert, and resolve problems of availability, functionality, and performance across critical business flows and the entire user journey. Specially constructed scripts that emulate end-user interactions run periodically against endpoints and critical business transactions (eg. the log in, check out, authentication services) to help alert, identify, and resolve problems. This process doesn’t require actual traffic; rather, you develop a preconfigured script, typically based on a Selenium-like programming language, to emulate traffic. Then, based on the logs, you define rules that act when certain criteria are met. For example, you might set the following action in case a check fails:
CI/CD Action: If this test fails, fail the build in the CI/CD pipeline
Then, you can trigger a Pagerduty incident or Slack message to notify everyone that you need to resolve the case. Typical use cases for synthetic monitoring include:
The larger your geographical and technological reach, the greater the need to ensure you’re “always up” and fast. Modern enterprises must monitor their critical endpoints, APIs, and business transactions, and alert in the event of outages or failures
Results from Synthetic monitors funnel into SLAs and SLOs for uptime and performance
Web performance optimization:
Synthetic monitoring helps identify and fix performance problems, especially as you test your site before going live, or as you compare builds (A/B testing).
Performing status or health checks:
You can set probes to monitor specific endpoints (such as /status, /health, or /readiness) and to trigger events once those are down.
By setting up synthetic tests across endpoints, business transactions, and user flows, you can begin to understand optimal performance. Synthetic results are often referred to as “lab data” because it’s typically carried out on the fastest networks, with specified endpoints and flows, under fixed conditions. RUM complements synthetic monitoring because RUM collects actual user data sourced from real interactions with your application. Therefore, by configuring both synthetic monitoring and RUM tests, you can obtain a 360° view of your application’s availability, performance, and error handling.
Next Steps with RUM
Collecting RUM data isn’t complicated, and there are many solutions available, depending on the depth you need for measuring page performance or viewing complete transactions and dependencies across the backend. Splunk RUM offers the deepest metrics for modern page performance improvements, and the fastest troubleshooting through unsampled, full-fidelity data, which helps pinpoint issues with end-to-end traces from your web browsers through your backend services. Stand-alone RUM/Synthetics solutions simply can’t provide the full context needed to troubleshoot issues.
Take your first steps with Splunk RUM today! An integral part of Splunk Observability Cloud today, watch this demo to see this in action and then start your free trial of Splunk Observability Cloud.