Lighthouse has been one of those tools I've used throughout my web development journey.
For a small website, running a Lighthouse audit manually isn't really a problem.
Open DevTools, run the audit, look through the results, fix what needs fixing, and move on.
That works perfectly well when you're dealing with a handful of pages.
But Web Weavers World isn't really a handful of pages anymore.
As the site has grown, I've found myself wanting to audit more than just the homepage. There are project pages, showcase pages, tools, experiments, forms, and other parts of the site that can all behave differently.
Running Lighthouse manually across all of those pages gets repetitive very quickly.
So, naturally, I automated it.
The Problem Wasn't Lighthouse
I want to make something clear first: manual Lighthouse testing is still useful.
I haven't built this because I think manually running Lighthouse is somehow bad or outdated.
If I'm working on one page and want to quickly see how it's performing, opening Lighthouse and running an audit is probably still the easiest option.
The problem appears when I want to ask a slightly different question:
"How is the whole website doing?"
Suddenly, testing one page isn't enough.
If a website has 5 pages, manually auditing them isn't particularly painful.
If it has 50, 100, or more URLs, that's a very different workflow.
At that point I'm not really spending my time analysing Lighthouse anymore.
I'm spending my time repeatedly launching Lighthouse.
And repetitive development tasks are increasingly becoming something I look at and think:
"Can I automate this?"
Turning Lighthouse Into a PowerShell Function
My solution was to build a PowerShell Lighthouse auditing function.
Instead of opening each page individually, I can give the function the pages I want to audit and let it work through them for me.
More importantly, I added support for sitemap auditing.
That means I can point it at a site's sitemap, let it collect the URLs, and then run Lighthouse against those pages automatically.
For Web Weavers World, that changes the workflow completely.
Instead of:
Audit page.
Wait.
Save results.
Open next page.
Audit page.
Wait.
Repeat.
I can start one audit and let PowerShell work through the site.
Recently I ran it against my sitemap and watched it pass the 100-page mark.
At that point my PowerShell window started looking slightly like one of those games where hundreds of filenames fly past while something loads.
Except this time it was my website being audited.
Automation Doesn't Mean Ignoring the Results
This is something I've been thinking about quite a lot recently.
I've been automating more of my development workflow, but the goal isn't to remove myself from the process.
It's to remove the repetitive parts.
Lighthouse still decides what it wants to flag.
I still have to decide whether those findings matter.
A warning doesn't automatically mean something needs changing, and a good score doesn't automatically mean a page is perfect.
The automation simply gives me the information at a much larger scale.
That's the bit I find useful.
Instead of spending my attention running the tests, I can spend that attention understanding the results.
Then Came the Edge Cases
Of course, automating something that normally expects a human sitting in front of it introduces another problem.
Things go wrong.
One of the first things I wanted my auditor to handle properly was failed or unreachable pages.
When you're manually testing a website and a page doesn't load, you immediately know something has gone wrong.
An automated process needs to know what to do next.
I didn't want one broken URL to kill an entire site audit.
If the auditor has already successfully tested dozens of pages and then encounters one that fails, throwing everything away because of that single page would make the automation considerably less useful.
So the function can record that a page failed and continue onto the next one.
That distinction matters.
A failed page is itself useful information.
A failed audit shouldn't necessarily mean a failed auditing process.
Temporary Files Are Still Files
Another interesting part was cleanup.
Running Lighthouse programmatically creates temporary files and intermediate data that are useful while an audit is running but aren't necessarily things I want hanging around afterwards.
This produced one slightly terrifying moment.
During one of my runs I saw output saying files had been removed.
As a developer who has previously experienced the joy of seeing unexpected "deleted" messages appear in a terminal, that wording gets your attention very quickly.
Thankfully, it was doing exactly what it was supposed to do.
It was cleaning up its own temporary files.
But it highlighted another part of automation that I think is easy to overlook.
Cleanup is part of the feature.
Creating temporary files is fine.
Leaving temporary files scattered around after every audit isn't.
So the auditing process doesn't just need to know how to start.
It needs to know how to finish cleanly as well.
The Interesting Part Is Scale
The actual Lighthouse tests haven't fundamentally changed.
I'm still using Lighthouse.
I'm still looking at performance, accessibility, best practices, SEO, and the other information it provides.
What has changed is the scale at which I can use it.
That's something I've started noticing with quite a few of my development tools.
A manual workflow can be perfectly good and still stop being practical as a project grows.
The question isn't always:
"Is there something wrong with this workflow?"
Sometimes the better question is:
"Does this workflow still scale?"
For manually auditing one page, yes.
For repeatedly auditing an entire site, not really.
And that's where automation becomes useful.
What I've Learnt From Building It
One of the biggest things I've learnt from building development utilities like this is that the main feature is usually the easy part.
"Run Lighthouse against a list of URLs" sounds straightforward.
And conceptually, it is.
But a useful tool has to deal with everything around that happy path.
What happens when a page fails?
What happens when a URL can't be reached?
What happens to temporary files?
Should one failure stop everything else?
How do I make the final results useful instead of producing a mountain of raw output?
Those edge cases are what turn a script that works on my machine once into something I can actually rely on.
And I think that's probably my main takeaway from this project.
Automate the Repetition, Keep the Decisions
I don't think every development task needs automation.
Sometimes clicking a button is genuinely easier than building a system to click the button for you.
But once I notice myself doing the same predictable process dozens of times, that's usually a sign that it's worth reconsidering the workflow.
Lighthouse is a good example.
Manual auditing hasn't become bad.
My website simply grew beyond the point where manually running every audit was the best use of my time.
So now PowerShell handles the repetitive part.
Lighthouse handles the auditing.
And I get to focus on the bit that actually needs a developer:
Deciding what to do with the results.
Sometimes automation doesn't need to replace a tool.
It just needs to make an existing tool easier to use at scale.
Top comments (0)