What you are billed for
Vercel's pricing page lists image optimization starting at $0.05 per 1,000 transformations, with 5,000 a month included on the Hobby plan. The important nuance is what a transformation is: it tracks the distinct source images processed and the variants produced from them, not the number of times an optimised image is subsequently served. A single photograph rendered at four widths in two formats is a small number of transformations no matter how many visitors see it, and a catalogue of ten thousand product photographs is a large number even on a quiet day.
The shape of site where this matters
A marketing site with a handful of images will never notice this line. A commerce catalogue, a media library, a directory with a logo per entry, or any programmatically generated page family with a distinct image each is where the count scales with your content rather than your traffic. If your image count grows every time you publish, this meter grows with it permanently.
Turning it off globally
The framework-level switch disables optimization for every image at once, causing the original file to be served as-is. This is the right choice when your images are already appropriately sized and compressed at the source, which is common when assets come out of a design pipeline or a content management system that already produces web-ready output. You keep the component and the layout behaviour and stop paying to re-process files that were already correct.
Turning it off selectively
The same opt-out exists per image, which is the more surgical option: leave optimization on for hero images and photography where the gain is real, and disable it for logos, icons, and any asset already delivered in a modern format at the exact display size. This keeps the benefit where it exists and removes the cost where it never did.
Replacing it rather than removing it
The third path is a custom loader pointing at a different optimization service or a content delivery network that transforms images as part of what you already pay it. This preserves the developer-facing API entirely, your components do not change, while moving the work to a provider whose pricing suits your volume better. It is the most work of the three options and the best fit for a large catalogue.
Decide with a measurement, not a preference
Turn it off on a representative page and measure your loading metrics before and after. If the numbers do not move, you have found a pure cost with no corresponding benefit and the decision makes itself. If they do move, keep it and budget the meter deliberately, because on an image-heavy commerce site the conversion value of a faster page comfortably exceeds this line item. Both outcomes are common; the mistake is choosing without checking.
Reader comments
No account needed. Share what worked, what did not, and what you would add.
Add a quick note with the form below. Short, specific tips help the next reader most.