Every web page is really two things mixed together. Some of it is unique to you right now — your shopping cart, your feed, your account balance. The rest is the same for everyone: the logo, the stylesheet, the product photos, the JavaScript bundle. Yet many apps make the same hardworking server compute the personalized part and hand out the identical files, over and over, to every visitor.
Static content hosting separates those two jobs. The unchanging files get served from somewhere cheap, fast, and built for exactly that — leaving your application servers free to do the work only they can do.
The problem
When your application server delivers a 2 MB hero image, it burns CPU, memory, and bandwidth doing something trivial — pushing the same bytes it pushed a thousand times before. That's capacity stolen from the requests that actually need application logic. Worse, every user pulls those bytes all the way from your origin, even if they're on the other side of the planet, so the page feels sluggish far from your data center.
You can throw more servers behind a load balancer, but that's an expensive way to solve what is, at heart, a file-serving problem. Application servers are the wrong tool for handing out files that never change.
Distant userPulls every image and script all the way from your origin, even from the other side of the planet, so pages feel sluggish far from the data center.
Overloaded app serverBurns CPU, memory, and bandwidth pushing the same static bytes over and over — capacity stolen from the dynamic requests that actually need it.
Big static filesImages, CSS, JS, and videos that never change per request, yet are re-served by application code on every single hit.
How it works
You upload static assets to a cloud object store — a service designed to hold and serve files cheaply and reliably. Then you put a CDN (content delivery network) in front of it. The CDN is a global mesh of edge servers that keep cached copies of your files close to where users are, applying caching at the network edge.
Now the split is clean: a request for the page's dynamic shell goes to your application server, while requests for images, scripts, and styles go to the CDN, which serves them from the nearest edge — often without ever touching your origin. Your app servers only do dynamic work; the heavy lifting of file delivery happens elsewhere. The diagram below shows a client pulling static files from the CDN and dynamic responses from the app server.
CDN edge cacheServes images, CSS, and JS from a location near the user — usually without touching the origin at all.- Object storageCheap, durable home for static files; the CDN pulls from it only on a cache miss.
- App serverHandles only the dynamic, per-request work — freed from shipping the same static bytes over and over.
Cache invalidation is the hard part. A CDN's whole value is holding onto copies, which means a changed file can keep serving its old version for as long as its TTL allows. The standard fix is fingerprinting: bake a content hash into the filename (app.9f3c2.js) so a new version gets a brand-new URL. Old URLs can cache forever; new deploys simply reference new ones.
When to use it
This is close to a default for any public web app or single-page application. The moment you're serving images, fonts, stylesheets, client-side bundles, or downloadable files, moving them to storage plus a CDN cuts load on your servers and slashes latency for distant users — usually for less money than running extra app capacity.
Where it fits less neatly is content that's genuinely per-user or needs strict access control on every fetch. You can serve private assets through a CDN with signed URLs, but if nearly everything is dynamic and personalized, the static-hosting win is small. The sweet spot is the large, shared, rarely-changing files that every visitor needs.