Web vitals automation using github actions
Web vitals has become a ket metric in SEO with more PWA’s created. Let’s see how we can automate web vitals using github actions.
Introduction
Google recently announced new standards for search engine ranching and Web vitals score directly impacts user’s experience visiting your website and also influences the search engine ranking. These new standards expect you to have less performance issues in production. we will use vercel CI Deployment using Github Actions
Lighthouse and web Vitals
Google Chrome is directly shipped with lighthouse, an open-source tool used to audit your website in a controlled environment within the browser.This tool generated web vital scores including first contentful paint, speed index, time to interact and other criteria out of 100 as PWA’s
It also provides suggestion and direct links to resources to help you resolve the performance, SEO issues and other helpful suggestions.
Though this is an easy way to get the web vitals before moving the app to prod.we need to do it manually. Now we can automate the process using github actions and vercel CI deployment action.
We can use Lighthouse cli or as in this tutorial we can use vercel CI deployment action
Lighthouse Budgets
Light house allows to maintain a budget file that specifies requirements of each web vitals measurement such as first-contentful-pain
and cumulative-layout-shift
. You can also specify the maximum sizes for images , script loads and third-party requests count.More information on Budgets here.
If the Lighthouse audit fails to meet the set budgets and assertions are returned that describe where the problems occur with a link to further details of the assertion and what was expected.
This file is named budget.json
and is put in .github/lighthouse/
directory
Below is the example of the file showing some metrics that assert against.
[
{
"path":"/*",
"timings":[
{
"metric":"interactive",
"budget": 3000,
},
{
"metric":"first-contentful-paint",
"budget": 1800,
},
],
"resourcesSizes":[
{
"resourceType":"script",
"budget":100
]
}
]
Writing a Github Action
We can write our workflow within our repository thanks to the Github Actions that make it seem-less . Since it is developed by Github we have complete control on the CI.We can trigger actions based on pull, push, tags or anything that is supported from GitHub Marketplace. We can also call external services like vercel
API or Lighthouse cli
.
When an action is triggred by pull-request
event , the outcome of the action can be used to pass or fail the pull request checks and also can be made mandatory in branch settings. In our case , we are going to create a pull-request-audit.yml
file in .github/workflows
directory. When you raise a pull-request
then this file will be triggered and run.
In order to perform a lighthouse audit on pull request changes. We need to :
- Deploy the changes on vercel
- Run Lighthouse against vercel preview URL
- Format the results
- Display the results on the pull request
Let’s take a look at the marketplace actions we need and how to use them
Vercel action
Vercel action allows you to trigger a vercel deployment Of our full request code and run a Preview URL which we Will use to audit, before actually merging the code.
In order to do that we need to connect our project to vercel via vercel API to get the project-Id
and org-id
information as per the following Vercel Project Linking documentation
We will need to save the vercel IDs as the Github secrets within settings of the repository. settings → secrets → new Repository secret
here is how we configure the action workflow file to automate web vitals checking.
- name: Audit URLs using Lighthouse
id: lighthouse_audit
uses: treosh/lighthouse-ci-action@v7
with:
urls: |
${{ steps.vercel_action.outputs.preview-url }}
${{ steps.vercel_action.outputs.preview-url }}/blog
budgetPath: '.github/lighthouse/budget.json'
uploadArtifacts: true
temporaryPublicStorage: true
runs: 3
Displaying the Results
To best display the results of the audit, we need to get hold of the Lighthouse audit output and format the results. We can then display these on the pull request using the sticky-pull-request-comment action. This action allows sticky comments to be added to a pull request and later edited.
When calling the sticky comment action you must ensure that you set a header
and use the same name consistently. This will ensure that the correct comment gets updated.
- name: Add comment to PR
id: loading_lighthouse_comment_to_pr
uses: marocchino/sticky-pull-request-comment@v2
with:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
number: ${{ github.event.pull_request.number }}
header: lighthouse
message: |
🚦 Running Lighthouse audit...
To format the assertion results, if there are any, you can simply loop through them and build up a string to pass as message
to the comment
action with the correct header
.
Putting it All Together
The complete finished action can be found in the vercel-lighthouse-action repository along with an example budget.
It will deploy your PR code to Vercel, run three Lighthouse audits against the provided URLs based on the Vercel preview URL, and then format the results before posting them as a comment onto the PR.