If you run a static Astro site with a few dozen images, you probably only need Astro’s built-in optimization, and paying for a separate service isn’t necessary. If you have thousands of images coming from different sources and needing different sizes for different pages, it’s worth moving that work to Cloudflare Images or imgix. The difference in cost and development time becomes noticeable by the time you hit your second dozen landing pages.
On Astro and Next.js projects, we regularly see the same mistake: a team moves images to an external service “just in case,” even though the site has 30 images that don’t change for months. And the opposite mistake: manually generating five sizes for every image on every build, when a single Cloudflare Images plan with on-the-fly transformation would solve it in an hour of setup. Below is an honest comparison of three approaches by cost, stack integration and real-world scenarios, without a vendor tilt in any direction.
Teams often already trimmed JavaScript, enabled compression and set up caching, but the page still loads slowly - because images remain the heaviest part of most sites. Getting this choice wrong hurts both ways: an external image CDN on a small site is an extra budget line and an extra point of failure, while skipping a CDN on a site with thousands of product photos means manual size generation, a clogged build pipeline and formats drifting apart between environments.
Image CDN: a service that serves images through a CDN and resizes, reformats and requantizes them on the fly based on parameters in the URL - without you having to prepare and store dozens of versions of every image ahead of time.
Short answer: for a site with a stable set of images (a landing page, blog, or catalog up to a couple hundred products), Astro Assets or next/image is usually enough - optimization happens at build time, with no external service. If you’re already on Cloudflare and have a lot of images, go with Cloudflare Images for predictable pricing and simple integration. If you need fine-grained control over transformations, or you work with a large media library or a DAM system (a centralized media asset repository), look at imgix.
What an image CDN actually does
Regular image hosting serves the file as-is: same format, same size, regardless of who’s requesting it or from what device. An image CDN adds a transformation layer on top of delivery.
On a request like /photo.jpg?w=800&fm=avif&q=70, the service resizes, converts the format and requantizes the image on the fly, then caches the result on the CDN’s edge servers. The next request with the same parameters is served straight from cache, without reprocessing.
This solves three problems at once:
- Responsive sizes. A single source image serves the right width for mobile, tablet and desktop through
srcset, without manually generating versions. - Modern formats. AVIF and WebP are served automatically wherever the browser supports them, falling back to JPEG for older clients.
- A single storage point. Source files live in one place (a bucket, a DAM, a CMS), and every derivative version is generated on request rather than stored in advance.
The alternative is a framework’s built-in optimization (Astro Assets, next/image), which does the same thing but at build time or through its own serverless handler, with no third-party service and no separate billing.
Comparison by key parameters
A direct comparison only makes sense on the parameters that actually drive the decision: cost, limits, and how quickly the service fits into your existing stack.
| Parameter | Cloudflare Images | imgix | Astro Assets / next/image |
|---|---|---|---|
| Pricing model | Per stored + delivered image | Per number of origin images and traffic | Free, part of the framework |
| Free tier | Yes, with a limit on image count | Yes, with a limit on origin images and requests | No limits - the only constraint is your build infrastructure |
| AVIF / WebP | Yes, automatic based on the Accept header | Yes, automatic based on the Accept header | Yes, via Sharp at build time (Astro) or the built-in image optimizer (Next.js) |
| On-the-fly transformations | Yes, via URL parameters | Yes, a wide parameter set: cropping, focal points, watermarks | No - only what’s defined in code at build/render time |
| Astro / Next.js integration | Via the astro:assets remote loader or a manual <img> | Via an official or community loader | Native, out of the box |
| CDN coverage | Cloudflare’s network, one of the largest in the world | Its own edge network across several providers | Depends on the site’s hosting (Railway, Vercel, Netlify, etc.) |
| Where it falls short | Weaker fine-grained transformation control than imgix | Gets pricier at high traffic without a negotiated plan | Not suited for user uploads or frequently changing sources outside the repo |
Both Cloudflare Images and imgix start with a free or trial tier limited by image count or requests - check the provider’s site for current numbers, since pricing gets revised periodically.
When to choose Cloudflare Images
Cloudflare Images makes sense if your site is already on Cloudflare - as DNS, proxy, or Pages/Workers - and you want a single bill instead of scattered services.
Pricing here is predictable: you pay for the number of stored images and the number of unique transformations, with no surprises from traffic spikes, because CDN delivery is already part of the same setup. Setup takes hours, not days - a Worker or a plain <img src> with URL parameters, no separate client library needed.
Go with Cloudflare Images when:
- your site is already on Cloudflare (Pages, Workers, or just proxied DNS);
- you have several hundred images or more, updated regularly (a catalog, gallery, or blog with frequent posts);
- predictable, unified pricing matters more than fine-tuning every transformation.
If a team needs to bolt this layer onto an already-running site without a full architecture rebuild, that’s usually a job for enhancing an existing site - adding a new module rather than rebuilding the project from scratch.
When to choose imgix
imgix covers the cases where Cloudflare Images and a framework’s built-in optimization hit a ceiling on flexibility.
imgix has one of the widest sets of transformation parameters on the market: focal points for smart cropping, watermark overlays, PDF and video-preview handling, and support for external storage sources (S3, Google Cloud Storage, DAM systems like Bynder or Cloudinary DAM). This is the case where a marketing or e-commerce team manages its own media library in a separate system, and the site simply requests the right crop on the fly.
Go with imgix when:
- the company already has a DAM or a large media library outside the site’s repo (thousands of product photos, banners for different campaigns);
- you need non-standard transformations - smart face-aware cropping, watermarks, generating previews from PDFs;
- the site isn’t tied to Cloudflare and switching infrastructure for this isn’t worthwhile.
The downside: cost grows faster at high traffic without a negotiated plan, and for a site with a couple hundred images this is more flexibility than you need - and you still pay for it.
When Astro Assets’ built-in optimization is enough
Built-in optimization means astro:assets in Astro or next/image in Next.js. It solves the same format-and-size problem, but without an external service and without a bill in a separate billing system.
At build time, Astro Assets runs images through Sharp, generates AVIF/WebP and the sizes needed for srcset, and outputs the result to static files. Next.js Image does something similar, but it can also run at request time through its own server-side image optimizer.
This is enough when:
- the site is static or nearly static - a landing page, blog, portfolio, or corporate site with up to a couple hundred images;
- the set of images changes rarely and lives in the repo or a CMS with a familiar publishing pipeline;
- you don’t need to serve the same source image in very different crops for different clients (web, app, partner widgets).
The line is simple: as soon as images stop fitting in the repo or start arriving from external sources on the fly (user uploads, integration with an external catalog), built-in optimization hits its build limits, and the conversation comes back to a CDN layer. If your LCP is already suffering specifically because of image format and load priority rather than delivery architecture, that’s a separate problem we covered in our article on optimizing LCP with AVIF, WebP and srcset. That piece is about compression technique and priority for a single image; this one is about where and how the image gets served at all.
What changes after switching approach, on a real case
A telling scenario: a services site running ad traffic, around 15 landing pages, each with 20-40 images across hero blocks, case galleries and testimonials.
Before switching to an image CDN, sources were stored at mixed resolutions, some as uncompressed JPEGs, with no srcset configured. Based on what we’ve seen on similar projects, total page weight under these conditions usually sits in the 3-4 MB range, with LCP around 4-4.5 seconds on mobile 4G.
After moving image delivery to Cloudflare Images with automatic AVIF/WebP and responsive sizes, page weight on similar projects usually drops to 1-1.5 MB, and LCP to 2-2.3 seconds. Exact numbers depend on the original photo quality and page structure, but the order of improvement holds - a 2-3x drop in weight and roughly half the LCP, with no change to the design itself.
On top of that, separate work on load priority (fetchpriority, removing loading="lazy" from the hero image) gives an additional gain beyond the CDN-layer switch - that’s a matter of technique, not infrastructure.
Who this matters for
This choice matters for teams building on Astro, Next.js or a similar stack who have already hit image weight as a performance bottleneck - marketing agencies, e-commerce sites with a growing catalog, SaaS companies with a blog and a library of product screenshots. For a single-page site with a dozen images, this article is more likely to confirm you don’t need an external service yet than to push you toward adding one.
Frequently asked questions
Can I use Cloudflare Images without the rest of the Cloudflare stack? Technically yes - you can hook up just Cloudflare Images as a standalone service without moving your DNS or hosting to Cloudflare. But then part of the benefit (unified billing, a shared CDN network with the rest of the site’s traffic) goes away, and the cost decision should be compared against imgix on equal terms. If your site runs on Vercel, Netlify or Railway and moving to Cloudflare isn’t planned, the convenience gap between Cloudflare Images and imgix in this scenario nearly disappears - the choice comes down to price and the specific transformations you need.
Does imgix work with Astro out of the box?
There’s no official integration at the level of astro:assets for imgix, but hooking it up comes down to building a URL with the right transformation parameters and using it with a plain <img> or <Image> component. That’s a bit more manual work than native Astro Assets, but without restrictions on where the source images come from. In practice, it’s enough to write a small helper function that builds a URL with width, format and quality parameters, and reuse it across every image component on the site.
What should I use for a small landing page with 10-15 images?
Built-in optimization - Astro Assets or next/image. Adding an external image CDN for a dozen and a half images usually doesn’t pay off, in money or in setup time - the speed gain would be minimal compared to AVIF/WebP already compressed at build time. An external service at this scale is only worth considering if you know in advance that your media library will grow several times over in the coming months and you don’t want to redo image delivery later, mid-project.
Do I need an image CDN if I’m already using Astro Image for compression? If your images are static and live in the repo - no, Astro Assets already handles formats and sizes. A CDN layer becomes worth adding once images start arriving dynamically: from a CMS, from users, or from an external catalog that Astro’s build process can’t reach. A mixed setup is also possible - some images (logos, icons, static banners) stay on Astro Assets, while dynamic content moves to an external service.
How do I tell if my current image delivery is slowing down the site? Check the Network tab in DevTools on your heaviest page, and the LCP element section in PageSpeed Insights or Lighthouse. If the heaviest image is over 200-300 KB after compression, or isn’t served in AVIF/WebP where the browser supports it, switching your delivery approach will likely pay off. Another signal: if developers are manually preparing several versions of every image before uploading it to the site - that’s a clear sign it’s time to automate this through a CDN layer or the framework’s built-in optimization.
Bottom line
Astro Assets’ and next/image’s built-in optimization covers most sites without adding a single extra line to your bill. An external image CDN is worth it once you have a lot of images, they come from different sources, or they need transformations the framework’s build process can’t do - and then the choice is between Cloudflare Images’ predictable pricing and imgix’s flexibility.
If images have already become a speed bottleneck on your site, or your media library has outgrown what the framework’s build can handle - describe your architecture and media library size to the Exceltic.dev team. We’ll look at your current image delivery and work out what a CDN approach change would gain you, versus what a targeted fix would already solve.