Maintenance has its way of killing perfectionism. We try so hard to solve all the things, but all the things are never solved.

Don’t just take my word for it. Listen to xkcd:

I’m just gonna leave this here… (tldr: it’s mathematically impossible to solve all the things)

It may seem that the natural state of things is to defy one’s every attempt. The more effort we put toward fixing an issue, three other undesirable ones appear. An endless string of code snippets yelling out “help me!” as one struggles in vain to afford time for all of them. Sorry, little binary buddies, I simply don’t have enough hours in my sprint!

We’ve gotta triage.

It’s technological triage, and it sucks. It can be a depressing fact but it’s important reminder of what we, as developers, are really trying to do each day:

  1. Add judiciously
  2. Maintain enough to quell the behemoth
  3. Sleep
  4. Shower
  5. Repeat.

(Feel free to add another shower or three in that mix. It does wonders to your concentration.)

How do we allocate the resources in a balanced way? How do we know when to fix, when to ignore, when to push, when to take a break? How do we balance the equation?

Money and time balanced on a scale

Time is money, bro.

As a developer always striving for the perfect mix of obsession and expediency, I like metrics that tell me where I should focus more of my time in my bug hunting efforts. Metrics are great shortcuts for my time and sanity. Where do I need to focus? Ah, right, in Area X, because that’s what this intelligently-informed metric says, and I’m in no position or mood to question it.

This week, as I was dedicating my life to resolving all my site’s bugs, Google’s Lighthouse became my new best friend.

Lighthouse is a potent potpourri of performance metrics.

Some of you may have noticed that I’ve made several releases to my site over this past month. In fact, I’m already building a recipe for the batch of hotfixes hot on the tail of my site’s version 1.5.0 release, which I pushed a few days ago.

Already I’ve plowed through a ton of the top-grass: little UI tweaks, minor script bugs, ya know, the small things. Plus I added a scoop of whipped-cream topping: lazyloadable images, search-engine chummy JSON-LD, and some cool Google Analytics indicators. Yummy.

Now, I’m seeing mostly shrub and hidden weeds. This is where the real maintenance work begins.

I got a verdict…

So, to help me sort though the brush and weeds, I fired up Lighthouse and ran it on my site’s heaviest page, the home page, and got this result:

My score wasn’t impressive (unless you’re impressed by bad scores). Yeah, you could say my tweet’s analysis was understating the issue — my site evidently needs a lot of TLC. No surprise that I scored excellent in the realms of SEO and best practices. But the 29 score on performance was bitter. In developing my own site over a 100-megabit connection, I hadn’t made sure to remain conscious of some of the pitfalls that 3G-conscious Lighthouse ratted me out about. Face, meet egg.

… and a super-helpful report!

Clearly, this report has an upside for me: A failure is a superb opportunity to succeed! In its own adorable language of red, orange, and green, Lighthouse is telling me that:

  1. I am not perfect (no surprise there, really)
  2. I should have used it earlier (clearly this is the case, amirite?)
  3. I now have a laundry list of todos that it knows I can accomplish (otherwise, why would it tell me these things???)

So, I set out on my self-assigned quest to achieve a more-perfect score.

In A World, where bugs rule the galaxy, a HeroHuman awaits, armed with devtools, data, and a killer demeanor, enough to slay even the toughest critters.

Don LaFontaine, beyond the grave, saying all the things he should have said but was never paid to say. R.I.P.


Over a handful of hours and probably as many cups of coffee, I was able to produce a substantially improved score from Lighthouse:

While it isn’t in the green, it’s a 20+ point boost into the orange range, and orange is better than red here. Lighthouse clearly thinks there’s a significant improvement to be noted — woohoo me!

But, we’re not yet in green territory. Why? Because Lighthouse is especially unhappy about some things I don’t have direct control over.

That, of course, is not an excuse for me. A responsible supervisor wouldn’t look at that and think “no problem here.” Lighthouse is Google’s product; if I want to please the gorilla, I should definitely listen to its demands.

Now, I have a solid case for spending time and resources toward developing a more efficient solution. The next step: Pinpoint exactly what are the problems, whereas Lighthouse has given a high-level analysis.

Major takeaway

This meticulous process to discover, classify and prioritize those problems led me to some pretty neat conclusions. Above all in importance: Twitter’s platform.js is a bloated #whale.

Twitter’s impact on a page’s performance is gross. I’m not surprised that my use of external libraries would aggravate Google’s effort to minimize my home page’s weight. But, I was shocked to see just how much unnecessary code there is in Twitter’s payload. Evidently, ~95% of the their lib code is deadweight to my site.

Illustration of a dead whale beached
A literal example of deadweight. #grimshot

For just displaying a simple timeline, I definitely don’t need everything.

Why can’t Twitter just be nice and offer minimal subsets for major cases, like when someone just wants to embed a simple timeline? Feels to me like an oversight on Twitter’s end, or it’s some heavy desire of theirs to accomplish a load-once scenario, but at the end user’s expense. Either way, not cool, and I’m not happy about it.

Clearly if I want to make good on my commitment to ace the Lighthouse exam, I need to make a better solution for my site.

I need to eliminate or sharply reduce site’s reliance on Twitter’s platform.js script. Instead of loading that gorilla’s weight, I’m going to roll my own. I’ll poll my timeline via their API, then I’ll cache and render the pretty things from their JSON response data. Perhaps I’ll even package my solution as an open-source WordPress plugin. #efficiency #ownership #community

TLDR: Big Bugs First

While it can be appealing to us to always kill the small stuff first, the “small stuff first” strategy doesn’t always lead us to the best outcome. If we always focus on the small stuff, we may never touch the big stuff.

Size matters.

Magnified view of roach on human skin
My skin crawls just by looking at this bug. Imagine how your repository feels.

The big bug for my site is a severely bloated external library. Until I kill it, I’d be spending way more time per unit of work. Meanwhile, I’d be ignoring the biggest way to lower my site’s technical debt.

If I ignore this big bug and resolve all the small bugs, I could still end up with my site having a terrible Lighthouse score, because the big bug is so damn big.

Focus on the big bugs. Don’t ignore the small ones, but especially don’t ignore the big ones. The goal is as much about the user’s perceived experience (the big changes) as it is about the overall picture (a string of small changes).


Just running my personal site through Lighthouse told me a lot in terms of its major areas for improvement. Without that free rubric, my site may have gone on to annoy countless number of poor souls bound to a depressing 3G (or worse!) connection. What a horrible outcome that would have made.

Though my site is aimed at audiences that have near-constant access to high-speed internet, I don’t want to ignore a large segment of the world community by prejudging them on the basis of their connection speed. And I certainly want to be super-conscious of Lighthouse’s opinion of any site I aim at a broader audience.

Where to find Lighthouse

Screenshot of the Audits tab in Chrome's Developer Tools pane

I highly recommend adding Lighthouse to your regular workflow. You can find it in Chrome and Chromium, in the Developer Tools pane, in the Audits tab.