Google Lighthouse is the free, go-to SEO tool for determining your website's overall health.

Enter your URL, and Google Lighthouse will score the performance metrics of your website, including page-speed, accessibility, best-practices and on-page SEO.

With the release of Lighthouse version 6 earlier this year, many developers observed a drastic decrease in the performance metrics of their websites.

This especially came as a shock to the community of developers that use the popular React-based framework GatsbyJS, praised for its speed and performance.

As a GatsbyJS developer myself, I too, was puzzled. We had gotten used to seeing those sweet, green, 90+ performance ratings, without much effort on our part.

After the version 6 update, however, our site dropped into the orange, down to 60 points! And some us were even experiencing red, sub 40 points scores.

I want to share with you the steps I took in order to re-achieve a perfect 100 Google Lighthouse score.

Step 1. The quick and easy fix: switching to Preact

With the release of Lighthouse version 6, three new performance metrics were introduced: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Total Blocking Time (TBT).

After scouring the Gatsby Github repo, as well as the Lighthouse docs, it seemed clear that Total Blocking Time (TBT) was the main culprit responsible for hampering the performance score for many sites.

Total Blocking Time (TBT) is defined as the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI).

Simply put, TBT is a measurement of how long the browser's main thread is blocked by long tasks, such as parsing JavaScript (JS).

That being said, any steps taken to reduce the amount of JS, as well as JS execution time, will positively impact site performance by reducing TBT.

Preact is a small (3kb), fast alternative to React. And thanks to gatsby-plugin-preact, switching your Gatsby-site from running on React to Preact is incredibly easy.

Navigate to your project root and install the following packages using NPM:

npm install --save gatsby-plugin-preact preact preact-render-to-string

...or Yarn:

yarn add gatsby-plugin-preact preact preact-render-to-string

Then simply add

... gatsby-plugin-preact, ...

to your gatsby-config.js

Then run

yarn gatsby build

If you use the webpack bundle analyzer, you should now be seeing a ~100kb smaller bundle size! Not bad, right.

Check out the difference this switch made to our bundle size in the image below.

An 8 percent decrease in bundle size for one line of code - not bad!

Switching to Preact should bump your performance score about 5-10 points.

Step 2. Reconsider the necessity of the Hero-Image

Another metric that made our site, SmartRate, take a beating performance-wise was the Largest Contentful Paint (LCP).

LCP is a metric for measuring perceived load speed. And together with Total Blocking Time, LCP and TBT makes up 50% of the total Lighthouse Performance score.

With that in mind, it's not a big surprise that an image covering 80 percent of the fold negatively impacts the LCP-metric, even when optimized using the webp format.

We tweaked the hero image and achieved partial success by disabling fade-in and switching loading from the default parameter (lazy) to eager:

However, the improvements were only marginal and barely noticable in Lighthouse (about 2-4 points), so we decided to regroup and rethink.

What was the purpose of our hero-image, really?

The hero image is commonly used to grab the user's attention and convey a central message to strenghten your brand.

In our case however, that's not how we use the fold.

A screenshot of the fold as it looks today, showing the hero-unit and user-input area.

As you can see from the image, the fold is dedicated to user-input. And the hero-image we were using before the current one was just a blurred photo in order to give some ambience to the fold.

After a bit of thinking, we realized we couldn't justify using a hero-image, given the negative impact it had on our performance metrics.

Instead, inspired by sites such as Spotify.com, we decided to go with an SVG background.

This single decision reduced the size of the initial page-load by a whooping 65kb!

From an optimized webp image of ~67kb down to a mere 2kb SVG for the same real estate.

Upon finding that this solution completely fixed our issues with the LCP metric, we quickly dropped the idea of using a hero-image from our most important subpage, företagslån - business loans - as well.

Current sub-page design utilizing a hero-unit (although not a hero-image)

For this, and our other subpages, we opted for a subtle three-color CSS gradient instead, to make the hero-message stand out.

This solution was perhaps not as sleek as using a custom tailored image, but it did the trick and greatly improved the LCP for our subpages as well.

Which brings me to...

Key considerations if your site is using a hero-image

Dropping the hero-image in favor of a SVG or CSS background will, in our experience, solve the issues caused by a low LCP score.

However, depending on the purpose of your hero-unit, this solution may not be optimal for you.

So, before you decide what to do, you should consider a few things:

• Is the hero-image custom made for your site or a stock-photo?
• Does the hero-image add value to your brand?
• What is the purpose of the fold on your site?

If your hero-image adds great branding value for your site, perhaps the trade-off for better performance simply isn't worth it.

However, if you're ready to give my suggestions a try, you will be happy to hear about the following resources.

Great resources for SVG backgrounds

Below I've compiled a short list of valuable resources and tools for anyone who wants to switch from using a hero-image to using SVG/CSS patterns:

• Hero Patterns by Steve Schoger A great tool providing multiple customizable SVG patterns.

• SVG Patterns by Philip Rogers Another free SVG pattern gallery.

• SVGOMG by Jake Archibald A great, free resource for minifying SVG-files. It's all about reducing those kb's, right?

The next step is a bit more situational, but will, for those of you who are using a UI library, still be very relevant. For us, this step was just as important as the first two steps in improving our metrics.

Step 3. Dropping Material UI for TailwindCSS

Let me state, right off the bat, that I'm a big, big fan of Material UI. And I'm not alone in thinking so. Until recently, MUI has been the most popular React UI library on Github (currently at second position).

When we started developing our site, the design was entirely based on MUI components.

The only problem was, it was slowing down the performance of the site.

A lot.

Especially for mobile users.

After the release of Lighthouse version 6, we simply couldn't get the mobile performance ratings above 70 points, due to a very high Total Blocking Time (TBT).

Nothing we did seemed to matter at first. We even tried code-splitting using Loadable Components, and lazy-loading non-essential payloads.

After some digging though, we identified Material UI as the source for the decrease in performance.

During page render, layout calculations (and re-calculations) seemed to occur all over the place, which contributed to an increased TBT.

We started removing MUI components, one by one, but this did little to improve the performance.

Finally, we were down to a single MUI component, and a near clean boilerplate website.

And we were still experiencing low performance ratings.

