How to Configure Lighthouse for Balanced Quality Websites

Published on Oct 15, 2018 (updated Jun 14, 2024), filed under development, quality (feed). (Share this on Mastodon or Bluesky?)

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

This post is partially outdated.

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.

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 -g lighthouse), 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 https://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 (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 Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)