Pimp your Pipeline with Lighthouse CI
In the world of Web Development, since as far back as I can remember, two topics that continuously reoccur are performance and best practices. Tools like Lighthouse make it really easy to understand these areas by surfacing key metrics and suggesting guidelines on how to improve.
But running the occasional audit on your site will only get you so far. Of course, it’s good if you can get your scores above 90, but how are you maintaining those scores? Are you running a report after every deployment to make sure you’re still in the green? What if you could prevent a detrimental deployment from happening at all…
Enter, Lighthouse CI!
Lighthouse CI is a fantastic suite of tools, maintained by the friendly folks at Google, that can do things like…
- Run Lighthouse audits on your app via the command line
- Fail and report on any scores that don’t meet given thresholds
- Graph and compare your scores over time, tying each report to a commit
In this article, I’ll run through my implementation of Lighthouse CI in Azure DevOps and hopefully inspire a few others to do something similar.
Before we get stuck in, it’s worth mentioning that the documentation is very good! If you’re interested in testing it out, just head on over to the repo — it’s pretty simple to follow along and get something up and running.
However, if — like me — you work in a large department with architectural constraints and don’t have the luxury of spinning up a container that’s an exact replica of production, you might hit some hurdles!
What are we working with?
In my team, we use Azure Pipelines. Specifically, the multi-stage YAML variety — if you’re using Azure DevOps, I definitely recommend it. The deployment process is quite straightforward; once a pull request is approved, it is completed and merged into master where the pipeline is automatically triggered. The following stages occur:
- Build: Bundle, create artefacts, publish artefacts etc.
- Deploy: Deploy to staging…