How could this be?

Well, as it appeared, importing a single MUI component would bring in the entire Material UI library into the bundle. And loading the landing-page would require the user to download the entire CSS and JS of Material UI.

But what about tree-shaking I can hear you say?

Well, to that I can only respond that we followed the MUI recommendations for minimizing the bundle size. Our efforts, however, did not pay off.

By removing the last MUI import, we noticed a staggering ~170kb drop in bundle size!

Finally, the performance of our site soared into the green, 90+ points, even on mobile!

The TBT was now non-existent, but so was the layout of our website.

We therefore started looking at alternatives, and I remembered reading about TailwindCSS integration into Gatsby some time earlier.

One phrase that caught my attention was "Purging your CSS".

PurgeCSS, which is now built-into TailwindCSS, does exactly what you think it does - removes unused CSS!

Perfect.

By transitioning from Material UI to TailwindCSS, we could obtain a material-ish design with a great performance score.

Simply following the Tailwind installation guide in the Gatsby docs was enough for us to get going. We slowly started designing material-ish looking components using Tailwind through PostCSS.

Not quite as nice looking as MUI components, but not far off. Given the huge performance boost though, it was totally worth it.

For being complete beginners, I must say designing components using Tailwind is surprisingly intuitive. You quickly get the hang of it.

Reconnecting to the first step

Another small perk of using Preact over React is the possibility to use the class parameter over the className parameter (which still works). This makes designing components a bit quicker - especially when copying markdown from their official website.

Should you decide to abandon Material UI, Bootstrap, or whatever other React-based UI library you're using in favor of Tailwind, you'll be happy to know about the following resources:

• Tailwind UI Made by the creators of TailwindCSS, Tailwind UI is a repo where you can find beautiful, pre-designed components. A few of them can be used for free.
• Tailwind Components is a repo of free-to-use community-made Tailwind components.

Bonus tip: Manage your bundle size going forward

As you probably can imagine, optimizing the bundle size and rebuilding the entire UI of our site was quite taxing. If I learned one important lesson during this process it was this:

Mind the bundle size!

As we grew more and more aware of how bundle size was impacting the performance of our site, we stumbled upon a tool called bundlephobia.

Bundlephobia landing page.

This great tool will "find the cost of adding a npm package to your bundle". Not only that, but it will show you similar packages, and how they relate in size to the one you're currently viewing.

This was truly useful for us when we developed the bolån (mortgages rates) sub-page. We required a charting library that would let us put together multiple line charts, showing the average mortgage rates for Sweden's largest banks over the last twelve months.

We couldn't find any other website doing this, so we thought it would be a great, free service to offer our visitors.

However, wiser from earlier experiences, we were not keen on simply using the first charting library that crossed our path.

Using bundlephobia, we compared the bundle size of different charting libraries and found that, based on our needs, chartist.js would be sufficient or us.

Bundlephobia showing similar libraries (and their respective package-size) to chartist.js

And an image of the resulting line charts showing historical mortgage rates.

If our need was simply to display interactive line-charts, why pay more than we need?

In other words, if we have the option to get the desired function with minimal impact to performance, that option should be our default choice.

However, it's also important to recognize that decisions between design and performance almost always implicates a trade-off. And that trade-off should be considered wisely.

Our priority was performance, as shown by the results below:

A near perfect Google Lighthouse score! Only two points off on Accessibility for having too low of a contrast ratio on some buttons. But hey, design has to prevail somewhere, right?

In this post we covered the steps we took in order to achieve a near-perfect Google Lighthouse score, by:

• Improving the metric Total Blocking Time by switching from React to Preact
• Improving the metric Largest Contentful Paint by optimizing the parameters of the hero-image, or switching the hero-image for a SVG-pattern
• Improving the metric Total Blocking Time by switching from Material UI to TailwindCSS, and purging unused CSS using PurgeCSS
• Reducing overall bundle size

I truly hope the lessons we learned will inspire and benefit you, too!

Lighthouse is an open-source project from the Google Chrome team. It's used to analyze web page quality based on a set of modern, "user-centric" metrics.

When supporting websites that rely on organic search results for revenue, quality is critical. Performance, accessibility and general SEO best practices are major factors in search engine rankings.

Lighthouse provides a granular set of metrics that represent these factors and suggestions of improvement in reporting.

There are many ways of running Lighthouse, but in the real world you may want to compare reports regularly, especially in continuous change workflows. With that said, you might be wondering - how can I keep track of SEO, performance, and accessibility changes over time?

This post covers how to use Automated Lighthouse Check to analyze website quality over time. But keep in mind that there are many other Lighthouse integrations to choose from.

Saving Reports and Viewing Results in a Timeline

Lighthouse scoring is an interesting aspect of the tool that may feel a little dirty at first. Still, it can be a very useful point of comparison when looking at historical data.

The performance category in particular is quite complicated in its calculation of score and you can find a lot of great reading about the topic among others on web.dev.

Automated Lighthouse Check provides a means of manually triggering audits or establishing a schedule in which they run automatically throughout the day. These audits are saved in a database so you can visualize and analyze results at a historical level. You can actually drill into any report in time to see full details (see an example here).

For a guide to getting started with Automated Lighthouse Check, see the documentation.

Timeline view of Lighthouse scores

A historical list of Lighthouse audits

Lighthouse Automation in DevOps

Not only are there many useful cloud-based Lighthouse tools, but there are also many open-source projects that can be implemented in a variety of DevOps workflows. Some of these solutions support persistence of data in one form or another, to track historically.

Below are a few examples that I've contributed to.

• This post covers how to use Lighthouse in CircleCI. You can save reports as "artifacts" in CircleCI or upload to AWS S3 automatically.
• This post covers how to use Lighthouse in GitHub Actions. This solution also provides a way to save reports as "artifacts" (in GitHub) or upload to AWS S3 automatically.
• Lighthouse Persist is an NPM package that exposes the native Lighthouse API with additional options to set AWS S3 credentials so it can be used to upload reports automatically.

A few friends - Octocat, Jenkins, CircleCI

Conclusion

I hope this post was helpful in providing solutions for analyzing website quality historically. Help support your local developers by purchasing their software ?

