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.
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.
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.
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!