Filed under: Performance Monitoring
Supporting a product like TraceVIew means that among other things I get to play with a broad cross section of web stacks, poke around in interesting and unusual server configurations, and field a wide array of questions.
- “What exactly do you mean by a trace?” (This).
- “Why can I install a TraceView Apache module but for nginx I have to replace the whole web server?” (Because).
- “Do you support Adobe CQ5?” (We do now!)
Recently I received a question from Aki, co-founder of Marketmuse, who had heard a Cliff notes summary of TraceView and wanted to know how it could help them.
Hey Tracing Guy: “Can I use RUM to test API performance?”
We sure could have done a better job of explaining the moving parts of TraceView and how they fit together. Aki and I spent some time on the phone talking about his stack and where TraceView could help but first we had to unpack and rearrange some concepts.
When we talk about Real User Monitoring we’re talking about gathering data from the navigation timing API from the browsers of users hitting your site. That is, everything from the moment a browser navigation event occurs to the moment the document load event is complete.
There’s a bunch of stuff going on in there, details in the W3C spec of course and a more intuitive demonstration of what that means can be seen with this “Navlet” bookmarklet tool. Note that recent changes to the Chrome security model will prevent this from running on a page loaded over SSL. You can work around that by using protocol relative URL’s though some sites may still disallow it with a CSP.
What you’re seeing here is a condensed timeline of browser navigation events which is very similar to the RUM data we collect. The request time including DNS queries and TCP setup overhead in green on the left, FBT or First Byte Time through to the firing of DOM ready in orange, and the remaining time until finally onLoad on the right in red.
Traceview tour guide pro tip: If you look to your left you’ll notice a black gap between the request and the first byte. That mystery blob comprises the work happening on your server before the response starts to come in. Wouldn’t it be cooler if that empty space looked more like this? Why yes, yes it would.
The bottom line is that RUM is about browser navigation events. By the time your front end makes an XHR back to your API as far as the browser is concerned navigation has already happened and the page has loaded.