The moment cover images became mandatory for every post, build time stretched from around one minute to over four. Image optimization may be a build-time cost you pay only once, but four minutes on every writing session is heavy. I broke the problem into factors and measured each, aiming to win the time back without giving up quality.
Measure where the time goes
The first question is which transformation eats the time. Adding log lines made the breakdown plain:
- Generating width variants: about sixty percent of the total
- AVIF encoding: thirty percent
- Metadata handling and file IO: the remainder
The culprit is the combinatorial explosion of widths times formats — not slow code.
Thinning the width variants
The layout dictates the maximum width a cover can ever render at. Even doubling for a device-pixel ratio of 2, three widths were enough. Cutting the default six variants down to three roughly halved generation time on its own.
Formats and caching
I stopped encoding AVIF alone and, after looking at the audience’s browser mix, went back to pairing it with WebP. On top of that, transformation results are cached by content hash, so unchanged images skip re-encoding entirely. With those two moves, every build after the first takes near-constant time regardless of image count.
Takeaway
Full builds ended at 2m05s, down from 4m10s, and incremental builds hover around 1m10s. I have yet to spot a visual quality difference. The default of “every width, every format” was over-provisioning for peace of mind; working backwards from measured layout widths lets you prune aggressively — obvious in hindsight, but I could not have trusted it without the numbers.