The fix was mostly plumbing. My img shortcode was handing the raw src straight to the <img> tag, so Hugo never got a look in. Everything now goes through one partial that resizes to the width it actually displays at, re-encodes to WebP and emits a srcset, plus width and height so the layout stops jumping around while things load. Markdown images get the same treatment through a render hook. The awkward bit: images under static/ aren’t resources, so Hugo can’t touch them. A second mount in hugo.toml fixes that without breaking any existing URLs.

While I was in there I dealt with the JavaScript. Every page was carrying all seven inline scripts, even the 90-odd pages with no code blocks, no zoomable images and no locked series titles. Those three now load only where they actually do something. The two that genuinely run everywhere moved into one small fingerprinted bundle, so your browser fetches it once for the whole visit instead of re-reading it on every page. I also finally turned on HTML minification, which I’d apparently never bothered with.

Where it landed:

That last one is about 46 times smaller. Nothing changed visually, which was the whole point. The sparks still spark and the locked titles still scramble.

One last silly thing. I added a new short code to style “Plant Smart” as “Plant🌱Smart”. Fun!

Well, I finally did the thing.

Three and a half years ago I wrote Why I Built Plant🌱Smart. A free and searchable database of plants that are toxic to pets. I built it over a holiday break to answer a simple question, “Can I bring this plant home without endangering the fluffy little gremlin that runs our household?” It was also my excuse to learn SvelteKit, TypeScript, TailwindCSS and Vite, because my frontend peers wouldn’t shut the hell up about them.

The site then chugged along quietly and untouched for years, which sounds like a compliment to its architecture and very much is not one to the maintainer.

The toolchain aged like fine milk.#

The thing no one really thinks about when they build something like this with shiny new frontend tools is that it doesn’t rust, it curdles. When I finally came back to give Plant🌱Smart a fresh coat of paint, the build no longer ran. Not “a few deprecation warnings” didn’t run. It didn’t run at all. Two years of an unattended package.json had fermented into something of a cheese-like consistency.

My original requirements list from 2022 said the site must be fast, static, ( almost ) free to run and open with its data. Nowhere did it say “must still compile in two years”.

So, I decided to spend a few weeks off and on to throw out the toolchain and give it a much-needed refresh. Just like this site, Hugo now builds the entire thing. There’s a single hand-written stylesheet and a few small scripts of delicious vanilla JavaScript. No npm install, because there is no longer anything to install. If I disappear for another two years ( likely ), the site will build exactly the same the day I come back.

First things first, absolute parity.#

The rebuild had one rule that saved me from myself: the first pass had to be a 1:1 replica of the old site. It needed the same pages, filters, URLs and quirks. The pass was meant to be boring on purpose. I had to resist the temptation of doing both the replatforming and redesigning all in one go.

My primary constraint was the plant data. Plant🌱Smart’s whole gimmick is what I called a “dumb API”. The entire primary database lives in one JSON file with other, smaller, supplemental files you could use as lookup tables. Since this was all hosted on Cloudflare’s CDN it was effectively free to use for others without keys or annoying rate limits. The old derivations were originally done by a pile of Go magefiles. The new site had to reproduce them exactly, down to the deliberately unsorted first-appearance ordering, or every downstream consumer would notice.

Hugo, it turns out, can do all of it. A content adapter reads the database and births every plant page directly with no intermediate files. A handful of templates re-implement the old Go derivation logic and regenerate the API on every build. I diffed the generated files against the originals and they came back value-identical on the first honest attempt.

Then came my favourite commit of the whole project:

retire the sveltekit stack: remove src, magefiles and the node toolchain
566 files changed, 112 insertions(+), 9905 deletions(-)

I deleted nearly ten thousand lines and the site did more than before. This is every developer’s favourite kind of commit.

I made the site cute on purpose.#

With the replica shipped, the redesign could actually be fun. The old site was fine but it was very much “2022 Tailwind starter” vibe. A lot of cool greys, hard shadows and gradients on anything that stood still. Meanwhile the logo, a randomised squishy little pastel potted plant with a face, deserved better surroundings.

