Frontend Observability: Instrumentation, Sentry, and Real-User Metrics

Overview

Frontend observability is the practice of making the behavior of a user’s experience visible, measurable, and actionable. It bridges the gap between developers and real users by converting events that happen in the browser into signals you can monitor, alert on, and act upon. A robust observability setup typically covers three pillars: instrumentation (collecting data), processing and storage (where data goes and how it’s shaped), and analysis/visualization (how you derive insights).

In this post, we’ll focus on instrumentation techniques for frontend apps, how Sentry can handle both errors and performance data, and Real-User Metrics (RUM) to understand how real users experience your site.

Instrumentation: what to collect

Effective frontend instrumentation starts with prioritizing data that helps you diagnose issues quickly and improve user-perceived performance. Consider:

• Core performance timings
  • Navigation timing: page load, DNS lookup, TCP handshake
  • Core Web Vitals proxies: Largest Contentful Paint (LCP), First Input Delay (FID), Cumulative Layout Shift (CLS), Interaction to Next Paint (INP)
  • Time to Interactive (TTI), Total Blocking Time (TBT)
• Resource timings
  • Time taken to load key assets (scripts, CSS, images)
  • Latency to first render for critical resources
• Errors and exceptions
  • Unhandled errors, rejected promises, console error logs (with care for noise)
  • Network failures and HTTP error responses
• Custom and business events
  • Route changes, page transitions, API call durations, user journey milestones (e.g., “add to cart” flow time)
• User/session context (privacy-first)
  • Anonymous session IDs, user identifiers that are hashed or pseudonymized
  • Environment and feature flags (e.g., production vs. staging)

A tiered approach helps: start with core metrics that affect perceived performance, then gradually add custom events tied to your business goals. Always respect privacy, and consider sampling to limit data volume while preserving signal.

Sentry: covering errors and performance

Sentry provides a cohesive way to collect frontend errors and performance data in one platform. Two main streams matter:

• Error monitoring
  • Capture unhandled exceptions and rejected promises
  • Automatic integration with window.onerror and window.onunhandledrejection
  • Breadcrumbs to show context leading up to an error
• Performance monitoring
  • Transactions and spans to trace user actions through the app
  • Sampling (tracesSampleRate) to control data volume
  • Release and environment tagging to correlate issues with deployments

Getting started typically involves initializing Sentry with the browser tracing integration and a sensible tracesSampleRate. A minimal setup example:

import * as Sentry from "@sentry/browser";
import { Integrations } from "@sentry/tracing";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  release: "frontend@1.0.0",
  environment: "production",
  integrations: [new Integrations.BrowserTracing()],
  tracesSampleRate: 0.2, // sample 20% of sessions
  beforeSend(event) {
    // scrub PII if present
    if (event.user && event.user.email) {
      delete event.user.email;
    }
    return event;
  }
});

Beyond initialization, you can start and finish manual transactions around meaningful interactions, such as page loads or complex user flows:

const transaction = Sentry.startTransaction({ name: "Home Page Load", op: "pageload" });
window.addEventListener("load", () => {
  transaction.finish();
});

Breadcrumbs, user context, and tags (e.g., route names, feature flags) help you correlate frontend issues with user journeys. Sentry also supports performance monitoring in SPAs with automatic instrumentation for route changes and network calls, which can be fine-tuned via sampling and custom spans.

Real-User Metrics (RUM)

RUM refers to collecting metrics from real users as they interact with your application. It complements synthetic monitoring by capturing what actual users experience under real network conditions and device capabilities.

Key RUM metrics to track:

• LCP (largest contentful paint): when the main content is likely visible
• FID (first input delay): responsiveness to user input
• CLS (cumulative layout shift): visual stability during loading
• INP (interaction to next paint): broader measure of interactivity beyond FID
• TTI/PTI (time to interactivity): when the app becomes fully usable
• Resource load timings and failed requests
• Error rates and retry counts per user session

How to approach RUM:

• Instrument with methodically sampled data to balance signal with cost.
• Tie RUM data to user sessions and traces to understand how performance translates to outcomes.
• Respect privacy: scrub personal data, provide a way for users to opt out, and aggregate data for dashboards.
• Combine RUM with server-side traces to correlate frontend performance with backend behavior.

Sentry can ingest RUM data alongside errors and traces, enabling a unified view of user experience. Other tools exist as well, but a tightly integrated RUM + error + tracing setup simplifies correlation across the stack.

Instrumentation patterns and best practices

• Start with the critical path: focus on metrics that directly impact user-perceived performance and error rate.
• Instrument by route or page boundary to correlate user journeys with performance and errors.
• Use trace IDs to link frontend transactions with backend traces for end-to-end observability.
• Adopt a sane sampling strategy: enough data to spot issues, but not so much it becomes costs and noise.
• Centralize data collection with a small set of well-defined events and attributes (e.g., route, user tier, feature flags).
• Implement data governance: scrub PII, set retention policies, and ensure compliance with privacy regulations.
• Validate instrumentation in staging with synthetic workloads before releasing to production.

Example integration plan

• Phase 1: Error and basic performance observability
  • Enable Sentry’s browser tracing with a reasonable tracesSampleRate
  • Capture unhandled errors and rejections
  • Add breadcrumbs around major user actions (navigation, API calls)
• Phase 2: Real-User Metrics and business signals
  • Enable RUM data collection to capture LCP, CLS, FID, INP, and TTI
  • Add custom events for key business milestones
• Phase 3: End-to-end tracing
  • Correlate frontend transactions with backend traces using trace IDs
  • Create dashboards showing error rates, performance trends, and business metrics
• Phase 4: Privacy and governance
  • Ensure PII scrubbing in beforeSend
  • Implement data retention and user opt-out controls

Conclusion

Frontend observability is not a one-size-fits-all feature; it’s a disciplined practice of instrumenting the most impactful parts of your user experience, integrating error and performance data, and collecting Real-User Metrics to guide improvements. By leveraging a cohesive setup with Sentry for errors and performance monitoring and a thoughtful RUM strategy, you can identify issues faster, understand how real users experience your app, and drive meaningful enhancements that resonate with users.