New Relic Browser goes GA!

I’m the product manager for New Relic Browser and, today, my team and I are announcing that New Relic Browser has completed an extensive Beta period and is now officially in General Availability. As a GA product offering, New Relic Browser is ready to monitor the frontend of your Web applications.

Since our public Beta began in March, we’ve heard your interest in New Relic Browser, some really helpful feedback, and three hugs. Yep, some of our customers try to hug us.


For many software engineers working on browser applications, it can be challenging to get actionable performance visibility once the application ships and runs in the wild. With New Relic Browser, we’re expanding Application Performance Monitoring (APM) into client-side applications, and we’re adding some brand new functionality available with a New Relic Browser Pro subscription or trial:

Standalone Browser: Easy deployment options for any app

By far, the most common feedback we received was that many applications just weren’t able to automatically instrument our JavaScript monitoring code using our APM agents. For applications written in backend languages like Perl, we didn’t offer support. And for static apps deployed as a single page, our auto-instrumentation just didn’t cut it.

We want everyone to be able to monitor their applications, so we now offer a new Standalone Browser deployment method. Standalone Browser is the copy-and-paste option to put our JavaScript snippet directly into your application template. It’s available now to all New Relic Browser customers, regardless of subscription level. Simply create (or choose) a Browser application, copy the generated code, and paste it into the HEAD of your HTML before any other <script> tag in your code. Deploy your app, and… that’s it. Performance data will start flowing into your account immediately.

URL-Based Transactions: Simpler (and customizable) naming options

When we were using New Relic Browser to improve our own site—something we do regularly—we realized we were spending a lot of time trying to find specific transactions in the Page views list. That was hard, because we were still naming front-end transactions by backend server-centric names. So now, we don’t do that anymore. Browser transactions (like Page views and AJAX requests) are now named with URLs, which makes it a lot easier to search for the transaction you care about. Oh yeah, we also added the ability to search through the transactions to find the ones you care about. You also have the option to customize your URL naming schemes with a URL whitelist.

URL based pageviews

Session Traces: Nitty gritty performance tools

I saved the best for last: We’re not just flipping the switch from Beta to GA. We’re also unveiling a new feature called Session Traces. Session Traces are a Pro feature that offers visibility into individual page views. For randomly sampled transactions we record the entire lifecycle of the page (up to 10 minutes) by logging asset loads, AJAX requests, JavaScript errors, iframes, JavaScript events and callbacks, and even user interactions. You can scroll through the timeline and quickly identify performance issues that you may have never seen before.

session traces

When we started developing Session Traces, we knew we could access some rich data, but we weren’t really sure how it would go. After we started visualizing the results, we were surprised. We saw stuff that we didn’t expect, and it’s reshaped how we’ve begun to think about performance. For one thing, we’ve found that performance is reflexive. Sure, bad performance impacts users, but user behavior can also impact performance. After seeing these Session Traces, we’ve started to build applications more defensively, with a goal of preventing users from triggering performance problems.

We also found that context really matters when you’re talking about performance. It’s good to know that you’ve had a JavaScript error, for example, but it’s even better to know what happened that led up to the error and what impact did it have on the user. This is equally true for slow callbacks, unsuccessful AJAX requests, or other performance issues.

Finally, New Relic Browser helps us find several usability problems on our site. While these weren’t specifically related to performance, at least not in terms of speed, we uncovered issues that impacted our users and that we really needed to fix. In one case, we were loading a gif that indicated that the page was working (but taking a second or three), but we were loading it way too late in the page lifecycle, so it wasn’t available when it should’ve been. Kind of embarrassing, but then again, this level of visibility was not possible for us before.

We’re rolling out the ability to start a 30 day New Relic Brower Pro Trial to all accounts throughout the week. (If your account hasn’t been updated yet, don’t worry, you’ll see it soon!) If you’re new to New Relic, you can check out for information on how to quickly get started. I really hope you’ll try it out and share your feedback. We’re on a mission to build great software—with or without hugs.

For more details on these new features, see the New Relic Browser documentation site or watch this short video:'

Nathan Taggart is a Product Manager for New Relic. He oversees New Relic Browser, a client-side application performance monitoring tool. He's given talks on front-end application performance at Fluent and Front-end Ops Conf. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!