You are paying twice to resize the same image

A structured content platform gives you an image URL you can add parameters to: a width, a crop, a format instruction. Ask for eight hundred pixels wide, cropped to a ratio, format negotiated, and the CDN returns exactly that and caches it.

Then the application passes that URL to a framework image component, which points at a metered optimiser by default. The optimiser fetches the already-correct file and processes it again, producing a set of variants for a responsive srcset. Each distinct source URL and width combination is a separate billable transformation.

Nothing is broken. Pages are fast, images look right, and the only symptom is a line on an invoice that grows with the size of the site rather than with its traffic.

The count is not driven by visitors. It is driven by distinct URLs multiplied by the widths in your srcset. One editorial homepage with a few dozen cards, each at several breakpoints, produces hundreds of distinct transformations on its own, and every new article adds more permanently.

That is why the bill surprises people. Traffic is flat, the site got bigger, and the two things are billed differently.

The fix is a custom image loader. Rather than routing through the metered optimiser, build the URL the CDN already understands: set the width, ask for automatic format, pass quality through.

One detail decides whether this works. Cropped images carry both a width and a height, and scaling the width alone squashes every entry in the srcset below the largest. A sixteen by nine image requested at six hundred and forty comes back at six hundred and forty by nine hundred. The loader has to scale the height with the width to preserve the ratio the crop was chosen for.

Everything valuable about the framework image component survives this: srcset generation, lazy loading, and reserved layout space that prevents shift. What is removed is only the second transformation.

Performance work that ignores the invoice is half the job, and cost work that ignores the user is the other half. A page can be quick and cost more each month than it needs to. It can also be cheap and slow.

So look at both: the transformation count and what it is billed at, alongside field measurements from real devices on real connections. In markets where most traffic is mobile data on older handsets, the field number is the one that decides whether anyone sees the page at all.