Measuring Web App Runtime Performance
When you’re focused on delivering amazing apps, you know that performance is a big part of that process. So, how do you know you’re delivering a performant app? Testing, of course!
We started monitoring and testing the apps manually and used the timeline from Chrome Developer Tools to measure how fast our apps were. We used it to inspect the number of resources being requested, namely, the time to load them, and the time to first paint. But gathering numbers with this manual process wasn’t enough, and we started to face some issues:
- Latency is anything but constant! Particularly when you consider apps used on mobile devices, latency can increase 10 fold just by being in a different room (we actually had this problem between 2 different desks in the same office!). Our solution was to repeat the test a bunch of times, but then…
- …you need to do a bunch of test repetitions: And for each, you need to measure the number of loaded resources, the time to first load, and so on. This is monkey work that we really didn’t want to do!
So we went on to automate the whole process. To do this, we used the Navigation Timing and Resource Timing APIs to gather essential metrics, and later we built a script to do test repetitions automatically.
Web Apps Performance Metrics
Let’s summarize the metrics that you must monitor, in order to measure the runtime performance of a web application:
- Time to load: This event is fired once all of the document’s resources (images, CSS, JavaScripts, …) have been fully loaded.
- Time to first paint: This allows us to understand how much time is needed until your user sees something on the screen.
- Time to DOM content load: This event is fired when all of the page’s DOM content has been loaded and parsed.
- Time to finish: the total time from the beginning of the request until everything is finished, including scripts’ processing.
- Is First Load: Helps us ensure that we are requesting a page without any cached resources.
- Time to first byte: This is basically a way to measure latency.
- Number of requests: Total requests, number of CSS files, number of JavaScript files, number of… you get the point.
Web Apps Performance Metrics with Chrome Dev Tools
If you want to try these metrics for yourself, you can launch the Chrome Dev Tools while accessing this page, run the code below.
You should now be able to explore the “perfData” object and see something similar to this:
The previous example is missing the “time to finish” metric. To measure that you need to trap the onload event and access the performance.now() API. There’s an example later on.
Testing Web Apps Performance: Repetition is Key
Like we mentioned previously, things like latency can vary a lot, so a stochastic approach is in order. What we really want to do is run the same test a bunch of times, and then analyze the results.
To achieve this, we developed a REST endpoint that stores the results and answers with the next webpage the browser must visit. The full script is below, including a set timeout, to make sure everything is loaded before we send the data back to the server. You’ll probably have to tweak the timeout value to fit your case.
The server side logic to collect the metrics was built with the OutSystems Platform, and you can find it in the Forge.
Automated Testing of Web Apps Performance
Having an automated way to do performance testing allowed us to monitor different performance scenarios very quickly. For example, we were able to test and understand the impact of concatenating and minifying CSS files on multiple devices. More about this on a future post! :)
By the way, there’s an amazing webinar about troubleshooting mobile apps performance that you can check to get more info.
