Lighthouse CI: Adding a Google Lighthouse Audit to Your CI CD Process

Lighthouse CI: Adding a Google Lighthouse Audit to Your CI CD Process

You’ve put in the hard work of
optimizing your website’s page speed. Now what? How do you make sure you don’t introduce
a change that causes you to take a step back? In this video, I’m going to go
over one way you can do this by adding Google Lighthouse audits to your build
process. Hi. I’m Phil Sparks with Guiding Digital. In previous videos we’ve talked
about the many benefits of web performance, and even talked about free
tools available to help you audit and optimize web pages. One of these tools
was Google’s Lighthouse audit. In today’s video I want to walk through how easy it
is to add Lighthouse audits to your build process. I’ll be hosting my repo
in GitHub and using some of their built-in CI CD features, but many of the
concepts apply to other git providers or CI CD setups. So let’s get into our demo.
As a starting point I’ve credited an out-of-the-box Gatsby site using the
gatsby new command, and then I’ve pushed that up to my GitHub repo. If you’re
wanting to follow along, you don’t have to use Gatsby. You can use whatever
framework that you’d like to use. If you’re not familiar with Gatsby, I’ll put
a link to there getting started page in the video description. Before we add our
action to our project, let’s create a local git branch to work off of. I’m
using Visual Studio code as my code editor and using their built in terminal
and PowerShell to run my git commands. Now let’s add our GitHub action to our
project. GitHub actions are of course specific to GitHub. I’m not going to go
into too much detail about GitHub actions, but for this video just know that
GitHub actions our GitHub’s way of allowing you to build continuous
integration and continuous deployment into your project. If you’re not using
GitHub, other git providers offer similar solutions, and you can use tools like
Jenkins as well to accomplish the same thing. To add the action to our project
we first create directory called .github to the root of our project,
and then we create a directory called workflows inside of that directory, and
then we’ll add our GitHub action to the workflows directory. The name is not
important, but we’ll name ours lighthouseaction.yml. Now let’s add our code for a default
action. I’m going to go ahead and copy and paste the code in so you don’t watch
me type. A lot of what I’m using for today’s demo is from the Lighthouse CIs
project page including this code that I just copied in. So if you need to
refer back to that I’ll include a link in the video description to that page. We
won’t go over every single detail of the action code, but let me just point out a
few things. The first thing I’ll point out is the on attribute. This is where
you can configure what events you want to trigger the action. For example, you
could tell it to trigger an action on push events or pull requests events. You
can also tell it what branches will trigger the action, and so you could tell
it to only trigger the action for a pull request against the master branch. The
next section I’ll point out is the steps section. This is basically where you just
outline what you want the action to do. The important parts of this section
are the part where you see here the npm install build step, and in that step is
where you basically tell it how to build your application, and so i’m using
yarn for my dependency management. So I’m I’m running the yarn command to install my
dependencies and then do a npm run build to do a gatsby build. The next section
is actually where the lighthouse code is run. You’ll see it installs the
Lighthouse dependencies, and then calls a lhci auto run which will actually then
run the report. Now let’s commit our changes and push it
up to the remote. Now we’ll create a pull request. Then we
see our action running. We can click on the details link to see each step in the
process. I’m going to go ahead and skip to the end and show you the results. Okay.
The action has completed, and you’ll see that Lighthouse ran for two URLs that
it found in the out of the box Gatsby site: the 404 page and the default home
page. You’ll see that it ran Lighthouse three times for each URL, and then
it uses the average from those three runs to report back. To view the results
you can copy the URL you see here in the output and copy and paste it into a
browser and you see a normal Google Lighthouse report. Now obviously it’s a
little difficult to get to the actual report. So the next step we’re going to
take is adding what’s called GitHub status checks, and that’ll make
it easier to view the results directly from the pull request. So the first thing
we’re going to do to add the status check is we’re going to install and authorize
the Lighthouse CI GitHub app. You can find a link to the app in the Lighthouse
CI project page or I’ll include a link in the video description. To install the
app simply go to the page and hit the install button, and then I’ve chosen to
only allow my specific repo, and then click the install and authorize button.
On this next page make sure and copy this token to your clipboard. You’ll need
it in the next step. Next we’re going to go back to our repo
and go to the settings section. Then we’re going to go to the secrets section
and add the token that we just copied. So we’re gonna paste it here in the value
field, and then give it a name and then click the add secret button to save
it. Now we’re going to switch back to Visual Studio Code and then add a
section to our last step for including an environment variable, and just make
sure the name that use on the right side when referring to this setting is the
same name you gave it in the previous step. Good. Now let’s commit our changes
and push them up to our remote repo. We’ll go back to GitHub and go back to
the pull request and open our previous pull request. We see that the action is
running again. Click on the details tab to see the details and again I’m going
to forward to the end and we’ll see the end results.
It is now completed and you’ll see here it mentions the status checks. We’ll go
back to the pull request and open it up and see that it added the checks and you
can easily see the summary of each of the categories and then you can click on
the details button to go directly to the report. So it’s so much easier than the
first method. Now let’s take it one step further. Let’s add some test assertions
to fail the checks if any of the categories fall below 90. To modify the
Lighthouse CI settings you just add a file named .lighthouserc.json to the
root of your project, and then you add your configuration to that file. In this
code that I’ve copied in, I’ve set up assertions that will throw an error for
any of the four main categories if the score falls below 90. If you remember
from my video on performance tools the Lighthouse performance score is
calculated from five different metrics: first contentful paint, speed index, time
to interactive, first meaningful paint, and first CPU idle, and out of those it
gives the most weight to the time to interactive weight, and so one way you
could do it is you could configure your assertions to set individual goals for
each of these metrics if you wanted, or if you just wanted to focus on the most
important one, the time to interactive, you could just set up a assertion for that
one as well. I’m not going to go over all the different options of configuring
assertions in this video, but the Lighthouse CI project’s read me page has
some pretty good documentation and guidance on these options. The last thing
we’re going to do is go back to our action yaml file. We’re gonna remove
the configuration options from the command line here since we moved it to
our lighthouserc JSON file. Okay. Now let’s commit our changes and push them
up one more time, and then we’ll go back to our pull
request and go the details, and skipping it forward again. Once the Lighthouse run has completed, we
see that our assertions have ran and everything passed. In today’s video we created a working
example that I hope gives you some ideas on how you can find a solution to
continually monitor your webpage performance.
Remember, you don’t have to use the exact pieces that I’ve used today.
Mix and match technologies for the different pieces of your solution based
on what you are familiar with and what works for your environment. The question
of the day is what tools have you used to monitor web page performance? Thanks
for watching today. If you found this video useful give me a like and make sure
and subscribe if you want more content on web best practices. Also, feel free to
leave me a comment or question below and I’ll try to respond to each one.

Related Posts

How to Find Backlinks from Competitors site । SEO Backlinks checker tool । How to check Backlinks

How to Find Backlinks from Competitors site - SEO Backlinks checker tool - How to check Backlinks please subscribe my
Link Building Strategies on Steroids: How to Get Backlinks FAST!

Link Building Strategies on Steroids: How to Get Backlinks FAST!

In this video, I’m going to show you how to turn your backlink analysis into actionable link building strategies… fast.

2 Replies to “Lighthouse CI: Adding a Google Lighthouse Audit to Your CI CD Process”

  1. This is really cool. I generally only check performance when I'm optimizing a site and I use lighthouse for that. Awesome videos.

Leave a Reply

Your email address will not be published. Required fields are marked *