But in all seriousness, I'd love any feedback about Automated Lighthouse Check... comments, suggestions, feature requests, etc. It's about a year old at the time of this writing and has recently been migrated to Kubernetes for high availability.

Automated Lighthouse Check provides free and premium plans.

CircleCI is a popular tool for orchestrating CI/CD pipelines. Lighthouse is an open-source project from Google for improving the quality of web pages. It provides user-centric metrics to audit SEO, performance, accessibility, best practices, and progressive web apps.

For a deeper dive about Lighthouse you can read “How to analyze website performance with Lighthouse”.

By combining these forces, we can establish website quality automation. This post will demonstrate the following:

• Basic implementation of Lighthouse in a CircleCI workflow.
• Advanced setup to display Lighthouse results in pull request comments.
• S3 Lighthouse report uploads.
• Slack notifications.

Lighthouse Check CircleCI Orb

CircleCI Orbs are shareable packages of configuration elements, including jobs, commands, and executors you use in your workflows. This post will provide a guide for using the Lighthouse Check CircleCI Orb for automating Lighthouse audits.

Basic Example

Below is a minimal example and all we need to run Lighthouse automatically on any code change ? In this example both https://www.foo.software and https://www.foo.software/contact will be audited.

version: 2.1

orbs:
  lighthouse-check: foo-software/lighthouse-check@0.0.8

jobs:
  test: 
    executor: lighthouse-check/default
    steps:
      - lighthouse-check/audit:
          urls: https://www.foo.software,https://www.foo.software/contact

workflows:
  test:
    jobs:
      - test

With this minimal setup we have a summary provided in the output of our job. We also have full HTML reports saved as CircleCI "artifacts".

Lighthouse Check Orb output

Lighthouse Check Orb save artifacts

Advanced Example

