Jens Oliver Meiert

Google Lighthouse and PWA

Post from January 17, 2019, filed under .

This 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 sumcumo.com 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.)

About the Author

Jens Oliver Meiert, photo of December 23, 2018.

Jens Oliver Meiert is a tech lead and author (sum.cumo, W3C, O’Reilly). He experiments with philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.

There’s more Jens in the archives and at Goodreads. If you have any questions or concerns (or recommendations) about what he writes, leave a comment or a message.

Read More

Have a look at the most popular posts, possibly including:

Say hello on Twitter or LinkedIn.

Looking for a way to comment? Comments have been disabled, unfortunately.

Found a mistake? Email me, jens@meiert.com.

You are here: HomeArchive2019 → Google Lighthouse and PWA

Last update: January 17, 2019

Awareness, honesty, responsibility.