Over my years of personal experience, I’ve found to be true, that 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)

Though 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 yell out “help me!” as one human 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.

I plowed through a ton of the top-grass.
  • little UI tweaks
  • minor script bugs
  • ya know, the small things.

Plus, I added some scoops 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.

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 was understating the issue.

According to Google, my site evidently needs a lot of TLC.

I expected excellent scores in the SEO and best practices realms, but the 29 score on performance was a bitter pill. In developing my own site over a 100-megabit connection, I had neglected the constraints put upon my visitors from 3G Land, while Lighthouse caught them with ease.

Face, meet egg.

Though my initial performance disappointed me a bit, this report has an upside for me: A failure is a superb opportunity to succeed!

In its adorable language of red, orange, and green, Lighthouse is telling me that I:

  1. am not perfect (but no surprise there, really).
  2. should have used it earlier.
  3. now have a laundry list of todos it’s provided me and knows I can accomplish. (Otherwise, why would it tell me these things?)

So, I set out on a quest to improve upon my first-round 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.

Results after first round of improvements

Over a handful of hours, and also probably from as many cups of coffee, I was able to improve my site’s Lighthouse score dramatically!

Though the Performance metric doesn’t yet report me a score in the green range, it’s a 20+ point increase from my previously terrible score, a boost into the orange range, and orange is better than red here.

TL;DR: 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, then 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 takeaways

This meticulous process to discover, classify and prioritize those problems led me to some pretty neat conclusions.

Twitter’s platform.js is a bloated #whale.
Illustration of a dead whale beached
A literal example of deadweight. #grimshot

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.

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

TL;DR for this post, in one phrase: 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.

Until I kill my site’s dependency on a severely bloated external library, 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 the overall picture (a string of small changes).


  • Just running my personal site through Lighthouse told me a lot in terms of 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.