My blog was shipping 1.2 MB banners

Wed, 26 Aug 2026 00:00:00 +0000

There’s never a good time to find out your blog is slow, but while people are actually reading it has to be the worst. One of my posts had just gone up on Hacker News, and I was watching the Cloudflare analytics the way you watch a kettle… and somewhere in among the traffic numbers was a much less flattering story about page performance. My pages were heavy. Embarrassingly heavy, for a static site with no JavaScript framework in sight.

The culprit wasn’t hard to find, because it was the prettiest thing on the page.

The covers were the payload

Every post here has a cover image, generated as a nice crisp PNG. And the site was serving those PNGs raw: full resolution, full weight, straight from the repo to your phone. The one at the top of the post being HN’d weighed 1.2 MB. The worst offender in the archive was 7.3 MB. Across the whole blog the covers added up to roughly 163 MB of pixels, most of which were being squeezed into a banner slot a few hundred pixels tall on a mobile screen.

And the averages in the analytics had hidden it beautifully. 28 KB per request looks perfectly reasonable, right up until you notice that the requests that actually matter, the big visual sat above every headline, are forty times that.

The pipeline that was there all along

Here’s the part that stung. Hugo, the static site generator this blog runs on, has excellent image processing built in: resize, re-encode, generate a srcset so browsers pick the right size. And the theme I use supports it. But that support is gated behind a family of imageProcessing params in the site config… and I had never set them. No error, no warning. Unconfigured, the theme simply shrugs and serves the original file.

Which is a config-default trap I keep walking into, one tool at a time. The capable pipeline and the do-nothing default produce the exact same build log, both green, both looking pleased with themselves. You only ever spot the difference in a reader’s download bar, which is about the last place I think to look.

The fix was one config block and two small template overrides. The config turns the quality and filter dials:

[imaging]
 quality = 78
 resampleFilter = "Lanczos"

And a pair of partials, shadowing the theme’s own (the joy of a vendored theme is you can override one file without forking the rest), re-encode every cover to WebP at a ladder of widths (480, 720, 1080, 1440) and emit the srcset, with a full-width WebP as the fallback src so a raw PNG is never served again, to anyone, for any reason.

The numbers, and the wrinkles

The cover that started all this went from 1,197,306 bytes to 68,154 as a full-width WebP, and about 11.5 KB in the 480-wide rendition a phone actually pulls. Call it 94% lighter on desktop and 99% on mobile, multiplied by every post on the site. My earlier back-of-envelope target had been “get each under ~150 KB”; the actual result embarrassed the estimate in the right direction for once.

Two wrinkles earned their own commits. First, the social cards. og:image and twitter:image don’t get the WebP treatment, because the unfurlers at LinkedIn and friends are years behind the browsers and will happily choke on a modern format (or, for that matter, on a multi-megabyte PNG). So those get their own resize down to a 1200-pixel JPEG: 97 KB, down from the same 1.2 MB. It’s a format old enough to vote, but it’s the one thing the bots won’t fall over.

Second, GIFs. These are skipped outright now, and there’s a reason. The first full build after the change went off and tried to re-encode the animated terminal recordings embedded in some of the tutorials, and it promptly ate every byte of memory the build machine had. A static site generator running out of memory over a GIF of a command prompt was not a sentence I ever expected to write… but here we are. gif is now matched and left well alone.

What I can and can’t claim

I banked the Cloudflare baseline before the fix, fully intending to do a smug before-and-after with real-user numbers. Then the launch traffic moved on, life happened, and the “after” snapshot never got pulled. So the plain version is: the byte deltas above are measured and repeatable, and the real-user improvement is merely obvious rather than proven. If I ever re-run the numbers I’ll append them; the megabyte that no longer travels to your phone doesn’t need a dashboard to vouch for it.

So there’s a certain irony in a blog that bangs on about performance and correctness having shipped seven-megabyte banners for weeks without noticing. The cobbler’s children, barefoot as ever. It took the customers turning up at the door all at once before I finally looked down at their feet.

Meta on PHP Boy Scout

My blog was shipping 1.2 MB banners

The covers were the payload

The pipeline that was there all along

The numbers, and the wrinkles

What I can and can’t claim