June 6, 2023
READING TIME2 min

Incorporating Lighthouse into Your CI Workflows

I've noticed that despite Lighthouse being one of the most widely used web development tools, Google's Lighthouse CI really isn't used as frequently as I believe it should in CI workflows. Having a decent Lighthouse score is a must for any accessible, SEO-friendly, performant website. Why shouldn't checks against it sit alongside your lint and type checks?

Following Lighthouse CI's Getting Started guide is the easiest way to set it up. There's too many configuration options to discuss, so I encourage you to check that article out.

Essentially, though, you're only dealing with two files: (1) the Lighthouse configuration file and (2) your GitHub Actions workflow. I've included an example of each below.

lighthouserc.json
{
"ci": {
// ...
"assert": {
"preset": "lighthouse:no-pwa",
"assertions": {
"categories:performance": [
"error",
{
"minScore": 0.9
}
],
"categories:accessibility": [
"error",
{
"minScore": 1.0
}
]
},
// ...
}
}
}

.github/workflows/ci.yml
name: CI
on:
pull_request:
branches:
- main
concurrency:
group: ${{ github.head_ref || github.run_id }}
cancel-in-progress: true
jobs:
ci:
runs-on: ubuntu-22.04
timeout-minutes: 30
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18.14.2'
- name: Install
run: |
npm ci
- name: Run Lighthouse
id: lighthouse
continue-on-error: true
run: |
npx lhci autorun

After setup is complete, all that's left to to do is enter your repo's settings and add a ruleset to your default branch that requires ci pass before any pull request can be merged.

FIN.