So, I set out to make the logo the design brief. Cream paper instead of white with warm espresso ink instead of a dull grey. Sage and moss greens with honey and clay accents were all lifted straight from the icon set. Every shadow is tinted warm because plain black shadows on cream look like stickers. The corners got a bit rounder and the controls became pills. The whole thing is set in Fredoka, a rounded display face that weighs about 30kB which I thought fit perfectly with the cute little mascot.

Here are a few before and after shots of the main content pages, with a bonus shot of the new pill navigation that smaller screens finally got:

The data enrichments will continue until “Morella” improves.#

Get it? No? Ok, I’ll see myself out.

The database had severity ratings for every plant, computed from symptom groupings and the old site displayed them precisely nowhere. Now, every card has a severity pill rated from Mild to Critical. The pills are also clickable filters on the main page’s plant cards. Search happens as you type and if you fumble the Latin a bit, a little Levenshtein pass offers “Did you mean Lilium?”. I thought this was a little bit more helpful than what the old site did after literally joking about spelling mistakes in its empty state.

A few other mentionable updates:

• A safe plants list, because the site only ever told you what not to buy. Every entry has to clear the ASPCA non-toxic list and be absent from my own toxic database before it’s allowed in.
• A symptom finder that allows you to perform a plant search backwards. You can click on multiple symptoms and it’ll filter accordingly.
• An emergency strip on every plant page with the poison-control hotlines. Unfortunately, for now, these are US numbers. Localising them by region is on the roadmap.
• Wikipedia descriptions for nearly every plant credited under CC BY-SA.
• Around 3,000 common-name redirects, so /plant/peace-lily/ finally lands somewhere useful.
• Because it made sense, the whole thing is now a PWA and works completely offline. So, now you can use the site in a greenhouse with no signal, which is precisely where this site is most likely to get used.

Once I started auditing the data properly, I started to see a few additional gaps. There were several plants with multiple entries under different, but similar, names. I deduped and merged the symptom data and also updated the severity groupings to make more sense.

I also quickly realised that merging seizure into seizures would have silently promoted over a hundred plants to “Critical”. The severity groups treated those two spellings as different levels. The little cleaner script I threw together caught it during a dry run. The script grew a rule about never merging across severity levels as a result. The plants that genuinely deserved promotion got one. For instance white snakeroot, the plant that killed Lincoln’s mother, was somehow rated “Severe”. The script properly re-rated it to “Critical”.

The enrichment didn’t stop there. I sourced proper taxonomy for every record via GBIF, per-plant toxicity principles with a glossary and little world maps showing their native origins.

There was also quite a bit of fat to trim.#

Somewhere in all this I noticed every page weighed over 200kB. This included pages that were basically just copy. The culprits were painfully self-inflicted. There was an 85kB inline script shipping all ten animated logo SVGs to every single page. The same animal icon inlined seventy times on the front page. Oh, and let’s not forget my personal favourite, the attributions page carrying 149kB of pure indentation that a template loop had quietly emitted. I was shipping whitespace at scale.

The fixes were old-school and very satisfying. A single fingerprinted and cached JS bundle, SVG sprites so each drawing only ships once and one well-placed whitespace trim yielded the following results:

No framework was harmed, or indeed present, in the making of this facelift.

We ship from the homelab now.#

The last box to tick from the original post was the bittersweet one. In 2022 I wanted the project “open-source and community-driven” on GitHub. In practice, the community contribution was me, at midnight, fixing my own typos. So, the repository followed this blog into my homelab using the exact same moving parts as outlined in My Blog Now Ships From My Homelab!. It just made sense after this site’s migration. The data remains as open as ever through the API, which was always the part worth opening. That will never change.

While migrating I had a small panic about the 315MB of plant photos sitting in my working tree, imagining every CI build hauling them across the network. Turns out my 2023 self had already gitignored them and the entire repository clones at 7.5MB. Every once in a blue moon past me does something right. I’ve decided to let sleeping dogs lie and not investigate what else he buried in there.

Was the juice worth the squeeze?#