Lighthouse Check CircleCI Orb offers a complete set of bells and whistles by utilizing [lighthouse-check](https://github.com/foo-software/lighthouse-check) NPM module under the hood. There’s so much more we can do with this. Let’s proceed!

Pull Request Comments

By utilizing this feature, comments are posted with Lighthouse results on every commit. We can do so by following the steps below.

1. Create a new user or find an existing one to act as a “bot”.
2. Create a personal access token from this user account.
3. Create a CircleCI environment variable in your project to hold the encrypted value from above. In our example we name it LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN.
4. Update our config file with the diff shown below.

+ prCommentAccessToken: $LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN
+ prCommentUrl: https://api.github.com/repos/foo-software/lighthouse-check-orb/pulls/${CIRCLE_PULL_REQUEST##*/}/reviews
urls: https://www.foo.software,https://www.foo.software/contact

The updates above provides a token to authorize comments on a corresponding pull request. prCommentUrl should be an endpoint in the format specified by the GitHub API. Your endpoint will be similar but with owner and repo params replaced ( foo-software/lighthouse-check-orb ). With this, we’ve created a bot to post Lighthouse results on pull requests ?

Lighthouse Check PR comments

S3 Report Uploads

In our example we persist results by uploading reports as artifacts in our job. This solution could be sufficient in some cases, but artifacts aren’t stored permanently. In order to view reports, we need to navigate into the workflow and manually download reports from the artifact view.

But what if we want a more dependable way of storing and referencing reports? This is where the S3 feature comes into play. We can configure AWS S3 storage by following the below steps.

1. Create an AWS account if you don’t already have one.
2. Create an S3 bucket if you don’t already have one.
3. Acquire an AWS access key id and secret access key.
4. Create a CircleCI environment variables for these two values. In our example we’ll use LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID and LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY, respectively.
5. Add the bucket name and region (example: us-east-1) as CircleCI environment variables: LIGHTHOUSE_CHECK_AWS_BUCKET and LIGHTHOUSE_CHECK_AWS_REGION.

Next, we’ll update our configuration with the following diff.

+ awsAccessKeyId: $LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID
+ awsBucket: $LIGHTHOUSE_CHECK_AWS_BUCKET
+ awsRegion: $LIGHTHOUSE_CHECK_AWS_REGION
+ awsSecretAccessKey: $LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY
prCommentUrl: https://api.github.com/repos/foo-software/lighthouse-check-orb/pulls/${CIRCLE_PULL_REQUEST##*/}/reviews

In our next commit and push, reports are automatically uploaded to S3 ✅! We also have a them linked in our PR comments.

Lighthouse result PR comment with S3 report linked

Slack Notifications

What’s a new feature in a DevOps workflow without Slack notifications? A sad one indeed. Let’s ramp things up by adding notifications to a Slack channel for our whole team to see. We can accomplish this in the below steps.

1. Create an “Incoming Webhook” in your Slack workspace and authorize a channel.
2. Add the Webhook URL as a CircleCI environment variable — LIGHTHOUSE_CHECK_SLACK_WEBHOOK_URL.

+ slackWebhookUrl: $LIGHTHOUSE_CHECK_SLACK_WEBHOOK_URL
urls: https://www.foo.software,https://www.foo.software/contact

Our next commit and push introduces Slack notifications! The “Lighthouse audit” link in the below screenshot navigates to the S3 report as configured ✨

Lighthouse Slack notification

At this point our complete "advanced example" configuration looks like the below.

usage:
  version: 2.1

  orbs:
    lighthouse-check: foo-software/lighthouse-check@0.0.8

  jobs:
    test: 
      executor: lighthouse-check/default
      steps:
        - lighthouse-check/audit:
            awsAccessKeyId: $LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID
            awsBucket: $LIGHTHOUSE_CHECK_AWS_BUCKET
            awsRegion: $LIGHTHOUSE_CHECK_AWS_REGION
            awsSecretAccessKey: $LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY
            prCommentAccessToken: $LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN
            prCommentUrl: https://api.github.com/repos/foo-software/lighthouse-check-orb/pulls/${CIRCLE_PULL_REQUEST##*/}/reviews
            slackWebhookUrl: $LIGHTHOUSE_CHECK_SLACK_WEBHOOK_URL
            urls: https://www.foo.software,https://www.foo.software/contact

  workflows:
    test:
      jobs:
        - test

Maintaining a Historical Record

Foo’s Automated Lighthouse Check is tool we can use to manage a historical record of Lighthouse audits. We can connect to it with the Lighthouse Check Orb! By doing so you can run Lighthouse remotely versus in a local, dockerized CircleCI environment. With this we can be assured our Lighthouse results aren't flaky from CircleCI infrastructure change. Follow the documented steps to connect with Automated Lighthouse Check.

A historical record of Lighthouse audits with "Automated Lighthouse Check"

What Now?

You can find other of examples of Lighthouse Check Orb usage on GitHub. I hope this article has provided a helpful addition to your DevOps workflow! With Lighthouse integrated in a CI/CD pipeline, we can stay fully equipped to ensure high quality in website SEO, performance, accessibility, best practice, and progressive web apps.

GitHub Actions are used to automate software engineering workflows. Similar to tools like CircleCI, Jenkins, Travis and many others, GitHub Actions provides a declarative API for defining workflows. These workflows can include jobs to build, test, and deploy applications.

Lighthouse is an open-source project from Google for improving the quality of web pages. It provides user-centric metrics to audit SEO, performance, accessibility, best practices, and progressive web apps. For a deeper dive about Lighthouse please read “How to analyze website performance with Lighthouse”. This post will demonstrate the following:

• Basic implementation of Lighthouse in a GitHub Actions workflow.
• Advanced setup to display Lighthouse results in pull request comments.
• S3 Lighthouse report uploads.
• Slack notifications.

Lighthouse Check GitHub Action

This post will provide a guide for using Lighthouse Check Action for automating Lighthouse audits. It can be used within a workflow - triggered by any event. This post will demonstrate how to use the action when triggered by a pull request event.

Basic Example

With the following steps we can create a basic workflow.

1. Create and checkout a new branch locally.
2. Create a file in your project with a path similar to the following .github/workflows/my-workflow.yml (replacing my-workflow with any name of your choice).
3. Populate the file from above with the example shown below, replacing the urls field with a comma separated list of the URLs you’d like to test.
4. Commit changes locally and push the branch up to your remote.
5. From your new branch, open a pull request.

name: Lighthouse Check
on: [pull_request]

jobs:
  lighthouse-check:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - run: mkdir /tmp/artifacts
    - name: Run Lighthouse
      uses: foo-software/lighthouse-check-action@master
      with:
        outputDirectory: /tmp/artifacts
        urls: 'https://www.foo.software,https://www.foo.software/contact'
    - name: Upload artifacts
      uses: actions/upload-artifact@master
      with:
        name: Lighthouse reports
        path: /tmp/artifacts

And Voilà ? — we have a workflow with Lighthouse! Assuming you have GitHub Actions enabled in your repo, you should see something like the below (note: at the time of this writing GitHub Actions are in “beta” mode and require registration).

GitHub repository tabs

Clicking on “Actions” will list all workflows currently running and previous.

List of GitHub Actions workflows

After following the steps from our basic example, you should see one item on this list. Clicking in will show us Lighthouse results printed to the console.

Lighthouse results printed out in the console

From our configuration, we also have results captured in HTML reports saved as “artifacts”.

Clicking through the “Artifacts” dropdown downloads the HTML reports

Full Lighthouse report as an HTML file downloaded from “Artifacts”

Advanced Example

Lighthouse Check Action offers a complete set of bells and whistles by utilizing [lighthouse-check](https://github.com/foo-software/lighthouse-check) NPM module under the hood. There’s so much more we can do with this. Let’s proceed!

Pull Request Comments

By utilizing this feature, comments are posted with Lighthouse results on every commit. We can do so by following the steps below.

1. Create a new user or find an existing one to act as a “bot”.
2. Create a personal access token from this user account.
3. Create a GitHub secret to hold the encrypted value from above. In our example we name it LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN.
4. Update our workflow file with the diff shown below.
5. Commit and push.

with:
+  accessToken: ${{ secrets.LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN }}
  outputDirectory: /tmp/artifacts

With this, we’ve created a bot to post Lighthouse results on pull requests ?!

Lighthouse results as PR comments

S3 Report Uploads

In our example we persist results by uploading reports as artifacts in our workflow. This solution could be sufficient in some cases, but artifacts aren’t stored permanently. In order to view reports, we need to navigate into the workflow and manually download reports from the artifact view.

But what if we want a more dependable way of storing and referencing reports? This is where the S3 feature comes into play. We can configure AWS S3 storage by following the below steps.

1. Create an AWS account if you don’t already have one.
2. Create an S3 bucket if you don’t already have one.
3. Acquire an AWS access key id and secret access key.
4. Create GitHub secrets for these two values. In our example we’ll use LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID and LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY, respectively.
5. Add the bucket name and region (example: us-east-1) as GitHub secrets: LIGHTHOUSE_CHECK_AWS_BUCKET and LIGHTHOUSE_CHECK_AWS_REGION.

Next, we’ll update our configuration with the following diff.

with:
  accessToken: ${{ secrets.LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN }}
+  awsAccessKeyId: ${{ secrets.LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID }}
+  awsBucket: ${{ secrets.LIGHTHOUSE_CHECK_AWS_BUCKET }}
+  awsRegion: ${{ secrets.LIGHTHOUSE_CHECK_AWS_REGION }}
+  awsSecretAccessKey: ${{ secrets.LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY }}

In our next commit and push, reports are automatically uploaded to S3 ✅! We also have a them linked in our PR comments.

Lighthouse result PR comment with S3 report linked

Slack Notifications

What’s a new feature in a DevOps workflow without Slack notifications? A sad one indeed. Let’s ramp things up by adding notifications to a Slack channel for our whole team to see. We can accomplish this in the below steps.

1. Create an “Incoming Webhook” in your Slack workspace and authorize a channel.
2. Add the Webhook URL as a GitHub secret — LIGHTHOUSE_CHECK_WEBHOOK_URL.
3. Add GitHub data and the Webhook URL to our configuration with the diff below. The GitHub data will be rendered in our notifications. We pass GitHub data through configuration with the GitHub “context”.

with:
  accessToken: ${{ secrets.LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN }}  +  author: ${{ github.actor }}
  awsAccessKeyId: ${{ secrets.LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID }}
  awsBucket: ${{ secrets.LIGHTHOUSE_CHECK_AWS_BUCKET }}
  awsRegion: ${{ secrets.LIGHTHOUSE_CHECK_AWS_REGION }}
  awsSecretAccessKey: ${{ secrets.LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY }}
+  branch: ${{ github.ref }}
  outputDirectory: /tmp/artifacts
+  sha: ${{ github.sha }}
+  slackWebhookUrl: ${{ secrets.LIGHTHOUSE_CHECK_WEBHOOK_URL }}
  urls: 'https://www.foo.software,https://www.foo.software/contact'

Our next commit and push introduces Slack notifications! The “Lighthouse audit” link in the below screenshot navigates to the S3 report as configured✨.

Lighthouse Slack notification

Maintaining a Historical Record

Foo’s Automated Lighthouse Check is tool we can use to manage a historical record of Lighthouse audits. We can connect to it with the Lighthouse Check GitHub! By doing so you can run Lighthouse remotely versus in a local, dockerized GitHub environment. With this we can be assured our Lighthouse results aren't flaky from GitHub infrastructure change. Follow the documented steps to connect with Automated Lighthouse Check.

A historical record of Lighthouse audits with "Automated Lighthouse Check"

What Now?

You can find a full example from the above in the Lighthouse Check Action documentation. I hope this article can provide a helpful addition to your DevOps workflow! With Lighthouse integrated in a CI/CD pipeline, we can stay fully equipped to ensure high quality in website SEO, performance, accessibility, best practice, and progressive web apps.

I discovered that a lot of web developers, including beginners, have not heard about this tool and those who have, have not tried it yet, that's not cool :(.

In this article, I would introduce you Chrome Lighthouse, what it does and how to start using it.

PS: This article was first published on my blog

Let’s get started :)

According to Wikipedia, A lighthouse is a tower, building, or other types of structure designed to emit light from a system of lamps and lenses and to serve as a navigational aid for maritime pilots at sea or on inland waterways.

Okay, let's turn this into a tech term;

Lighthouse is a tower, building, or other types of structure designed to emit light from a system under the “Audits” panel in Chrome Developer Tools and to serve as a guide for developers

Making any sense? :)

