A Look at New Relic Browser
Join the DZone community and get the full member experience.Join For Free
while at fluent conf this year, i was walking by the new relic booth when i noticed something interesting – a product called new relic browser. back when i converted my blog to wordpress, i ran into a lot of problems. my server went down, wordpress crashed, it was a bit frustrating. (much like how lemonade in a paper cut is a bit frustrating.) one of the tools i used to help diagnose my server was the new relic server monitor . outside of a few issues installing, i was really impressed with the level of detail the monitor provided. while it wasn’t the final solution for fixing my problem, it definitely helped me pinpoint what was sucking up all the ram on my box, and helped me check my changes to ensure things were going well. best of all, this was entirely free. i’ll give them huge props for offering such a powerful tool for no up front money. because i had such a good experience with them on the server side, i thought i’d give their browser product a try as well.
as you can guess, this tool is meant to help you gain insights into how well your web application is performing. i decided to try it on my blog, which, admittedly, is probably not the best use case for this product. wordpress isn’t something i need to hack up and outside of the performance issues i had on the server side, i figured the client side was pretty much good enough. it certainly seemed good enough to me. but at the same time, my blog gets quite a bit of traffic so i figured it would also provide a good set of data to dig into as well.
setup is relatively simple. you begin by selecting a deployment method:
i selected copy/paste as i figured that would be simpler. on the next page, i said i was not using apm, even though i guess i kinda was. i was trying to test this as someone who was not also using the server side product, so there may be things i missed out on. typically when i try products like this though i try to keep things as simple as possible.
so that was that. i copied in the code, cleared my wordpress cache, and then promptly forgot about it for a week or so. i then took a look back at my stats. there’s a tremendous amount of information you get right on the front dashboard.
first off – note the browser load times. i’m averaging 6.8 seconds or so which is quite high and not what i expected. for over ten years i ran my blog with very precise knowledge of what i had going on within my templates. with wordpress, i’ve kinda gotten lazy about it and have given up being so deeply involved. this gives me a clue that maybe i need to take a closer look at my template and plugins and see if i need everything i’ve got.
as i said, the dashboard is pretty packed, but let’s go deeper. first, the page views report.
this report shows recent pages and which page requests are consuming the most load time. you can mouse over each line item for a detailed view:
you can also switch the “sort by” to show average page load time:
and yes – that twenty plus second item on top there made me crap my pants. honestly i’m not sure why that page averaged so high as it is relatively simple, but it does give me something to dig into deeper.
the next link, session traces , is not what you may think. i had assumed this was a report of a ‘session’ for one visitor to my blog. instead, it is a deep look at one particular web page. and when i say deep, i mean deep. here is a top level report for one session:
note all the detail in the chart. you can then scroll through the session and look at every particular darn thing in the one request. for example, here i can look at what google analytics is doing.
the next report shows you the ajax requests your web app is making. you get details on what is making requests as well as throughput and data size. i can say from experience that the data size chart could be really useful. back when i first learned ajax i made the mistake of not considering the size of my packets and my applications suffered through it. this is a rather long page so i’ve split the screen shot into two parts.
i’m thinking that in ‘real’ web app the ajax report will be the number one place you’ll find nuggets of information. of similar importance is the js errors report.
clicking on a particular item will give you details:
if you click on the instance details, you can see the line number where this error was thrown.
while not this particular error, earlier i found an issue with gravatar. i didn’t think i was using gravatar, but it turned out one plugin was making use of it and throwing an error. i modified the plugin and the error went away.
the browsers report gives you details about what types of browsers are hitting your site and how well they perform. i mentioned how i was a bit surprised by the page load times on my site, well in this report i can see what browsers are having the worst issues with page load:
look at that jump for ie and opera! that’s fascinating to me. it doesn’t necessarily mean those are bad browsers, but it gives me an area to focus in if i were to start digging into my site performance.
you can then go to the geo report to see how different areas of the world (and america) handle your site.
along with just reporting, you can also create alerts too. you get a default alert policy out of the box and can define your own as well. this is fairly similar to what you get in the server product as well.
from what i can see, this is a really darn good tool, and as i said, i had great success with the server tool. so how much does it cost? here is the price plans as of the time i wrote the post:
150 a month isn’t necessarily cheap, but heck, that’s my rate for development (yes, that’s what i charge by the hour) and considering how much data you get the forensic information is easily worth it. the free (lite) version also has fewer reports. if you go to their pricing page you can see what you don’t get at that tier, but note that you get 14 days of free access to the top tier to see if it is worth it.
Published at DZone with permission of Raymond Camden, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.