Very much so. The site is faster, cuter and finally says the most important thing it knows on every card: how dangerous is this plant, not just whether. It builds from nothing with a single binary and deploys itself when I push. The data is cleaner and more robust than it has ever been and enriched well past what 2022 me had the patience for.

But the honest win is the same one as the blog demolition. The whole thing is now boring to operate and boring is what lets a hobby project survive its maintainer’s attention span.

If you have a plant-curious pet, Plant🌱Smart is free, the API is free and the safe list might even let you buy something nice for yourself. And if four years from now there’s a third post in this series, may it be shorter than this one.

Anyways, adios…

So, of course just weeks later I have this burning desire to nuke it all from orbit!

To be clear, the June cleanup wasn’t wrong. The pipeline was genuinely tidy. But, a tidy pipeline is still a pipeline and somewhere between then and now I started asking a more annoying question: why does a personal blog, a pile of static text, need a JavaScript toolchain at all? Why do I need to buy into the Tailwind framework when I knew full well how to write vanilla CSS with my own hands? Every npm install was a little tax that I’d eventually have to pay with interest the next time I wanted to update the site’s dependencies. I felt as if I wasn’t maintaining a blog. I was maintaining the machinery that produces a blog and the machinery had some very strong opinions.

So, I did a hard reset with a very satisfying amount of deleting.

The demolition …#

Here’s the bill for the redesign commit:

230 files changed, 3951 insertions(+), 33365 deletions(-)

That’s roughly a 10-to-1 ratio of deleted to written. Which, as a software engineer, is my favourite kind of ratio. I happily added the following the to chopping block:

• Tailwind v4 and the typography plugin. Replaced by one hand-written CSS file. The whole thing gzips to under ~10kB with syntax highlighting included.
• The entire Node toolchain. The package.json, lockfile, Prettier and its plugins. There is no npm install step anymore because there is no npm anymore.
• Fuse.js and the ⌘K search palette. Nobody was searching this blog. I checked. It was me. I was nobody.
• Two self-hosted webfonts. More on this in a second, because it’s the biggest single win.
• The changelog page. This pulled from the GitHub events API and shipped with an 18,016-line JSON fixture for local dev. Eighteen thousand lines of someone else’s API response, committed to my repo. So, a page barely anybody visited could render in development. I mean, I added it back becase I missed it, but it’s much more efficient now.
• 68 of the 79 icon SVGs. A 390-line drawer menu and a taxonomy I’d stopped using.

The layouts went from 2,868 lines of template across 48 files to about 800 lines across 21. Not because I got cleverer, but because most of that code was written for the joy of it. Which, look, is a fine reason to build something. It’s just a bad reason to keep serving it to strangers. And with all that complexity and cruft came what felt like a lot of brittleness.

The fonts had to go too.#

This one hurt a little. I like Inter and Rubik. Together they were 449kB of woff2 riding along on every first visit. Which made them, by an enormous margin, the heaviest thing on the site.

So, I dropped them and switched to the system font stack which, to my surprise, actually looked better on the site. The actual typeface was doing very little. Your operating system already ships a perfectly good set. All lovingly hinted by people with far more patience and experience than myself. Best of all it costs zero bytes to use!

Hugo, finally home alone.#

Thanks to all the trimmed fat, the build process is effectively just hugo. No more extended binary, SCSS, image processing or defining NODE_VERSION in Cloudflare Pages required. Fewer dependencies mean fewer moving parts and that’s always an improvement.

Numbers, or it didn’t happen.#

Right after the deploy I proudly measured the new site and announced it was “under 100kB”. Which would have been true if the production site were served by my dev server, uncompressed, with a 40kB livereload script attached. I made the mistake of measuring the network stats on my local development server. Womp, womp.

The real numbers, from the live site with Cloudflare’s brotli doing its thing:

The single largest asset on the home page is now the favicon. 7.5kB; roughly a third of the total weight. I think you’re allowed to stop optimising when your largest single asset is your favicon.ico. It’s an image of my gorgeous mug. It stays. I’m quite attached to it.

An ambitious first pass.#

