The One Session You Shouldn’t Have Missed at Fluent 2014: Browser Monitoring for Modern Web Apps

In March, we announced New Relic Browser on stage at Fluent. The talk was so popular, it was literally standing room only, and we were invited to give it a second time to accommodate more attendees. I wanted to recap the talk, for those who missed it, because I think it highlights the importance of browser monitoring for modern web applications.

The History of the Entire Internet

To begin, let’s review the history of the entire internet. (Stay with me, it’s a pretty short history.) At the advent of the internet, servers stored static files. When browsers asked for content, the server would return a static file. There wasn’t a big need for performance monitoring back then. Eventually, developers realized they could make better web sites by customizing the user experience (remember when you could choose your color scheme on a website? Those were the days…). They, of course, did this by writing an application layer — which took a request from a browser, handled it with some logic, and dynamically built a file to return. At some point (probably after a bunch of frustratingly slow n+1 queries), developers realized that they needed to monitor the performance of their application. This is a problem New Relic has been solving for since 2007.

But, the thing is, today applications don’t always work that way. Developers kept on, well… developing. And we’ve learned that we can further improve the user experience if we break our application apart and put some of it in the browser. Now, some of our application runs in our customer’s environment, not on our server any more. So at the same time we introduced new opportunities for performance problems (by not controlling the application environment, for example), we also lost visibility into the application at run time.

PastedGraphic-3

It turns out, not controlling the app environment creates some problems. Users don’t always do what they should (or at least, not what we expect them to). For example, they use really old computers sometimes. And those computers run slowly, and come with old browsers, which aren’t compliant with modern standards. Sometimes our customers even install spyware toolbars intentionally for FarmVille credits, or whatever. They connect from unreliable networks, like on airplane Wi-Fi. And from devices you wouldn’t expect, like “Smart TVs” and game consoles.

And all of this means one thing: browser application development is hard.

So, we built a solution. We’re really excited about it. So excited, that we’re currently sharing a preview of two browser monitoring features for a limited time for all of our customers, including customers on our Lite subscription.

JavaScript Error Monitoring

PastedGraphic-4

One feature we’re currently previewing in public beta, is our new JavaScript Error Monitoring. JavaScript errors can be tricky to track down and fix. Errors are reported differently in different browsers (and different browser versions, and different user languages). So, even if you build a way to log errors, it’s still pretty tough to see how impactful and widespread an error truly is. We aggregate errors based on their stack trace (yep! We grab a stack trace of the error, too). This allows us to surface the errors that are most prevalent and helps prioritize JavaScript errors to fix.

Unlike server errors, JavaScript errors can happen multiple times per page load. They don’t always break the page. We’ve seen that they frequently happen in loops, and can therefor create thousands of errors per second, per page load. Trying to log all of these can put a real strain on your infrastructure (if you ever bump into me at a conference, ask me about that one time we accidentally DDoSed ourselves. It’s funnier in hindsight…). Part of New Relic’s JavaScript Error Monitoring solution is a mechanism for aggregating errors in the browser for up to one minute before sending them up to be further aggregated and charted. By doing this, we significantly minimize the risk of any performance issue associated with error monitoring.

AJAX Performance Monitoring

The second feature we’re showing off in public beta is our AJAX Performance Monitoring. We monitor all AJAX requests made by your instrumented page, and record round trip time from the browser, http status codes, and payload size. Most importantly, we aggregate this data in two ways: from the page making the request, and from the server endpoint receiving the request. This way, you can ask yourself how an AJAX request to a specific endpoint is performing across your entire application, or you can alternatively ask what AJAX requests are impacting performance of a specific page.

PastedGraphic-5

We’re currently working on additional AJAX Performance Monitoring functionality which, internally, we’re calling “BJAX.” Why “BJAX?” As Sam Goldstein puts it, “We could call it AJAX 2, but calling it BJAX is pretty funny.”

The Future of New Relic Browser

There’s a lot more we can do with New Relic’s browser application monitoring, and we’re excited to continue to work on it. Modern web applications are relying more and more on browser-side code execution, and we’re focused on bringing the same quality of performance monitoring we’ve offered for server-side applications into the browser.

If you haven’t yet tried New Relic Browser for your application, create an account , check it out, and let us know what you think!

ntaggart@newrelic.com'

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!