A single upload can quietly spawn twenty or thirty resized copies you’ll never serve. Making each size only when a visitor asks for it trims the bloat without slowing anything down.
Table of Contents
How WordPress handles images by default
WordPress is proactive. Upload one image and the server immediately resizes it into every dimension your theme and plugins have registered – the three core sizes plus whatever a heavy multipurpose theme and its add-ons declare. A single hero image can become fifteen, twenty, or thirty files. Most of those sizes are never actually served to a visitor, yet they all sit on disk, swell every backup, and slow every migration and sync.
Most of the thumbnails WordPress builds on upload are never served – they just sit in every backup you take.
What “on the fly” changes
On-the-fly generation is reactive. The logic is simple:
- You upload one high-resolution original. No resized copies are made yet.
- A page loads that needs, say, a 300-pixel-wide version for a card on a phone.
- The system checks: does that exact size exist? If no, it generates it right then, serves it, and caches it.
- Every later visitor who needs that size gets the cached file instantly.
The site ends up storing only the sizes people genuinely request, in the dimensions they’re actually viewed at – not a full matrix of every size something might one day use.
Why it helps performance and SEO
The win isn’t a faster image on any single view – a cached OTF thumbnail serves exactly as fast as a pre-built one. The wins are structural:
- Less bloat. You store a handful of real sizes instead of dozens of speculative ones, so the uploads folder stays small.
- Smaller, faster backups and migrations. Fewer files means less to copy, which is where the “server bloat” pain actually bites.
- Right-sized images for Core Web Vitals. Because sizes are generated to match how images are really requested, a page can serve a tightly-fitted file, which helps Largest Contentful Paint (LCP) – a real Google ranking signal – without shipping oversized images.
On-the-fly doesn’t make the served image faster; it makes everything around it – storage, backups, migrations – lighter.
The trade-off to plan for
The one cost is the first request for a size: that visitor waits for the file to be generated before it’s cached. On a busy page this is invisible, but there are two things to get right. First, make sure the cache is durable and, ideally, sits behind or in front of a CDN, so a generated size is reused widely rather than rebuilt. Second, decide what happens to the original – OTF keeps a high-resolution master, so store it sensibly rather than deleting it, because every future size is derived from it.
When it’s worth switching
On-the-fly generation pays off most on image-heavy sites with themes that register many sizes – exactly the case where the default matrix explodes into dozens of files per upload. A small site with a lean theme and a few registered sizes gains little and can stay on the default. The heavier your theme’s size list and the larger your library, the more the reactive approach saves you in storage and operational drag.
The short version
By default WordPress builds every registered thumbnail size the moment you upload an image, most of which are never served but all of which bloat your disk, backups and migrations. On-the-fly generation instead keeps the original and creates each size only when a visitor first requests it, caching it thereafter. The served image is just as fast, while storage and operations get much lighter. Plan for the one-time cost of generating a size on first request – back it with a durable cache and a CDN – and reach for it when a heavy theme and a large library make the default size matrix unmanageable.
Frequently Asked Questions
Does on-the-fly generation make my images load slower?
No, not for the visitor in the normal case. Once a size has been generated and cached, it serves exactly as fast as a pre-built file. The only wait is the very first request for a given size, which is then cached for everyone after.
What happens to the sizes I never use?
They’re simply never created. That’s the whole point: instead of pre-building every registered dimension, the system only ever generates the sizes real pages request, so your uploads folder holds a handful of files rather than dozens.
Will this help my Core Web Vitals score?
Indirectly, yes. Because sizes are generated to match how images are actually requested, pages can serve tightly-fitted files rather than oversized ones, which supports Largest Contentful Paint. It won’t fix a slow server on its own, but it removes one common source of over-fetching.
Do I still keep the original image?
Yes – the high-resolution original is essential, because every on-the-fly size is derived from it. Store the master reliably; deleting it would leave the system with nothing to resize from.
Is on-the-fly generation worth it for a small site?
Usually not. A lean theme that registers only a few sizes doesn’t produce the size explosion that OTF solves, so the default handling is fine. The approach earns its keep on image-heavy sites with themes and plugins that register many dimensions.
