CoreDash vs New Relic Browser

New Relic is an APM platform first

If your backend already runs on New Relic, Browser monitoring might already be on, and if it isn't you can have it running this afternoon. The APM agent can inject the browser script for you, so no template changes. That's a fine reason to use it as your RUM tool.

I built CoreDash, so this page isn't neutral. I'll try to be fair, and with New Relic that's not hard, there's plenty that's good about it.

What New Relic Browser does well

Most important: it can do something no RUM-only tool can, CoreDash included. With distributed tracing you can follow a slow page into the backend service, the database query and the host it ran on. When a bad TTFB turns out to be a slow SQL query, New Relic shows you the query. I tell clients all the time that their TTFB problem is on the server. New Relic customers can actually go and look.

newrelic.com, October 2026.

The Core Web Vitals data is also better than people tend to think. The browser agent source is public on GitHub, and version 1.322.0 includes Google's web-vitals 6.2.1 with attribution. So every LCP comes with the four subparts (TTFB, load delay, load duration, render delay), the element selector, tag and resource URL. INP comes with its three phases, the interaction target, interaction type and load state. CLS records the element behind the largest shift, its value and when it happened.

Some other things I like:

• Session Replay is hooked into the Core Web Vitals tables and shows the poor LCP sessions first, so you can watch the actual visit where LCP took six seconds instead of looking at a percentile.
• NRQL. Every attribute on every event can be queried, your own custom attributes too, and you can build a dashboard or an alert on any of it.
• The free tier: 100 GB of ingest a month and one full-platform user. That's generous.
• Frequent agent releases, and it handles SPAs and micro-frontends. Their Ground Truth MCP server went GA in September 2026.

If you already use it

If you measure your real visitors with New Relic today, you're ahead of most sites I see. Those are still guessing from Lighthouse runs and waiting 28 days for CrUX to tell them something broke. If it answers your questions, keep it. The rest of this page is about what happens after months and years of data.

Side by side

Pricing and features checked September 2026.

What changes after a few months

Eight days of raw data

Core Web Vitals usually get worse bit by bit. A plugin update in March adds 80 ms, a new consent tool in May adds another 150, and in June someone swaps the hero image. Nobody notices until Search Console turns orange, and then you want to know what changed. For that you need data from before it went wrong.

On New Relic's default Original data option, raw browser events (PageView, PageViewTiming and the rest) are kept for 8 days. Data Plus makes that 98 days at $0.60 per GB instead of $0.40, and every extra 30 days after that is another $0.05 per GB. Some rollups are kept longer (Apdex and page load time indefinitely), but they won't tell you which LCP element got slower in March.

New Relic docs, manage data retention, October 2026.

CoreDash keeps a year on Standard, three years on Studio and eight on Enterprise, included in the plan price. You can compare this June with last June for the same page template, split by device and country. CoreDash also shows Google's CrUX data next to your own numbers. I couldn't find a CrUX integration in New Relic.

Which script made that click slow

New Relic's INP phases are useful. If processing takes 400 ms you know it's the event handler, but not whose handler. On most sites I work on, the slow clicks on mobile come from a third party, usually the tag manager or a chat widget. The browser agent doesn't support Long Animation Frames, so it can't give you the script URL you need to fix it.

CoreDash records the LoAF script URL for slow interactions, so you can group INP by script and see which vendor costs you the most (my Long Animation Frames article explains how that works). For LCP, LCP priority tells you if the LCP image was preloaded, had a high fetchpriority or was lazy loaded. A lazy-loaded hero image is still something I find way too often. The Diagnosis dashboard turns that into a breakdown per phase with the fix for your stack. New Relic does capture the attributes, but for p75 LCP by element or by phase the docs mostly send you to NRQL and your own dashboards.

MCP tools for Core Web Vitals

New Relic has an MCP server that's GA, which is more than most RUM vendors have. It's built for observability in general, which makes sense on a platform where most questions are about the backend. None of the 30+ tools are about the browser or Core Web Vitals though, so an agent that wants your INP has to write NRQL against PageViewTiming first. And the AI analysis tools are billed separately as Advanced Compute.

The CoreDash MCP server has three tools, all about Core Web Vitals. get_metrics returns the p75 (or p50 up to p95) with its rating and the good/needs improvement/poor split, grouped by any dimension. get_timeseries tells the agent if a metric is improving, stable or regressing. get_histogram gives the distribution. It's included in every CoreDash plan, Starter too. Claude connects through OAuth as a custom connector, and Claude Code, Cursor, Windsurf, VS Code and Gemini CLI work as well (setup guide).

Then there's CWV Superpowers, a free MIT-licensed agent. It takes the field data from CoreDash, runs a Chrome trace with mobile throttling, finds what takes the biggest share of the time and gives you a diff with file and line. It never looks at a Lighthouse score.

The MCP endpoint is also a plain HTTPS API. If you want Core Web Vitals in your own reporting you POST JSON and get JSON back, no query language to learn.

Paying for more people to look

New Relic's free basic users can't open the Browser monitoring screens. If your SEO specialist or a client wants to see the Core Web Vitals, they need a Core seat at $49 a month or a full-platform seat. Ingest grows with traffic too, because every metric of every page view is a separate PageViewTiming event. On a busy site the browser data adds up and the bill goes up with every traffic spike. Unexpected bills come up a lot in New Relic reviews.

CoreDash is priced on pageviews as well, so a bigger site pays more. But users and dashboards don't cost extra. Starter has 3 users, Standard 10, Studio and up unlimited, and every plan has every dashboard. Agencies get agency plans with pageviews pooled across clients and an Agency API to create a project per client from their own tooling.

When to pick New Relic Browser instead

If you already pay for New Relic APM, keep Browser switched on. Being able to trace a slow page into the backend is worth a lot, and for TTFB problems that start on the server no RUM-only tool can do that.

New Relic also makes sense if you need session replay, JavaScript error tracking and AJAX monitoring in the same place as your Core Web Vitals, if you need FedRAMP or HIPAA (Enterprise), or if you have a small site under 100 GB a month and one engineer who enjoys writing NRQL. That last setup costs nothing.

Or run both. The CoreDash script is under 2KB and async, so it sits next to the New Relic agent without getting in the way.

Try it next to New Relic

Add the CoreDash snippet next to your New Relic agent and give it two weeks. Both use Google's web-vitals library, so you're comparing the same thing on your own traffic. The trial is 14 days, no credit card. Check pricing, or book a demo if you'd like me to show you around.

See also: all comparisons, CoreDash vs Datadog.

Sources: New Relic pricing, New Relic browser agent source, browser agent v1.322.0 release notes, New Relic data retention, New Relic user types, browser agent performance impact, New Relic MCP tool reference, Session Replay in the Core Web Vitals tables, New Relic reviews on Capterra.