Well, Lighthouse is a tool developed by Google that analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices.

Think of Lighthouse as the speedometer in a car that checks and balances the cars speed limit.

Basically, Lighthouse works with developer best practices and performance metrics. It runs checks on a web app and gives you feedback on errors, practices below standard, tips for better performance and how to fix them.

According to Google Developers Docs

Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, and more.

You can run Lighthouse in Chrome DevTools, from the command line, or as a Node module. You give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page did. From there, use the failing audits as indicators on how to improve the page. Each audit has a reference doc explaining why the audit is important, as well as how to fix it.

That’s pretty much all about Lighthouse, It audits the URL of a web app and generates a report telling you how bad and good your web app is according to web standards and developers best practices. Also attached to each section of the report is documentation explaining why that part of your app was audited, why you should improve that part of your app and how to fix it.

Here is a demo of Lighthouse audits report for this blog https://bolajiayodeji.com

L: My blog :) R: Lighthouse audits report

Pretty cool right? :)

What you should note is that I didn’t get great scores like this on my first audit. I had to use my first report to fix and improve the performance and quality of my app.

This is the idea behind Lighthouse, it is to identify and fix common problems that affect your sites performance, accessibility and user experience.

Now, let's move to the interesting part, HOW TO GET STARTED!!

LightHouse is available in three workflows

• Chrome Developer Tools

• Command line (Node)

• A Chrome extension

I personally prefer using LightHouse in Dev Tools. Using the extension does not make sense as the Dev Tool and extension work in the same chrome browser, well our preference varies, use what works best for you.

Lighthouse was first available only with the Chrome extension before it was added to the Chrome DevTools.

Using lighthouse on the command line is really cool also,(For geeks :))

Let’s Get Started!!!

[1] Run Lighthouse in Chrome DevTools

• Download Google Chrome web browser here

Note that Lighthouse can only be run on a desktop and not mobile

• Go to the URL you want to audit in Google Chrome.

You can audit any URL on the web.

• Open Chrome DevTools

Command+Option+C (Mac)
Control+Shift+C (Windows, Linux, Chrome OS).

• Click on the Audits panel

To the left is the viewport of the page that will be audited, here that’s my blog :). To the right is the Audits panel of Chrome DevTools, which is now powered by Lighthouse

• Click on Run audits

DevTools shows you a list of audit categories. Ensure that you leave them all checked. If you want to personalise what part of your app to be audited, you can set that by checking the categories you want to audit.

• After 60 to 90 seconds — depending on your internet strength, Lighthouse gives you a report on the page.

Not that your internet speed and pre installed extensions can affect lighthouse audits. For better experience, run audits in Icognito mode to avoid any interference

[2] Run Lighthouse in Command line

• Download Google Chrome web browser here

• Download node here, If you have it installed already, skip this step!

• Install Lighthouse

npm install -g lighthouse
# or use yarn:
yarn global add lighthouse

The -g flag installs it as a global module.

• Run your audits

lighthouse <url>

Sample;

lighthouse https://bolajiayodeji.com/

By default, Lighthouse writes the report to an HTML file. You can control the output format by passing flags.

The report can be displayed in HTML or JSON format

Output samples:

lighthouse
# saves `./<HOST>_<DATE>.report.html`

lighthouse --output json
# json output sent to stdout

lighthouse --output html --output-path ./report.html
# saves `./report.html`

# NOTE: specifying an output path with multiple formats ignores your specified extension for *ALL* formats
lighthouse --output json --output html --output-path ./myfile.json
# saves `./myfile.report.json` and `./myfile.report.html`

lighthouse --output json --output html
# saves `./<HOST>_<DATE>.report.json` and `./<HOST>_<DATE>.report.html`

lighthouse --output-path=~/mydir/foo.out --save-assets
# saves `~/mydir/foo.report.html`
# saves `~/mydir/foo-0.trace.json` and `~/mydir/foo-0.devtoolslog.json`

lighthouse --output-path=./report.json --output json
# saves `./report.json`

