How to measure performance as experienced by real users of your web application?

Performance is arguably the one word, the importance of which is realised by software engineers, product managers and business alike. Perf matters but how do you measure what your end users are experiencing when it comes to web applications? While there are a bunch of paid solutions available to achieve this, you really do not have to go very far to look for the answer.

The Performance Web API present right in your browser can be leveraged to instrument important metrics such as DOMContentLoaded, TTFB, dns lookup, load time of static assets and service response times to name a few which contribute to the performance of your application as experienced by real users.

There are few out of the box performance APIs which are described in the section below.

Performance Related Web APIs: Performance Interface is extended by other APIs such as Navigation Timing API, User Timing API, Resource Timing API and Paint Timing API.

At Inmobi, we have written a lightweight javascript package to leverage the methods exposed by window.performance and collect important resource and navigation timing data being experienced by the end users. Visualisation of this data has helped us in understanding the performance bottlenecks of our application.

At the core of this library are the following important method invocations:

As you can see, navigation timings give you information about your web page performance by recoding timings such as domContentLoadedEventStart,domContentLoadedEventEnd,domComplete etc.

Similarly, the resource timing can give you useful information about the latency of resources(images, scripts, style, service data) being fetched by your application. Information such as dns lookup time, payload size, request/response time etc. Each resource timing is saved in the timing buffer as an entry.

Every entry can be serialized using the toJSON() method.

performance.clearResourceTimings() is used to clear the existing entries once sent to the server to avoid duplicates.

performance.setResourceTimingBufferSize() is used to customise the size on number of entries which can be saved in buffer. By, default this size is 150 in most browsers.

The Holy Grail: Everyone loves charts, so let us give them one. Below are the two examples from the dashboard created using the timings data collected, that we use to monitor perf.

To get to the above end result, the entire solution consists of four important components:

The detailed explanation of the entire solution is beyond the scope of this blog . I would try to cover it in the upcoming blogs but at a high level, can be visualised by the following diagram:

The Client Side Tracker Library: This library is imported in the application code as an npm module and initialised with an options object.

trackUrl is the endpoint of NodeJS server route where data will be received, processed, saved as histogram and sent to a time series data value store, in this case, graphite.

threshold(in milliseconds) is the interval at which the new data collected by the library will be sent to the telemetry server.

exclude: The timings which do not serve your use case can be eliminated before sending the data to telemetry server to save both space and processing time.

excludeHosts: An optional list of hosts you don’t want to monitor, eg, third party hosts such as fonts.googleapis.com

parserCb and filterCb allow you to further parse and filter the collected data based on your own custom requirements.

The timing data collected is then processed at the server. Since it is raw timing data, it is first converted to a histogram object which can be then stored by Graphite and eventually plotted by Grafana to give us the visualizations shown above and allow us to monitor this data against several dimensions such as mean, max, min, p90, p95, p99, standard deviation etc.

Ciao!! Hope this article will help you in the real user management(RUM) of your application and take you one step closer in understanding the performance tools provided by the browser and how to make the most out of them. Please post your feedback and questions in the comments and clap if this was not a total waste of time :P

Related posts:

sit up. stand tall. and walk.. “towards a new tomorrow.” is published by Mariyam Haider in Unarchived Writings.

When I first fell for design thinking, I fell hard. In the third month as a civilian, after 14 years of buttoned up service in military structure, and two days into our fellowship at Stanford’s…

I think those were the affectionate words I used when when Micah first showed me our now current home listed on the MLS. At first glance through the photos, it was everything we had been looking for…