Building Frontend Observability in Observe

A few months ago, one of our enterprise customers came to us with a request: "We need frontend observability. Our users are complaining about performance, but we're flying blind on what's actually happening in their browsers, and we want to be able to correlate frontend and backend performance."

We had to be honest that we didn't have a frontend observability product, but we started to explore what’s possible with the platform.

Why Frontend Observability Matters

Modern web applications have gotten super complex. Users access your site from countless different devices, browsers, or geo locations. With so much happening on the frontend, there’s a lot that can go wrong.

Traditional monitoring only tells part of the story. The truth is, you could have a perfectly running backend while your users are struggling with slow page loads, JavaScript errors, or unresponsive interfaces. Frontend Observability bridges this gap by connecting what happens in your users’ browsers and mobile apps with what’s happening on your backend services and infrastructure.

We started with OpenTelemetry's browser instrumentation, but unfortunately it’s far from complete. So we found a mature open-source browser monitoring library and spent a few weeks of engineering effort hacking it a bit to emit OpenTelemetry trace IDs that could be picked up by OTel-instrumented backend services.

Real User Monitoring for Instant Insights into User Experience

Once we got the data flowing, we built out custom dashboards in Observe to provide an overview of how the website was performing. Key metrics include total page views, load-time distribution (with breakdown), and error rate. The customer could slice and dice data by country, OS, browser, etc. to narrow the impact or understand performance by a specific dimension.

After a bit of custom shaping of the data coming from the open-source library, we were able to build dashboards that gave the customer the visibility they needed into their frontend:

Core Web Vitals

Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page. It is not only important to keep track of Core Web Vitals for an optimal user experience, but these metrics are important contributors to Google search results.

• Time to First Byte (TTFB): How quickly your website responds to requests
• Largest Contentful Paint (LCP): When your page’s largest content is loaded
• Interaction to Next Paint (INP): How responsive your site is to user interactions
• Cumulative Layout Shift (CLS): How stable your page is as it loads

Geo Mapping to Understand Website Traffic

By mapping out where their visitors come from, they can quickly spot if an outage is isolated to a particular location or if there’s a sudden burst of traffic from one spot. This provides key business and application performance insights and also helps them narrow down where to focus their troubleshooting efforts.

Performance Breakdown

They can track the performance of their web application right from the moment a user request is initiated – the time it takes in DNS resolution, time spent in making a request, processing and loading the page with a clear breakdown so they can measure and optimize performance.

Transaction Drill Downs

Drilling down into a specific transaction that shows anomalous behavior in load times, or errors gives details about location, browser, OS, and time spent in completing the transaction.

They can also look at performance using Waterfall providing a sequential breakdown of a page load, allowing developers to pinpoint performance bottlenecks and understand how different resources and network requests contribute to the overall user experience.

Correlate with Backend Traces

With the trace ID hack we mentioned earlier, we were even able to get them the unified view their troubleshooters needed from frontend to backend. They can correlate a specific transaction on the front end with the backend trace that fulfilled the request.

Instrumenting Mobile Applications: a proof-of-concept

While the customer's immediate need was browser monitoring, they also wanted to see the art of the possible around Mobile RUM, because they had a lot of users for their mobile apps.

We decided to build a proof of concept. We leveraged Embrace's OpenTelemetry-compliant SDKs, which export telemetry data using OTLP directly to Observe. The integration was very smooth because Embrace had already done the heavy lifting of mobile instrumentation.

As a proof of concept, we built a drill down dashboard into application, device, & OS details, as well as spans, traces, and contextual app logs:

Continuous Observability with Synthetics

By continuously testing APIs, user flows, and endpoints, synthetic tests catch potential issues before they affect actual users. Our customer had requirements around synthetics, and even though we don’t offer a synthetics test runner, we again leveraged our flexible platform to give them a few options: they can test API or application endpoints using OpenTelemetry HTTP Check Receiver and export response data with desired transformations to Observe. Our native integration with cloud providers such as AWS App also provides pre-built dashboards and the ability to create monitors on synthetic test results from one central point.

Interested in Exploring Something Similar?

If you're facing visibility gaps in your frontend applications and want to explore what's possible with Observe's platform, reach out to your account team. They can discuss your specific requirements and help evaluate whether a similar approach might work for your architecture.

Fair warning: this isn't an out-of-the-box solution. What we built for this customer required significant engineering effort, creative problem-solving, and a willingness to hack around the gaps in OpenTelemetry's browser support. But if you're willing to invest the time, the payoff is complete observability across your entire stack – frontend to backend – in one unified platform.