Webpage Performance Monitoring with Dotcom-Monitor's BrowserView

Orde Saunders' avatarPublished: by Orde Saunders

I've been taking Dotcom-Monitor's BrowserView for a spin recently, it's the front end performance component of a wider suite of monitoring tools.

It's this suite of tools that is Dotcom-Monitor's real focus: it can monitor functionality at different levels of an application stack from back end - with ServerView - to scripted multi-step front end transactions - with UserView. Alongside this sit LoadView and BrowserView covering the performance monitoring aspects.

As it's the area of this suite in which I specialise, I've only looked at BrowserView. As you'd expect from a current generation front end performance monitor it uses real browsers in different locations across the world. This is useful if you're serving a global audience as the speed of light has a significant effect on a well optimised page so you can use BrowserView to assess the impact of this to your users in different countries and, if you're using edge CDNs the benefits of this should be reflected in your results.

BrowserView test locations

The main metrics available for each run are a breakdown of requests by type and a waterfall chart. Whilst this might seem a bit light if you're used to using WebPagetest, BrowserView is a monitoring and reporting tool rather than the kind of dedicated performance testing application you'd use during the optimisation process. However, if things move out of bounds of your performance budget there's enough information here to triage an issue and give you an idea of where to start with an investigation.

BrowserView waterfall diagram

The UI is refreshingly functional, there's a lot of information contained in a product like this and as a professional tool you want to get to it with as little "surprise and delight" as possible.

BrowserView UI

As someone who uses a lot of reporting tools, I find the high information density of screens like this a distinct plus point.

Whilst this covers the basics, using load time as the key metric isn't ideal for me - I'd prefer to see more options including objective measures as well as perceived performance metrics like speed index and first paint. That said, the tools I've used that do have these metrics don't come with the support of the rest of the integrated monitoring stack Dotcom-Monitor offer. As with most things, if you need the depth of a full stack then you won't get the breadth of detail and if you want the breadth of detail you won't get the depth of a full stack - pick the tool according to your needs.

A feature I didn't take a look at is Private Agents that allow you to deploy Dotcom-Monitor agents inside your networks - not something I need on any current projects but I can see it potentially being useful for an internal tool that's not exposed on the public internets.

In conclusion I'd say that if you're looking for an integrated full stack suite of monitoring tools that includes front end performance then Dotcom-Monitor is worth taking a serious look at.