Image delivery needs a CDN, not just a storage bucket

Why media delivery is a performance problem, not just a storage problem

"Media management" often gets scoped as an upload form and a database record. That framing misses the part that actually affects visitors: how the resulting file reaches a browser, and how long it takes to get there.

Storing an image is the easy part. Serving it fast, at the right size, on every request is where most media pipelines fall down. Images account for roughly 60-70% of the average webpage's total weight. (Source) That makes images the single biggest lever for page performance on most sites.

Sites that treat media delivery seriously see it in their Core Web Vitals. The share of mobile pages passing a good Largest Contentful Paint score rose from 44% in 2022 to 62% in 2025, per HTTP Archive's Web Almanac data, reported by Hostinger. (Source) Largest Contentful Paint is usually an image. Fixing how that image gets processed and cached moves the metric directly.

A CMS that only stores the original file pushes this work back onto your app. You build a resize pipeline yourself. You set your own cache headers by hand. You hope nothing regresses when traffic spikes. A CMS that treats media as a delivery problem does that work once, centrally, for every asset, instead of once per project.

The storage layer and the delivery layer are not the same job. Storage just needs to keep the bytes safe. Delivery needs the right format, the right size, and a cache policy that keeps a CDN from re-fetching the same file on every request. Conflating the two is why so many teams end up with slow image-heavy pages despite paying for fast hosting.

This is also why "just use S3" is an incomplete answer. A bucket alone has no concept of image variants, no processing step, and no cache policy attached by default. It will happily serve a 6MB original to a mobile visitor on a slow connection, at the same speed it serves a 6MB original to anyone else, because nothing in that setup distinguishes a media asset from any other blob of bytes.

A CDN in front of that bucket helps with geography, but it can only cache what the origin tells it to cache. Without a Cache-Control header on the response, a CDN has no signal for how long a given image is safe to keep at the edge. The header and the CDN are two halves of the same mechanism — one is useless to a visitor without the other.

How Draftbase handles media management and CDN delivery

Media management in Draftbase is a pipeline, not a single upload endpoint. Four pieces work together: a presigned upload step, an async processing step, an explicit cache policy on the CDN delivery path, and entry-level versioning. Each step exists to remove one specific failure mode teams hit when they build this themselves.

This split mirrors the write/read separation the rest of Draftbase already uses for content: writes go through an authenticated management surface, reads go through a separate delivery path built for speed. Media follows the same shape — the upload and confirm steps are management operations, and the CDN-fronted URL is the delivery side, cached and public.

Put together, this covers the four places a homegrown media pipeline usually breaks: a blocked API request during upload, an unprocessed original served at full size, a missing cache header that forces re-fetches on every load, and a swapped image with no record of when or why it changed.

None of these four pieces requires configuration before an upload works. The presigned URL flow, the Lambda trigger, and the delivery cache headers are wired up by default for every environment in an org. What's configurable is the cache max-age and the org's upload size limit, so the defaults match a typical site and the knobs are there for the cases that don't.

Media management and CDN delivery approaches compared

The table below lines up three common setups: rolling your own upload path against a plain S3 bucket, a generic headless CMS media field, and Draftbase's pipeline. The differences show up most in processing and caching, the two steps teams skip first under deadline pressure. None of the three approaches is wrong on day one — a plain bucket works fine for a handful of images. The gap widens as asset count and traffic grow, which is exactly when a manual pipeline is hardest to retrofit.

Upload path and processing get most of the attention because they're visible during development. Caching and versioning are the two rows teams regret skipping months later, once traffic and edit history both start to matter. Both are the kind of thing that works fine in a demo and then quietly costs money or trust at scale — extra origin bandwidth on one side, an unexplained image swap on the other.

Common pitfalls in media delivery

The most common mistake is serving the original upload directly instead of a processed variant. A camera photo or export can run several megabytes. Shipping that straight to a browser wastes bandwidth on every single request. It also slows down the exact metric — Largest Contentful Paint — that a CDN and cache headers are supposed to help. Resizing and compressing once at upload time, then serving the smaller result, fixes this permanently instead of per-request. It's a one-time cost at upload instead of a repeated cost on every page view afterward.

The second mistake is skipping cache headers entirely. Every request then re-fetches from origin, even when the underlying file hasn't changed at all. This adds latency for the visitor and load on the origin for no benefit, since a correctly set stale-while-revalidate window would let a CDN serve a slightly stale copy instantly while it revalidates in the background.

The third mistake is treating media as separate from content versioning. A swapped image silently changes what a "published" entry shows, with no audit trail and no way to answer "what did this look like last week." All three pitfalls trace back to the same root cause: media handled as a one-off file operation instead of as content that's processed, cached, and versioned like everything else in the CMS.

None of these three are exotic failures. They're the default outcome of wiring uploads to a bucket without also deciding what happens after the upload — who resizes the file, who sets the headers, and who notices when the file behind an entry changes. A media management pipeline is what makes those three decisions once, up front, instead of leaving them for whoever hits the bug first.