How to Configure Lighthouse for Balanced Quality Websites

Post from October 15, 2018 (↻ December 5, 2021), filed under  (feed).

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). Then, 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': [
    'skipAudits': [

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

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.

Toot or tweet about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!