Run $ lighthouse --help for CLI options

[3] Run Lighthouse with the Chrome extension

As I earlier said, The DevTools workflow is the best as it provides the same benefits as the Extension workflow, with the added bonus of no installation needed.

To use this method you need to install the extension, but If you have your reasons, here is the guide;

• Download Google Chrome web browser here

• Install the Lighthouse Chrome Extension from the Chrome Webstore.

• Navigate to the page you want to audit

• Click Lighthouse Icon.

It should be next to the Chrome address bar. If not, open Chrome’s main menu (the three dots on the upper right) and access it at the top of the menu. After clicking, the Lighthouse menu expands.

• Click Generate report.

Lighthouse runs its audits against the opened page, then opens up a new tab with a report of the results.

Bingo! You did it

That’s pretty much it, Lighthouse is a great tool, especially for beginners.

It is a very useful tool when it comes to auditing Progressive web apps.

I actually learned so much about optimization and performance standards when I started using Lighthouse. In no time you would become an expert in building full optimized web apps with great performance, accessibility and user experience. :)

Lighthouse is not magic, it was created by humans. It is open source and contributions are welcome. Check out the repository’s issue tracker to find bugs that you can fix, or audits that you can create or improve upon. The issues tracker is also a good place to discuss audit metrics, ideas for new audits, or anything else related to Lighthouse.

Thank you for reading this, after installing and using Lighthouse, share your success stories in the comments!

Also, I just launched my blog where I write articles on web and frontend development, don’t forget to visit and share!!!

For someone who is trying to break into software development, it doesn’t matter where you look — LinkedIn, career advice boards, youtube tutorials — the advice is always the same: you need a portfolio. freeCodeCamp knows this advise, and they make it compulsory to create one to finish their “Responsive Web Design” Certification.

The portfolio is supposed to be a living document. You finish a project, you throw that bad boy onto your portfolio to show it off to the world. You constantly add to it, displaying your personal growth trajectory. You give it to potential recruiters and hiring managers to add some dimension to your resume.

Out of the five projects to get that certification, I put hands-down the most work into my portfolio. If it was going to be my digital first impression, I wanted to ensure that it was the best one I could make.

The de facto method for completing the projects on freeCodeCamp is to use codepen.io. The free version lets you code in an HTML, CSS, and JavaScript pane, and see your changes as you type them in a window. You can open the page in a full view, which eliminates the HTML, CSS, and JavaScript panes, but leaves a black banner at the top. The url is a hash, something like https://codepen.io/cam-barts/full/ZPWpqo, which is not memorable, doesn’t give any indication about the site’s content, and in my opinion doesn’t make any waves on a resume. Furthermore, unless you pay for a membership with codepen, you can’t change it.

Around the time I was finishing my project, the stars aligned and I discovered two technologies that would help my portfolio stand out: Github Pages and Google Lighthouse.

Github Pages allows you to host a website directly from a GitHub repository. It offers a pretty slick github.io url, which tickled my fancy for something to put on a resume. It would allow me full control of what my users would see when they navigated to the site (so long, black banner), and I wouldn’t have to deal with self hosting or paying for some other hosting service.

I heard about Google Lighthouse in the CodeNewbie Podcast featuring Frances Coronel. It audits your website straight from Chrome Dev Tools for five areas: Performance, Progressive Web App, Accessibility, Best Practices, and SEO. SEO, or Search Engine Optimization, is what helps your site float to the top of search engines like Google, which helps you get found. Also, now that I was going to host my site on Pages, I wanted to take responsibility for my site’s performance, and to effectively do that I had to at least have a benchmark.

My goal in writing this article is to help you create a blazing fast, professional looking portfolio site at no cost to you. I want it to be something you’re proud to post about on LinkedIn and plaster on the top of your resume, and I want to leverage GitHub Pages and Google Lighthouse to do it.

To go any further, I’ve made a few assumptions. The first is that you have a Github account. If you don’t already have one, creating one is easy. The second is that you have a basic understanding of git. If you’re brand new, there are plenty of excellent articles on getting started. This article assumes you’ve completed your portfolio on codepen. Finally, you should have Google Chrome installed.

This article follows my personal portfolio. You can find the pen here, the code here, and the final product is at cam-barts.github.io.

Getting started

Setting up your Github Pages site is pretty straightforward. The TL;DR version is:

• Create Repository following name convention [GitHub Username].github.io
• Clone Locally
• Create index.html, style.css, script.js files within repository
• Add code to those files
• Commit and push to GitHub
• Profit!

You create a repository with a title that follows the convention [Your Github Username].github.io. Here is mine: cam-barts.github.io. Whatever code gets pushed to that repository gets displayed when you navigate to that site.

So, when you’ve cloned the repository locally, what exactly do you put into it?

You should start with three files, an index.html file, a style.css file, and a script.js file. In whatever editor you like (I use Atom), you should start with the following code snippet in your index.html:

There is a lot going on here that might be unfamiliar if you have only been working with codepen.io.

The dir attribute in the html tag indicates that the document should be read Left To Right. That just ensures that when your page shows up, all of the elements are left justified, which is how English speakers read.

The meta tags in the head indicate metadata about the page, which helps search engines like Google index your site.

At this point, you should go ahead fill out the meta tags and the title tag. Note that the keywords meta tag’s content should be comma separated, and should include terms that you would want people to use in Google to find your portfolio. Here’s what mine looks like:

The next step is to copy the HTML section of your portfolio pen into the body section of your snippet. Once that’s completed, if you linked to any outside CSS or JS in your pen settings, such as to Bootstrap or Font Awesome, you need to link those in your index.html.

Create more link tags for css and script tags for JavaScript and add the links that are in the settings to the href and src attributes, respectively. To ensure that your styles and scripts show up, be sure to put them before the existing link and script tags in the snippet. For example, linking to Bootstrap and JQuery would look like:

Next, you need to add your own CSS into your style.css, and if you have any JavaScript, add that to your script.js.

After you’ve done that, you’re good to commit all your work and push it to Github. Immediately after you do that, you can navigate to [Your Github Username].github.io and check out your website!

Optimizing your portfolio site

Congratulations on publishing your portfolio!

