Image delivery is a CDN problem, and storage buckets don't solve it

Why media delivery is a performance problem before it is a storage one

"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 pipelines fall down. Images account for roughly 60-70% of the average webpage's total weight. (Source) That makes images the biggest single lever on page performance.

Largest Contentful Paint is usually an image. So how that image gets processed and cached moves the metric directly. Sites that treat media delivery seriously see it in their Core Web Vitals.

A CMS that only stores the original pushes the rest onto your app. You build the resize pipeline. You set the cache headers by hand. You hope nothing regresses when traffic spikes. A CMS that treats media as delivery does that work once, for every asset.

Storage and delivery are not the same job. Storage keeps the bytes safe. Delivery needs the right format, the right size, and a cache policy. Conflating the two is why image-heavy pages stay slow on fast hosting.

This is why "just put it in a bucket" is an incomplete answer. Raw object storage has no image variants, no processing step, and no default cache policy. It will serve a 6MB original to a phone on a slow connection, exactly as it serves everyone else. Nothing in that setup tells a media asset apart from any other blob.

A CDN in front of the bucket helps with geography. But it can only cache what the origin tells it to cache. With no Cache-Control header, a CDN has no signal for how long an image is safe to keep at the edge. The header and the CDN are two halves of one mechanism.

How Draftbase handles media management and CDN delivery

Media management in Draftbase is a pipeline, not a single upload endpoint. Four steps, in order: upload, store, transform, serve. Each one exists to remove a specific failure mode teams hit when they build this themselves, and entry-level versioning runs across all four.

This mirrors the write/read split Draftbase already uses for content. Writes go through an authenticated management surface. Reads go through a delivery path built for speed. Upload and confirm are management operations. The CDN-fronted URL is delivery: cached and public.

Need to draft alt text for an asset before it's uploaded? Try the free alt text generator.

Together these cover the four places a homegrown pipeline usually breaks. A blocked API request during upload. An unprocessed original served at full size. A missing cache header that forces a re-fetch every load. A swapped image with no record of when it changed. Media is referenced from entries as a field type, so that last one is covered by the same revision history every other field uses — swapping an image shows up in the entry's history and rolls back the same way.

What a delivery URL actually looks like

An asset's url is the CDN host joined to its storage key. Nothing else. Both the original and the processed variant follow the same shape:

# what the browser uploaded, before the worker runs
https://cdn.example.com/<orgId>/production/originals/1754870400000-hero.jpg

# what the asset points at once processing finishes
https://cdn.example.com/<orgId>/production/processed/1754870400000-hero.webp

No query parameters. No ?w=800&format=webp to append, because there is nothing to ask for at request time — the transform already happened, once, at upload. That is a real architectural difference from an imgix-style CDN, and worth being plain about: you cannot generate an arbitrary crop from the delivery URL, and you do not pay a transform per unique variant either. One canonical file per asset, cached immutably at the edge, with a URL safe to hardcode in an <img> tag.

None of it needs configuration before an upload works. The presigned URL flow, the processing trigger, and the cache headers are wired up by default in every environment. The knobs that are yours are the org's resize settings — on/off, max width, max height — and its upload size limit, which defaults to 25MB.

How much does WebP conversion save on storage and load time?

WebP files are typically 25-34% smaller than a comparable JPEG, and 26% smaller than a comparable PNG, per Google's own published figures. (Source) Draftbase re-encodes every processed upload to WebP at quality 82. The saving lands on the stored asset itself, so it applies before any delivery variant exists.

All three figures are Google's own published measurements for the format. (Source) They describe the encode, not our pipeline — what Draftbase adds is that the encode happens on every upload with nothing to configure.

That one conversion pays twice. Storage is smaller, so a plan quota stretches further and the media library costs less to keep. Transfer is smaller too, so every visitor downloads fewer bytes for the same image on the same page.

The resize step compounds it. Uploads are fitted inside 1920x1920 before encoding, and a smaller original is never enlarged to match. A 6MB camera photo becomes a web-sized WebP once, at upload, instead of being shipped at full resolution to every mobile visitor forever.

Fewer bytes on the wire is the most direct lever on Largest Contentful Paint. The LCP element on a content page is usually an image. Every current major browser supports WebP, so the smaller format costs you no reach.

Can you turn image resizing off?

Yes. Resizing is an org-level setting with three knobs: on/off, max width, and max height. Raise the max dimensions and larger images survive at full resolution. Turn resizing off and the worker stores your original untouched. Everything else still runs. The asset becomes ready, gets CDN cache headers, and versions with its entry.

WebP is the standard, not the optional part. Resizing to fit 1920x1920 and encoding at quality 82 is what every org gets from the first upload, with no setup step. The knobs exist for the images that don't fit that default, not because the default is a guess.