In retrospect, I wanted to make everything simpler and unintentionally over-compensated in the opposite direction. I stripped out too much and was now staring at a sad little blog with zero personality.

So, the second half of the job was building the personality back and making my selections a bit more deliberate. One thing led to another and I think I’ve produced my finest work yet on a personal blog. It’s small and lightening fast. I’m not sure where else I can optimise without drastically affecting the overall vibe of the design; the law of diminishing returns… returns.

The thing about now having such a light frame is adding to it stops feeling like a burden, or something future Wilhelm will have to pay. For example, here are the biggest things I’ve added and they barely increased the overall “weight” of the design.

Series#

A proper taxonomy for multi-part writing. Built because I’ve been wanting to write a Cyberpunk-themed set of tutorials for writing advanced HCL in Go. The series will be about eight posts long and outside of sharing a tag, I had no way to string them together. Series posts wear a stacked-sheet card, a segmented progress meter that is absolutely not a cyberdeck RAM readout and a panel showing every part in the run, including the ones that don’t exist yet.

The unpublished parts of a series ship as glyph noise and decode, left to right, when you point at them. The real titles sit in aria-label the whole time, so a screen reader is never handed the static. The browser tab pulls the same trick on every page load, because a title bar is just a very small marquee nobody was using.

Try moving your mouse pointer over some of the “encrypted” titles on the new dedicated page.

Tired LEDs#

The lit chips in the series meters, static leaders in the main page’s hero section and a scattered handful of cells in the activity graph flicker like hardware that has seen some things. Their animation clocks share no common factors, so the pattern never visibly repeats. The same no-RNG randomness as the heading glitch. On page load the whole graph boots like an old panel, dark, then a sputter per cell, then steady stream of blinking boxes. Reminiscent of the old monochrome screens and beige boxes of my youth.

Christ, I’m getting old.

Changelog, resurrected#

Yes, the one from the butcher’s block above. However, instead of hitting the associated Github repository directly at build time using a PAT, the new one doesn’t call anyone. Commit data is sourced directly from Cloudflare Pages’ shallow clone it checks out during build time. There’s a simple 20-or-so-line shell script reads git log and Hugo renders the result. HEAD gets a lit node that flickers, because why the hell not?

Image shortcodes#

Something I’ve been meaning to add is support for various ways to display images. Each image can now be clicked-to-zoom with attribution in the following forms:

• Masonry.
• A scrollable, horizontal display.
• Last, but not least, the typicla single image display.

There’s actually a sneaky, super-secret page I use to test all my shortcodes and typography stylings where you can see everything for yourself.

Even with all these complex additions, it all adds up to a few kilobytes of CSS and inline script. Which is to say the entire second wave of features weighs an order of magnitude less than one of the webfonts I deleted.

My new favourite fidget toy.#

The part I didn’t expect was to glue my eyeballs to the Firefox throttle menu under its network tools panel.

I flipped it to a 2G profile just for shits and giggles - call it a generous 50kb per second - and did the napkin math. The old site’s 750kB works out to between 60 to 90 seconds of staring at a blank viewport. The new site lands in about four seconds on a connection profile most of the industry stopped thinking about a decade ago.

I have reloaded this page on simulated garbage networks far more times than any reasonable person should, and it is satisfying every single time. The page just… appears. Like a website. Remember plain’ole websites?

None of this is novel, I know. The “your blog doesn’t need 2MB of JavaScript” essay has been written a hundred times. Usually on a blog serving 2MB of JavaScript. I’m not even the hundred-and-first person to do this. But, there’s a difference between nodding along to the idea and watching your own site load over a simulated tin-can connection before you can finish blinking.

In closing …#

The funny thing about the June post is that it ended with me feeling like the blog was finally sorted. And it was! For the architecture it had. It just turned out the architecture itself was the thing that needed to go.

The site is now boring in the best possible way. It builds with one command, it has no dependencies to rot behind my back and the whole design fits in one stylesheet I can actually hold in my head ( not really ). Fewer moving parts, fewer things to forget, fewer surprises the next time I touch it in six months. Best of all, it looks fucking great!

Set-and-forget, but this time with almost nothing left to forget. … Right?