Web Performance Monitoring Tools
Introduction
There is no silver bullet in the wild wild web that will grant you excellent performance for your site, every app is unique, especially when complexity kicks in and features are added.
Requirements, budget and user base will define your actual performance goal, but there are general rules that you can follow to avoid junky applications and angry users. Fortunately the web is plenty of tutorial and documentation to help on this matter, articles like the PRPL Patter, Google Developer Speed Docs or recent announced https://web.dev help developers to understand topics such as code splitting, css optimisation, images resizes and many others…everything needed for silky smooth web app! ⚡️.
My Own Dashboard
“If You Can’t Measure It, You Can’t Improve It.” — (someone on the web)
Can’t argue with that, measuring your progress helps visualise how what and why things go wrong with your app. I decided to share my experience of building a dashboard to monitor any web app.
I wanted to use lighthouse because is an amazing auditing tool: easy to use, has practical documentation and generates a to do list to rise the performance bar.
On lighthouse GitHub page I landed on this project called Garie, very well organised. I may have found a solution 🏆🏆🏆!!
It is easy to install and configure, so I started playing with it…until I decided to build my own. The issue I had is the plugin approach: LightHouse + PageSpeed Insight + BrowserTime. Their are all great projects but I’m a fan of single source of truth and can’t have a bunch of tools telling different stories…
In fact PageSpeed just switched to lighthouse to provide performance metric. Thanks Google:https://youtu.be/ymxs8OSXiUA?t=887. BrowserTime instead is used only to record page loading in mp4 video file..no thanks I prefer lighthouse trace timeline.
Other two points that convinced me to play with my own dashboard are: missing static typing and multi-repo approach. I’m in love with Typescript, especially if you have a long list of metrics with keys and values to associate, nothing more to say here. For the repo approach feels more natural to have dashboards and lighthouse in the same repo, much easier for the current complexity of the project.
Lighthouse as source of truth
As I said earlier Lighthouse will be the major actor here, for a very good reason: PWA. Encourage Progressing Web App refractor with a very detailed TO DO list.
Everybody should be pushing for PWA for obvious reasons:
- https://medium.com/dev-channel/a-pinterest-progressive-web-app-performance-case-study-3bd6ed2e6154
- https://dev.to (A beautiful example of PWA)
Garie the good bits
Garie is a great project with no doubt! I kept the docker architecture because of great portability (we will see an example on GitHub Hook as well). Also Grafana was my first choice and Garie makes a good use of it, I kept the container and rebuilt the dashboard. I was impressed by influxDB, in my mind there was elastic search as goto storage, but influxDB is great as well especially for time series and for the scale of the project. It comes with a chronograf which is the corresponding of Kibana for Elastic Search, not necessary but nice to have if you want an easy way to inspect your storage.
webperf-dashboard
This is the project i’m working on:
After partially rewrite the lighthouse service, his cronjob functionality and updated lighthouse to the latest version, I focused on building Grafana dashboards.
- Versus Dashboard
I want the freedom to compare all the websites I’m monitoring or just 1 vs 1 on a specific page bases on a time frame, I also want a view very familiar to a lighthouse report page. On top there are overall scores, following on the bottom: metrics that impact the performance score. At last a collection of miscs such as downloaded bytes, nodes count & network requests.
- Single Page Dashboard
It Is very similar to Versus but gives focus on the single page and shows the TO DO list (aka Opportunities) from lighthouse HTML Report.
For both dashboard the time series graphs have thresholds for their score, applied from official threshold spreadsheet.
https://docs.google.com/spreadsheets/d/1Cxzhy5ecqJCucdf1M0iOzM8mIxNc7mmx107o5nj38Eo/edit#gid=0
As you can see notice interactive andspeed-index have the most impact on performance score.
GitHub Bot
I’m not going into implementation details because is fairly simple and documented in the repo, but CI automation on PR is a huge help identify issues before merge. In this case the Bot pull the pr code and run an audit posting the result as commit.
I got this idea from the React GitHub Repo where they have bundle bot to check changes in the bundle size.
Further improvements
Development is not over, while this is a basic configuration that helps you monitoring any app, some further improvements can be added to make these tools awesome:
- Investigate on alerts when a budget is exceeded (Grafana).
- Display scores delta compared to target branch (This is a tricky one you need some kind of storage to avoid multipe audit on same branch).
- Bundle bot like React! Why not, maybe an extension of the current bot. (Here as well some sort of storage to keep the bundle size of specific hash commits)
- Code Coverage on Dashboard. (Would be nice to Understand how much of the bundle is used when the page is rendered)
- Parallel Lighthouse Audit for cron job. (At the moment are sync one after the other)
- User Timing, Analyze trend of complex interaction in your app (This involve a little bit of end to end testing)
