How to Configure Lighthouse for Balanced Quality Websites

Published on October 15, 2018 (↻ June 14, 2024), filed under Development (RSS feed for all categories).

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 frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, 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. (Please be critical, interpret charitably, and give feedback.)