The next steps involve optimizing your site. For this, we will use Google Lighthouse. It is better to do this in an In Private Browser window so that any cache or Chrome extensions you may have will not affect the results. When you navigate to your site, open Chrome Developer Tools (Ctrl + Shift+ i) and click on the Audits tab.

Google Lighthouse Pane

Progressive Web Apps are outside of the scope of this tutorial, but there is no harm in running all of the audits. When you run them, you should get a page that looks like this:

The best thing about these reports is that it gives you “Opportunities” to improve your scores.

In the performance section, it tells you to serve next gen file formats such as WebP versus traditional .PNG images, and suggests lazy loading the images.

In the SEO section, it suggests SEO improvements such as adding a description meta tag and using legible font sizes. Not only does it make these suggestions, it links to articles with practical examples with things to change in your code to optimize for those areas.

For me, it only took an hour to get the scores for my site in the high 90s for Performance, Accessibility, Best Practices, and SEO. You can see all to the changes I made here.

Going further

Next steps for your site are up to you. You could link it to Google Analytics to see how many visitors your Portfolio is getting. You could add sections for your awards to show your freeCodeCamp certifications as you get them. The evolution of your site is completely in your hands! Comment links to your portfolio below.

An overview of modern concepts, tools and example strategies to improve web page performance

Not Impressed at Penn Station

In March of 2018 Google confirmed rumors by announcing the migration of sites for “mobile-first” indexing.

What this Means

