Google Lighthouse and PWA

Published on January 17, 2019 (↻ June 16, 2024), filed under (RSS feed for all categories).

This [now partially outdated] article has been in the making for a while and as it happens, it just got hit by a major update of Lighthouse, Lighthouse release 4.0.0. And yet, I believe all is not lost and it will be very interesting to compare this review of Lighthouse 3 with version 4, because some issues persist. In the meantime, I’ll wonder whether dropping this post and writing a new one would have been the more favorable option. Swearword.

Google Lighthouse is a useful analysis tool but the PWA category’s audits appear questionable and should in many cases be disabled. Why? From my point of view Google has so far done an incomplete job normalizing the category and making it really useful. Let’s have a look.

The PWA Audits

When we start with the assumption that the test object is, indeed, a web app, about half of the PWA audits are reasonable. If we understand manifests and service workers as implicit parts of a PWA, it’s legitimate to check on them.

However, a good number of audits suffers of one of the following problems: They’re either weak or they belong to a different category (if they’re not a duplicate).

The PWA Category

Now that we checked the individual PWA audits—of which the rest is sound–, we get a better idea of the usefulness of the category.

Apparently there was a strong urge to have a category just for PWA. Well. But what then seems to have happened is a problem all of Lighthouse now suffers from: Some checks have been moved to “PWA” that better fit elsewhere (viewport, load time, encryption), and then the category looks like it got filled up for good measure (colors, scripting, splash screens).

This seems to have happened. But even if the story is different, the outcome, at this point, means a weak architecture that undermines Lighthouse’s usefulness as a whole:

If Lighthouse would make out the difference between sites and apps, would focus on important criteria (not colors and modals and such), and had its information architecture normalized to allow for some sort of General checks, it could up the ante to be even more useful, in a more usable fashion—by default.

I will have erred in some aspect or other, but that’s my current take on Lighthouse. If you’re interested in some of the tests we consensually disabled at sum.cumo, or the wrapper we use to simplify Lighthouse configuration, stay tuned over at and check out Lighthouse Keeper. And then let’s see what I can do to merge this review with Lighthouse 4.

Val strides swiftly eastward, using the forest paths. He only sees his men when a shadowy figure steps silently from among the trees and gives him directions.

Figure: Lighthouse would sometimes suggest a different route. (Copyright King Features Syndicate, Inc., distr. Bulls.)

Was this useful or interesting? Share (toot) this post, or maybe treat me to a coffee. Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

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 close to W3C and WHATWG, 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 I share some of my views and experiences.

If you want to do me a favor, interpret charitably (I speak three languages, and they can collide), yet be critical and give feedback for me to learn and improve. Thank you!