How to Configure Lighthouse for Balanced Quality Websites

Published on Oct 15, 2018 (updated Jun 14, 2024), filed under development, quality. (Share this post, e.g., on Mastodon.)

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 an engineering lead, guerrilla philosopher, and indie publisher. I’ve worked as a technical lead and engineering manager at various companies (e.g., Google); I’m an active web and tool developer (code optimization, digital defense), a contributor to web standards (like HTML, CSS, WCAG), and a book author (O’Reilly, Frontend Dogma).

I love trying things—in web development and engineering management, but also in politics and philosophy, where I hold to one idea in particular: that we can only be well if we take good care of everyone. Here on meiert.com I talk about some of my perspectives and experiences. (Interpret charitably but be critical—and share feedback and advice that makes my work better.)