Mobile-first indexing means Google will predominantly use the mobile version of the content for indexing and ranking. Historically, the index primarily used the desktop version of a page’s content when evaluating the relevance of a page to a user’s query. Since the majority of users now access Google via a mobile device, the index will primarily use the mobile version of a page’s content going forward. We aren’t creating a separate mobile-first index. We continue to use only one index.~[Prepare for mobile-first indexing](http://Mobile-first indexing means Google will predominantly use the mobile version of the content for indexing and ranking. Historically, the index primarily used the desktop version of a page's content when evaluating the relevance of a page to a user's query. Since the majority of users now access Google via a mobile device, the index will primarily use the mobile version of a page's content going forward. We aren't creating a separate mobile-first index. We continue to use only one index.)

“Yikes!” — you may be thinking. This is a reasonable reaction for anyone owning a website relying on organic search results for its success. Consider extreme examples of websites that drive millions of dollars a day who’ve come to depend on such rankings. Many of these websites weren’t necessarily built to support mobile devices as the highest priority.

Confronting Performance

The first step in ensuring optimal performance of a web page on a mobile device is to understand key metrics in modern testing. We can go straight to the source by utilizing Lighthouse, Google’s open-source tool. You can run it in Chrome DevTools, from the command line, or as a Node module.

Lighthouse has a variety of options to allow performance testing under a variety of conditions, specifically notable being device and connection type.

Lighthouse Metrics and Scoring

In a Lighthouse performance audit, results are provided as a set of metrics with values. The score is a number between 0 and 100 where the higher number is better. Score is calculated by a weighted group of select metrics as explained in the documentation.

Load is not a single moment in time — it’s an experience that no one metric can fully capture. There are multiple moments during the load experience that can affect whether a user perceives it as “fast” or “slow”.

~ Paint Timing Spec

Not only does each metric capture a characteristic of page load, but each metric can encompass the results of others.

Nobody is perfect — an audit of the Lighthouse’s own documentation page

Opportunities for Improvement and Solutions

I’ve identified a few commonly low metrics with fairly straightforward solutions, depending on complexity. “Time to Interactive” is one of the most important.

Time to Interactive

At the time of this writing, the “Time to Interactive” metric is weighted highest in its influence on the overall performance score.

The Time to Interactive (TTI) metric measures how long it takes a page to become interactive. “Interactive” is defined as the point where:

The page has displayed useful content, which is measured with First Contentful Paint.

Event handlers are registered for most visible page elements.

The page responds to user interactions within 50 milliseconds.

To improve your TTI score, defer or remove unnecessary JavaScript work that occurs during page load. See Optimize JavaScript Bootup and Reduce JavaScript Payloads with Tree Shaking, and Reduce JavaScript Payloads with Code Splitting.

~Time to Interactive

Improving Time to Interactive

Webpack provides sophisticated customization nowadays to improve optimization. It provides out of the box configuration options to split code and prevent duplication as illustrated in the documentation. By using Webpack Bundle Analyzer, we can visualize the outcome of a “prevent duplication” code splitting approach.

Webpack Bundle Analyzer: Standard code splitting of a “vendors” bundle

Okay, well… could be worse ?! The important part is we separated common code. By doing this alone we relieve work from the main execution thread, provide asset caching potential, and other interesting things as detailed by Addy Osmani and Jeremy Wagner. But wait… there’s more!

Dynamic Code Splitting

We talked about one approach above. Another code splitting technique supported by Webpack involves the use of dynamic imports. I accomplished this fairly easily with staggering results by using Loadable Components to handle rendering in my “universal” app. I chose this library in its support of “Server Side Rendering” and documentation of it. It provides a Babel Plugin (which delegates chunks under the hood during build) and a Chunk Extractor — to collect chunks server side and provide script tags on page render. This seems confusing, so enough with the words… let’s role up our sleeves!

Imagine a page component, defined with a dynamic import.

And to process and delegate Loadable Components during build, we can configure Webpack with the Babel plugin (mentioned above).

In our client side render entry, we wrap in Loadable Ready. Loadable Components loads all your scripts asynchronously to ensure optimal performance. All scripts are loaded in parallel, so you have to wait for them to be ready using loadableReady .

On server side render, Loadable Components ChunkExtractor provides only the script tags used by initial page load and the rest asynchronously, client side! JS is loaded on-demand, behind the scenes.

Dynamically extracting script and style tags needed by a particular page is quite powerful. I used dynamic imports in all page components and components that uniquely import heavy libraries. What a difference! ?

Webpack Bundle Analyzer: Dynamic code splitting

We reduced the main vendor bundle by more than 100kb. The blue squares in the image above represent bundles created with dynamically imported page components. The large violet square in the top middle is a vendor split bundle from one specific component I identified as uniquely importing large libraries.

Okay, Did We Actually Do Anything?

The short answer is — yes!! We can see how JS is loaded by examining the network panel in Chrome Dev Tools. Let’s assume a request to a home page.

Chrome Dev Tools network panel: An example home page

Okay, wait… it’s all coming back now…

An alternative to large bundles is code-splitting, which is where JavaScript is split into smaller chunks. This enables sending the minimal code required to provide value upfront, improving page-load times. The rest can be loaded on demand.

~ Reduce JavaScript Payloads with Code Splitting

Aha, we can see this in action here as a user navigates to another route client side. Assume the user navigates to a “dashboard” page from the home page. Dashboard.fc4871b3.js is downloaded on demand!

Chrome Dev Tools network panel: An example home page and client side navigation to a “dashboard” page

And… Google loves it! With the above changes, I saw a Lighthouse score improvement of more than 10 points. ?

A Lighthouse audit with success written all over it!

Conclusion

By utilizing a recipe of modern tools and features, we can effectively identify, measure, visualize and address web page performance. This is important in accommodating Google’s mobile-first indexing. Key metrics documented by Google to measure performance, such as “Time to Interactive”, can help us pinpoint opportunities for improvement.

Recently a new package has revolutionized the creation of a GraphQL API in Laravel. This package makes it so simple and easy to set up a GraphQL server, that it gives you the same feeling you had the first time you worked with Laravel, “What magic is this!”. This package is, of course, Lighthouse.

In this article, I will cover how to set up Lighthouse with a simple blog example. I will assume that you already are familiar with the basics of GraphQL. The example will let you get and create articles via GraphQL. Lighthouse uses a schema approach. You define your API by creating a GraphQL schema, then use directives to add bindings with Laravel.

Installment

For getting started, simply add the package via composer and publish the config file. (The package laravel-graphql-playground is a GraphQL browser client which is optional.)

$ composer require nuwave/lighthouse$ php artisan vendor:publish --provider="Nuwave\Lighthouse\Providers\LighthouseServiceProvider"$ composer require mll-lab/laravel-graphql-playground$ php artisan vendor:publish --provider="MLL\GraphQLPlayground\GraphQLPlaygroundServiceProvider"

Creating the schema

Now for the interesting part: when setting up this package, we just have to create the following file routes/graphql/schema.graphql. This file is the one containing our whole schema for the graphql server.

To get started we will add a simple endpoint for getting all posts in our database. For doing this we first need to create our Article type in the schema file.

...type Article {    id: ID!    title: String!    body: String!    author: User!}

Defining the schema query

We now have two types, a type for articles and one for users, so we can get the author of the post. However we still don’t have any endpoints for the articles, so let’s add one in the schema file.

type Query {  ...  articles: [Article]! @paginate(type: "paginator" model: "Article")}

Now some more magic is happening. We are adding a custom directive called paginate. This directive adds pagination for the given model supplied (in this case Article). We are also saying it should use the type paginator which will result in it making a pagination-compatible type for us.

For browsing the endpoints, let’s open up the GraphQL client we installed by going to your-url.test/graphql-playground. In the schema, we can now see that a new type called ArticlePaginator is added. The endpoint articles is returning an instance of the ArticlePaginator.

Screenshot from graphql-playground

Running the query

So let’s create a simple query to get 10 articles with their title and the name of the author.

query {  articles(count: 10) {    data {      title      author {        name      }    }  }}

When we run this query, it results in an error saying that it was not able to find a class called Article. This makes sense as we haven’t created the model yet. This debug message is only visible because we are not running in a production environment.

Screenshot from graphql-playground showing error of no Article class

Creating our model and migrations

So let’s create our models and migrations. By default, Lighthouse looks for models inside app/models. To make it easier we will add the Article model in here. We do not have to move the User model as in the schema file, the namespace for User has been typed directly.

$ php artisan make:model Models\\Article -m

Then update the migration and the models:

Querying the articles

Now that our models and migrations are set up, let’s migrate the database and check if it still fails.

Screenshot from graphql-playground showing no result

So we can see now that the endpoint works, but we have no data in the database. We will add some manually and then later tackle how to do this through GraphQL.

Screenshot from graphql-playground showing articles

Great! We are now able to fetch articles through GraphQL. Let’s also add support for getting the articles from a user instead. For doing this we have to change our GraphQL user type to have a relationship to articles.

...type User {  id: ID!  name: String!  email: String!  created_at: DateTime!  updated_at: DateTime!  articles: [Article] @hasMany(relation:"articles" type:"paginator")}

Screenshot from graphql-playground showing articles from user

As this is GraphQL, we could keep chaining it. So we can get the author now from the article and then the articles from that author and so on (even though that would be rather pointless).

Screenshot from graphql-playground showing pointless query

Creating a mutator

Now let’s add a mutator for creating a new article. This endpoint will also need authentication. Of course, we need to be a user in the system before we can create a new article. To do this we will use Laravel’s middleware auth:api. Remove all the previous mutations, as we do not need them, and add the following:

type Mutation @group(middleware: ["auth:api"]) {    createArticle(title: String!, body: String!): Article        @create(model: "Article")        @inject(context: "user.id", name: "author_id")}

Authenticating the mutator

To use the auth:api middleware, we will need to set up a Guard. For this example, we will just use the TokenGuard. For using the token guard, we need to add a field to the user called api_token, and then the value there is your token.

Schema::create('users', function (Blueprint $table) {    $table->increments('id');    $table->string('name');    $table->string('email')->unique();    $table->timestamp('email_verified_at')->nullable();    $table->string('password');    $table->string('api_token'); // The new API token field    $table->rememberToken();    $table->timestamps();});

Now we manually add the token in the database and set it to secret (you can create your own UI for setting the token or use Laravel Passport). We then add this token to our request, so we are authenticated.

Screenshot from graphql-playground showing headers

Using the mutator

Screenshot from graphql-playground showing mutation

We now have a new article, and we can see that the author who made it was our authenticated user. So now we have a really simple GraphQL API up and running, but with support for getting our articles and creating them!

Hope you enjoyed this post, and if you would like to know more visit Lighthouse documentation. You can also find the example created above on Github.