Introduction
After switching to headless EC (a setup where the commerce platform such as Shopify and the storefront pages are built separately), you may run into complaints like "the hosting bill is higher than expected" or "pages slow down during sales." Dig into the cause, and it often turns out to be how product images are delivered.
The motorcycle-gear EC site I operate ran into exactly this problem. This article explains what changes about image delivery when you go headless, and how much extra load and cost you can expect if you leave it as is. By the end, you should be able to judge whether your own site needs countermeasures.
Going Headless Changes the Path Images Travel
With a Traditional Shopify Theme, Shopify Handled Images
With a traditional Shopify theme, product images are delivered straight to users from Shopify's CDN (a network of distribution points placed around the world).
In one sentence: all the image work was done for you by Shopify. Resizing, compression, and delivery all happen on Shopify's side, so operators rarely have to think about images at all.
In a Headless Setup, Your Server Becomes the Image Handler
Once you go headless, pages are served from hosting you provide yourself (Vercel, AWS, or similar — the place where your built pages live). The image path changes too, and depending on the setup, your own server ends up handling image fetching, conversion, and delivery.
In other words, the image work Shopify used to do moves wholesale onto your server. Using Next.js's built-in image feature (Next.js Image) doesn't change this either — every conversion still consumes processing on the hosting side.
What Happens If You Leave It Alone
Image Work Eats Up Your Server's Capacity
A product listing page shows 20–50 images at once. Each one triggers fetching the original, resizing, format conversion (to lighter formats like WebP), and compression, so the more traffic you get, the more of your server's computing power goes to image processing. During traffic spikes like sales, image processing can fall behind and slow down the entire site.
Hosting Costs Rise in Proportion to Conversions
Vercel's image optimization bills by the number of conversions, with overage charges once you exceed your plan's allowance. EC sites with large catalogs hit that ceiling quickly. At 100,000 page views per month with an average of 20 images per page, that's roughly 2,000,000 image requests monthly. Even with caching (reusing already-converted images), the cost is hard to ignore. Building your own conversion pipeline on AWS doesn't escape this either — you pay by execution time and request count.
More Cache Variants, More Complexity
Even for a single product image, each combination of display size (1x, 2x, 3x) and format (WebP, AVIF, JPEG) needs its own cached copy. With 500 products and 5 images each, you have 2,500 originals — but multiplied by the variants, the cache runs to around 15,000 files. Every new product or image swap invalidates cache entries, so sites with fast-moving catalogs end up re-converting constantly.
How to Tell If Your Site Needs Countermeasures
Conditions That Amplify the Problem
The more of these apply, the faster image load and costs grow:
- A catalog of hundreds to thousands of products
- Fast product turnover (apparel, general goods, and the like)
- High-resolution photography (fashion, interiors)
- Traffic spikes during sales
- Users overseas, requiring delivery to multiple regions
Conversely, if you have a few dozen products and steady, modest traffic, the standard setup may be fine for now — that's a legitimate conclusion too.
A Rough Calculation Makes the Scale Concrete
To judge whether you need to act, estimate the number of files to cache with "products × images per product × size-and-format combinations," and monthly image requests with "monthly page views × images per page." When I ran these numbers for the site I operate, the potential overage cost without countermeasures came to tens of thousands of yen per month, which settled the decision to restructure. Numbers make the judgment concrete.
The Direction of the Fix — Hand Image Work to a Specialist Service
The basic strategy is to detach image conversion and delivery from your own server and entrust them to an external image delivery service. The best-known option is Cloudinary (a cloud service specializing in image transformation, optimization, and delivery). Route Shopify product images through Cloudinary, and your server's image workload drops to zero.
It's the same division of labor as the traditional Shopify theme — where Shopify was the image handler — rebuilt for a headless setup with a specialist service in that role. The next two articles cover what the service actually does, how to decide whether it fits, and how to build the pipeline.