Jens Oliver Meiert

How to Configure Lighthouse for Balanced Quality Websites

Post from October 15, 2018 (↻ November 14, 2018), filed under .

While we’re at it, here’s a short treatise just about managing the quality of websites: The Little Book of Website Quality Control.

Google’s Lighthouse is a great tool, whether used in Chrome DevTools, as a Chrome extension, or as a Node module. Alas, it also has some (in my view unnecessary and avoidable) issues, most notably around what Google pushes as “progressive web apps”—these soft and arbitrary preferences (colors!) shouldn’t land in a tool geared towards hard and objective quality criteria (more on PWA elsewhere).

Fortunately, it’s possible to configure Lighthouse to one’s own views on what matters. Here’s the config that I like to use running Lighthouse as a Node module, flanked by the steps needed to get the setup running immediately:

First the config itself,

module.exports = {
  extends: 'lighthouse:default',
  settings: {
    'scores': {
      'performance': 90,
      'accessibility': 90,
      'best-practices': 90,
      'seo': 80
    },
    'onlyCategories': [
      'performance',
      'accessibility',
      'best-practices',
      'seo'
    ],
    'skipAudits': [
      'byte-efficiency/uses-responsive-images',
      'byte-efficiency/uses-webp-images',
      'seo/meta-description'
    ]
  },
};

which goes into a lighthouse-config.js (gist) in the project root.

In package.json (make sure to have Lighthouse installed—npm i lighthouse -g), the following script ("scripts" section) should be included:

"lighthouse": "lighthouse --config-path=lighthouse-config.js --"

…which now allows to run tests through npm run lighthouse http://example.com/.

The Config

Key point of this post, why this config, why these modifications?

The categories: As noted above, I strongly doubt, in fact discard, the usefulness of the “progressive web app” category (and as also noted, I’ll elaborate separately). Therefore, in my own and suggested config I’ve removed this category entirely.

The audits: Having audited all Lighthouse checks for sum.cumo, most checks are quite reasonable, but apart from the PWA ones the ones around responsive images, WebP, and meta descriptions appear little useful if not harmful to me. The first wants to sacrifice too much code purity, the second comes with so far little robustness (and smells a bit like marketing), and the third is sneaky (I’ve for their forcing on extra work and their hidden nature despised and therefore avoided meta descriptions throughout my career, and deem them another machine problem pushed on humans).

The ratings: Performance, Accessibility, and the following of Best Practices look very important to me, when SEO comes a little behind these; and therefore to find a balance between good quality and flexibility I’ve found 90/90/90/80 to be a reasonable baseline for the projects I’m using Lighthouse with.

❧ Lighthouse is a useful tool, and it complements nicely the many other web development tools we have at our disposal. With the mentioned config, I find Lighthouse to be better suited to meet the needs of the projects I develop and maintain—perhaps that’s the case with yours, too.

About the Author

Jens Oliver Meiert, photo of September 22, 2018.

Jens Oliver Meiert is an author and developer (O’Reilly, W3C, ex-Google). He plays with philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.

There’s more Jens in the archives and at Goodreads. If you have any questions or concerns (or recommendations) about what he writes, leave a comment or a message.

Read More

Have a look at the most popular posts, possibly including:

Say hello on Twitter or LinkedIn.

Looking for a way to comment? Comments have been disabled, unfortunately.

Found a mistake? Email me, jens@meiert.com.

You are here: HomeArchive2018 → How to Configure Lighthouse for Balanced Quality Websites

Last update: November 14, 2018

Awareness, honesty, responsibility.