Spent a weekend rewriting our thumbnail pipeline to output webp instead of jpg, with a jpg fallback for the handful of old clients that need it. I expected a modest win and instead the thumbnail storage footprint dropped by a large chunk, and the grid pages feel noticeably snappier because the images are so much smaller over the wire.
Posting partly as a brag and partly because I almost did not bother, it sat on the todo list for a year. If you are sitting on this one, it was a smaller job than I feared. Happy to share the gotchas.
nice. the gotcha that bit us was the fallback logic, make sure you are actually serving jpg to the clients that need it via content negotiation and not just shipping webp to everyone and hoping. the picture element or a proper Accept header check, otherwise a few users see broken images and you never hear about it
did you look at avif while you were in there? it beats webp again on size, though the encode is slower so it is more cpu at generation time. for thumbnails that are generated once and served forever the tradeoff usually favours the smaller format
the page speed bump is real and google does notice it on the mobile side, so you may get a small ranking tailwind on top of the bandwidth save. worth watching your core web vitals over the next few weeks, the largest image on the grid getting smaller tends to help that metric
one thing to check now that the files are tiny, make sure your cache headers are long and immutable on the thumbnails. when they were big jpgs the cdn did the heavy lifting, but tiny files with short ttls can mean a lot of little origin hits that add up in request count even if bytes are down
Good calls all round. We did go with the picture element for the fallback so negotiation is explicit. Avif is next, I agree the generate once serve forever math favours it. And yes I will push the cache ttl way up now, had not thought about the request count flipping the savings.