The reasons to turn resizing off are narrow and worth naming. Large artwork or photography that has to keep its full pixel dimensions. Assets that must stay bit-identical to what was uploaded, for legal or archival reasons. Source files handed to a downstream tool that needs the original format. For most of those, raise the max width and height instead. You keep the WebP saving and give up only the downscale.

How a CMS and a CDN divide the work

The split is cleaner than most integrations make it look. The CMS owns the asset record: which file exists, its dimensions and size, its alt text and tags, which entries reference it, and which processed variant is canonical. The CDN owns the bytes in flight: the edge cache, the geographic distribution, and the TLS termination near the visitor. Neither half is useful alone. A CDN with no record of what an asset is cannot tell a canonical variant from an abandoned original, and a headless CMS with no edge serves every visitor from one region.

URL rewriting is where the seam usually shows. In an integrated setup there is nothing to rewrite: the asset record stores a storage key, and the API returns the CDN host joined to that key, so the URL a frontend renders is already the edge URL. In a bolted-on setup — the WordPress CDN plugin pattern — the CMS emits its own origin URLs and something has to find and rewrite them afterwards, in a filter, a template, or worse, a regex over rendered HTML. That plugin is not a feature. It is a symptom of the CMS never having owned delivery.

Three failures follow from that seam, and all three are common. A stale cache after a replace, because the CDN keys on a URL that did not change when the file did. Broken invalidation, because the CMS has no way to tell the CDN which paths to purge, so someone purges everything and absorbs the origin traffic. And orphaned originals, because deleting an entry deletes a record while an unreferenced file sits in storage forever, paid for monthly.

Draftbase closes the first by never reusing a key: a replace repoints the asset at a new one, so the URL changes and the CDN fetches fresh with no purge involved. That is also why the cache header can be immutable. The third is handled at delete time — an asset still referenced by an entry returns a conflict listing the entries that reference it, rather than leaving a broken image behind.

Media management and CDN delivery approaches compared

Three common setups: your own upload path against a plain bucket, a generic headless CMS media field, and Draftbase's pipeline. The differences concentrate in processing and caching. Those are the two steps teams skip first under deadline pressure. None of the three is wrong on day one. The gap widens with asset count and traffic, which is when a manual pipeline is hardest to retrofit.

Upload path and processing get the attention, because they're visible during development. Caching and versioning are the rows teams regret skipping months later. Both work fine in a demo. At scale one costs money in origin bandwidth, the other costs trust in an unexplained image swap.

Media management pitfalls

The most common mistake is serving the original upload instead of a processed variant. A camera photo can run several megabytes. Shipping that to a browser wastes bandwidth on every request. It also slows Largest Contentful Paint, the exact metric a CDN is meant to help. Resize and compress once at upload, then serve the smaller result. One cost at upload beats a repeated cost on every page view.

The second mistake is skipping cache headers. Every request re-fetches from origin, even when the file hasn't changed. That adds visitor latency and origin load for no benefit. An object whose URL is unique to its contents can carry a long max-age with immutable, which stops browsers and edges revalidating something that will never differ.

The third mistake is treating media as separate from content versioning. A swapped image silently changes what a published entry shows. No audit trail, no way to answer what it looked like last week. All three trace to one root cause. Media gets handled as a file operation instead of as content that's processed, cached, and versioned.

The fourth is caching a URL that can change underneath you. A long max-age on a key that gets overwritten on replace means an updated image never reaches anyone until the cache expires, and cache-busting query strings only shift the problem to whoever forgets to append one. Give every file its own key and the problem disappears: a new file is a new URL, and the old one can be cached forever without lying.

The fifth is uploading through the app server rather than presigning direct-to-storage. A 20MB file on a slow connection holds a request thread open for the whole transfer, and enough concurrent uploads starve the API for everyone else in the org. The bytes have no business touching your application at all.

The sixth is having no maximum-dimension policy, and it is the one we learned the hard way. Image libraries have their own limits that do not match what a product accepts: sharp refuses to decode past roughly 0.27 gigapixels by default, which a stitched panorama trips, and a processing job with a fixed memory and time budget can run out of both on a large enough original before it ever reaches the encode step. Decide the ceiling deliberately — in Draftbase that is the org's resize setting — rather than discovering it as a failed asset. Client-side re-encoding deserves the same suspicion: a picker that decodes to a canvas and re-encodes before upload can hand the server a file several times larger than the one the user chose.

None of these 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, what the size ceiling is, and who notices when the file behind an entry changes. A pipeline makes those decisions once, up front, instead of leaving them to whoever hits the bug first. If what you actually need is per-request transforms from an existing origin, that is a different tool — our image CDN guide covers when one is worth adding.