You could possibly also pre-populate cache - all new media files get sent to encoder and cached preemptively, and if they are popular enough they just stay there till they are not.
Please forgive the case study format, but I'm quite proud of what we did and this is the easiest way to back up my assertion with data: https://aws.amazon.com/solutions/case-studies/skyscanner-clo...
We're currently generating JPG, WebP, and PNG, depending on the source and the target. The problem with doing this on-demand is that formats that are great for delivery but slow to encode aren't useful. I did try to add AVIF, but the latency on the first request was too high for it to be practical.
But still, anything AV1 based just needs a lot performance to encode that just doesn't feel worth it at the moment. Our system to encode videos was tooled for that but developers eventually decided it's too slow/cpu hungry to bother. It was some time ago tho, encoders did get better...
(For a large image collection you have some images that are heavily requested and most of the cost is network transfer, but you also have many images that are infrequently requested and for those the cost of storage in the dominant factor. I launched a large image collection in the late 2000's and many sites that did the same thing at the same time were ultimately crushed by running costs, Pinterest and Instagram were survivors, overall the economics of video collections turned up to be better than images.)