Integrate Google Lighthouse into your CICD pipeline

Do you want to increase the quality and most likely the conversion rate of your web pages? In this blog post, I provide the steps on how to integrate Google Lighthouse into a CICD pipeline. Read on.

When you develop a web application performance and accessibility are key requirements. Since many have walked the same road, there are best practices available. If you are exposing this web application to the outside world you also need to consider SEO (Search Engine Optimization). If you would measure and score these requirements the higher the score, the more likely it will end up higher in Google’s search results (source). That will mean more traffic and likely a higher conversion rate.
There is a tool that measures these requirements and scores them: Lighthouse. This tool analyzes your web application and provides valuable feedback in improving your score.

Shift left

Lighthouse is often run in a post-deployment scenario to then discover that some requirements are not up to par. Lighthouse is a tool for developers at its core, meaning that it can be run during development to tackle and solve issues as soon as possible. So even before we integrate Google Lighthouse into a CICD pipeline. An example of a Lighthouse report looks as follows:

Getting started

In this example, I use Angular to generate a web application that can be targeted by Lighthouse. The web application is generated by using the Angular CLI. This is a personal preference; any web application will do. Use the framework/library you are most comfortable with. When the application is hosted locally it looks as follows:

When we click on SEO, Lighthouse shows us the following:

If we click on the link, we can see the solution to this problem. After adding the following to the index.html:

The resulting report looks like this:

Checking your deployments

Checking locally is an excellent practice and you can tackle issues as soon as possible. Let’s see what happens if we deploy the application to a remote URL and run the report again:

The performance score is different. This is because of differences in the hosting environments of the application. It would be valuable to check the report on the deployed environment as well. Suppose we have the following CICD pipeline:

The pipeline creates an artifact and deploys it to a development environment and next to a test environment. Both environments have a different URL.
Where would be a good place to show the report? There are many options and I tried a few. I ended up with the following:

In this solution, we can view the scores from the development environment after our latest version has been deployed. We can then compare these scores against the scores from the latest version of the code on the test environment. If the scores are worse, we decide to halt further deployment to Test. Next, let’s look at what is needed to integrate Google Lighthouse into the CICD pipeline.

YAML

Complete YAML Gist

I will focus on the SEO score for demonstration purposes. The Lighthouse comparison stage is as follows:

I will skip the first step. I explain this in my other blog post. We need to install dependencies because we are going to call the Lighthouse node module. I will explain this later in more detail.
Lighthouse needs to run silently to output only a value. If we don’t add –silent, it will output additional logging. We want a clean number for the comparison. We store the scores temporarily to a dev and test variable.
Next, we do a comparison between these two variables. We use the command “node -e” (evaluate) to do the comparison. Bash in Linux is not able to compare two decimals (for example 0.8 and 0.9) without the use of a library. With console.error we can signal our pipeline that an stderr has occurred in case the score on the test environment is better than on the dev environment. To halt the pipeline, we set failOnStderr to true.

Lighthouse code

Complete Lighthouse code Gist

I’ve used the following snippet from the readme in the Lighthouse repository in Github:

I changed the options to the following:

If we don’t specify the headless option, the agent shows the following error during the pipeline run:

The default for emulatedFormFactor is mobile, which means it will run the report for mobile devices:

It would be useful to call the lighthouse with a URL as shown in the YAML file earlier.

The Calling function looks as follows:

Because we use results.lhr, we can directly access the SEO score. This gives us a high degree of granularity. The console.log command outputs a digit, which is used in the comparison. Eventually, you may want to return an object with multiple properties to have access to other scores as well. Last, in the package.json in the scripts section we add the lighthouse command:

Tied together

Let’s see what happens if we add an image without an alt attribute to the index.html file:

Conclusion

Google Lighthouse helps you to a great extent in analyzing and improving the quality of your web pages. The detailed and extensive documentation makes improving your quality scores a breeze. Next to this, it provides developers a rich set of features. This makes it straightforward to integrate Google Lighthouse into your CICD pipeline. Once you have completed the integration, you can choose whatever method you like to ensure the quality of your web pages during the deployment of your web application.

Your opinion

Thanks for reading my blog post. If you believe something is unclear or incorrect, please let me know. I am always open to feedback and eager to improve my explanation and knowledge sharing.