New Relic Browser is a mature enterprise observability module. AuditJet is purpose-built for Core Web Vitals, SEO performance, and revenue impact. This page explains how RUM works — and when each tool is the right choice.
Background
New Relic was founded in 2008 and was one of the first companies to build a commercial Application Performance Monitoring (APM) platform. In APM's original framing, “application performance” meant backend application performance — the latency of database queries, the throughput of API endpoints, the resource usage of server processes. New Relic, along with AppDynamics and Dynatrace, defined this category in the late 2000s and sold it to engineering and operations teams at large enterprises.
New Relic Browser emerged as the industry recognised that APM's backend focus left a significant blind spot: the browser. A server-side request might complete in 50ms, but if the JavaScript bundle takes three seconds to parse and execute, users experience the page as slow regardless. New Relic extended its observability reach to the frontend with a JavaScript agent that could capture page load times, JavaScript errors, and — eventually — Core Web Vitals from real user sessions.
Today, New Relic Browser sits within a full-stack observability platform that also covers infrastructure monitoring, distributed tracing, log management, synthetic monitoring, and alerts. Its target users are engineering teams who are already committed to the New Relic ecosystem for backend observability and want to correlate frontend and backend performance in a single platform. The value proposition is vertical integration: a slow page load in New Relic Browser can be linked directly to a slow database query in New Relic APM — the same trace, the same tool, the same dashboard.
In the market, New Relic competes with Datadog RUM, Dynatrace Digital Experience Monitoring, and Elastic APM for the full-stack observability buyer. For the frontend performance buyer specifically — teams focused on Core Web Vitals, SEO health, and conversion optimisation — it competes with tools like AuditJet, SpeedCurve, Calibre, and DebugBear. These are different buyers with different workflows, and the distinction matters when choosing a tool.
Technical Primer
Real User Monitoring captures performance data from actual users' browsers as they navigate your site. Unlike synthetic testing — which simulates a user from a controlled server environment — RUM measures what real users on real devices and real networks actually experience. A user in rural Ohio on a 4G connection loading your site on a three-year-old Android phone will have a fundamentally different experience from a synthetic test run on a high-powered server with a fibre connection. RUM surfaces that distribution.
RUM works by injecting a JavaScript agent into your pages — typically 10 to 30 KB of minified code loaded via a <script> tag in the document head or via an NPM package bundled with your application. This agent hooks into browser APIs to observe performance events as they occur. When a user loads a page, the agent begins collecting timing data from the moment the navigation starts: DNS resolution time, TCP connection time, time to first byte, DOM content loaded, and eventually the metrics that constitute Core Web Vitals.
Modern browsers expose performance data through the PerformanceObserver API. A RUM agent calls new PerformanceObserver(callback) and subscribes to entry types: largest-contentful-paint for LCP, layout-shift for CLS, event for INP, and longtask for main-thread blocking. The callback fires whenever the browser records a matching entry, allowing the agent to capture metrics as they happen rather than polling after the fact. This is why RUM data reflects the actual progression of user experience — the agent is notified in real time by the browser engine itself.
At scale, collecting and storing performance data from 100% of sessions becomes expensive — both in terms of data ingest costs and the server capacity required to process it. Most RUM tools address this through sampling: capturing data from a representative subset of sessions (often 10% to 30%) and extrapolating to the full user base. Sampling introduces statistical error, particularly for low-traffic pages or rare device configurations, but makes the economics of large-scale RUM viable. The trade-off is worth understanding: a p75 LCP calculated from a 10% sample will be close to the true value but not identical. For trend analysis and regression detection, sampled data is usually sufficient. For precise performance budgeting, you may need higher sample rates.
Beyond per-page metrics, RUM tools like New Relic Browser capture session-level data: sequences of page views made by a single user within a browsing session. Session data enables features like session replay — recording DOM mutations and user interactions as a structured log that can be replayed visually — and funnel analysis — tracking how users move through a conversion flow and where they drop off. Session data requires storing considerably more information than per-page aggregates, which is why session replay is typically gated behind higher pricing tiers.
RUM agents typically also capture JavaScript errors by hooking into window.onerror and window.onunhandledrejection. When an uncaught exception occurs, the agent captures the error message, stack trace, browser version, and the user's session context. This is technically distinct from performance monitoring but runs in the same agent because the context — what the user was doing when the error occurred — is essential for debugging.
Feature Breakdown
New Relic Browser captures LCP, INP, and CLS from actual user sessions using the PerformanceObserver API. These are the same metrics Google uses for Search ranking signals (via the Chrome User Experience Report), but derived from your specific visitors. The p75 distribution — the score at the 75th percentile of your users — is what matters for ranking. New Relic surfaces this distribution broken down by page URL, country, browser, and device type.
New Relic Browser can record session replays — serialised DOM mutation logs that reconstruct exactly what a user saw during their visit. When a user hits a JavaScript error or experiences a slow page load, you can play back the session to see the precise sequence of events. Session replay is best-in-class for debugging production issues that are difficult to reproduce in development. It is available in the Browser Pro tier.
The same agent that collects performance metrics also captures uncaught JavaScript exceptions with full stack traces, error rates over time, and an analysis of which errors are impacting the most users. Because errors are captured in the same session context as performance data, you can correlate a spike in JS errors with a performance regression or a specific deployment. This is more tightly integrated than running a separate error tracking tool.
This is New Relic's most distinctive frontend capability. When a page makes an API request that is slow, New Relic Browser can link that frontend event to the trace in New Relic APM — following the request through the API gateway, the application server, and the database query that caused the latency. Full-stack trace correlation turns 'the page is slow' into 'the /api/products endpoint is slow because of an N+1 query in the product service'. This is uniquely powerful for engineering teams doing production debugging.
New Relic Browser automatically instruments XMLHttpRequest and fetch calls, capturing the latency, error rate, and throughput of every API call your frontend makes. This is particularly useful for single-page applications where the initial page load is fast but slow API calls cause the perceived load time to be poor. AJAX monitoring data integrates directly with APM traces when distributed tracing is enabled.
New Relic charges primarily by data ingested — gigabytes of telemetry sent to their platform per month. The free tier includes 100GB/month. Beyond that, you pay per GB. For Browser specifically, the data volume depends on the number of sessions, the sample rate, and which features are enabled (session replay data is significantly larger than metric-only data). This aligns cost with usage but can make monthly costs difficult to predict for high-traffic sites with variable traffic patterns.
Genuine strengths
Honest limitations
Key insight
New Relic Browser is a module in an observability platform. Its value compounds when you're using New Relic for everything — APM, logs, infrastructure, traces, and synthetics. The distributed tracing capability that lets you correlate a slow page load with a slow backend query only works because New Relic is instrumented across your entire stack. If you're considering New Relic Browser in isolation, you're evaluating a feature without the product that makes it uniquely powerful.
This matters because it changes the economics. If your team is already a New Relic customer — paying for APM and infrastructure monitoring — adding Browser monitoring is a marginal cost that unlocks significant additional value. If you're evaluating New Relic specifically for web performance monitoring, you're taking on the cost and complexity of an enterprise observability platform to solve a problem that a more focused tool handles better and at lower cost.
The category distinction matters too. APM (Application Performance Monitoring) and Web Performance Monitoring are different disciplines serving different goals. APM is an engineering reliability discipline: it answers “is the system healthy and functioning correctly?” Web performance monitoring is a UX and SEO discipline: it answers “are users having a good experience, and are our pages fast enough to rank and convert?” APM tools are built for engineering teams managing infrastructure. Web performance tools are built for the intersection of engineering, SEO, and product — teams optimising for user experience and business outcomes.
The billing model reinforces this. New Relic's data-ingest pricing means a traffic spike — a viral article, a holiday sale — doubles your bill. For a business where high traffic is good news, paying more for observability during your best moments is a strange incentive structure. Flat-rate pricing, as AuditJet uses, decouples cost from traffic and lets you monitor confidently regardless of volume.
The rule of thumb
If New Relic is already your observability platform, Browser monitoring is a natural extension. If you're starting from a need to improve Core Web Vitals and SEO performance, starting with a focused tool that speaks that language — and connects to revenue — is the better path.
Direct comparison
Honest positioning requires acknowledging that these tools have genuinely different strengths. New Relic Browser wins on the capabilities that flow from being part of a full observability platform. AuditJet wins on the capabilities that come from being purpose-built for the CWV and SEO performance workflow.
| Capability | AuditJet | New Relic Browser |
|---|---|---|
| Core Web Vitals monitoring | Hourly synthetic + real-user CWV tracking. Regression alerts with context. | RUM-based CWV from real sessions. PerformanceObserver-based collection. |
| Distributed tracing | Not supported — AuditJet is browser-side only. | Core strength: connect a slow page load to a slow backend query. |
| Session replay | Not included — use New Relic or FullStory alongside AuditJet. | Available in Browser Pro. Best-in-class for production debugging. |
| JS error tracking | Not included — use Sentry or New Relic for error tracking. | Included in the same agent. Correlates errors with session context. |
| Revenue impact modeling | Connects CWV scores to estimated conversion loss and revenue impact. | Not available. |
| AI Fix Blueprints | Code-level fix guidance per performance issue (Watchdog+ plans). | Not available. |
| Competitor benchmarking | Scan competitor CWV scores on your monitoring schedule (Pro+). | Not available. |
| Agency / multi-client workflow | Built-in: white-label reports, client grouping, multi-site dashboards. | Not designed for multi-client workflows. |
| Pricing model | Flat rate $49–$499/month. Traffic spikes don't change your bill. | Data-ingest billing. Costs scale with session volume and features. |
| Setup complexity | URL-based synthetic monitoring: no code changes required to start. | JavaScript agent requires deployment. Distributed tracing requires backend instrumentation. |
The honest recommendation for teams evaluating both tools: if you are already running New Relic for backend APM, keeping New Relic Browser for session replay and JavaScript error tracking makes sense — those capabilities are best-in-class for production debugging and the marginal cost is reasonable. Use AuditJet specifically for the CWV and SEO performance workflow: scheduled synthetic scans, real-user CWV aggregation, revenue impact context, AI fix guidance, and competitor benchmarking. The two tools are complementary rather than mutually exclusive.
For teams not already on New Relic — evaluating their first web performance monitoring tool, or looking for a focused alternative to a complex enterprise platform — AuditJet gives you the performance workflow without the observability overhead. You get the metrics that matter for SEO and conversion, connected to business impact, with guidance on what to fix. That's a meaningfully different value proposition.
Use New Relic Browser if
Use AuditJet if
Frequently asked questions
Get started
AuditJet gives you everything you need to monitor, understand, and improve Core Web Vitals — with revenue impact context and code-level fix guidance. No enterprise overhead. No data-ingest surprises.