Page loads had been creeping up again, so I went looking. Turns out I’d been quietly serving enormous screenshots. One post was pulling 5.1 MB of PNGs, and a single one of those was a 1.96 MB app screenshot sitting in a column 736 pixels wide. Oof.
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:
| what | before | after |
|---|---|---|
| Images the site serves | 12.3 MB | 1.5 MB |
| HTML over the wire, mean per page | 10,236 B | 6,671 B |
| Worst offending post, first paint | 5.1 MB | 112 KB |
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!
Comments