Static Content Hosting
Static Content Hosting serves assets from storage or a CDN instead of app servers, cutting latency, cost, and load while scaling globally. It needs good cache and versioning strategy and handles only static, cacheable content.
The Static Content Hosting pattern serves static resources, such as HTML, CSS, JavaScript, images, fonts, and downloads, directly from a storage service or content delivery network (CDN) rather than from application compute. The application servers handle only dynamic requests.
The problem is that using application servers to deliver static files wastes compute, adds latency, and scales poorly. Static files never change per request, so there is no reason for them to pass through application logic.
How It Works
Static assets are uploaded to a storage service such as Amazon S3 or Azure Blob Storage that can serve files over HTTP. A CDN (Amazon CloudFront, Azure Front Door, Cloudflare) sits in front, caching copies at edge locations near users. Requests for static content are routed to the storage or CDN endpoint; requests for dynamic content go to the application.
The CDN serves cached assets from the nearest edge, dramatically reducing latency and origin load. Cache-control headers and content versioning (fingerprinted filenames) manage freshness so updated assets are picked up promptly while unchanged ones stay cached.
When to Use It
Use it for any application serving a meaningful volume of static assets: single-page applications, media-heavy sites, documentation, and download portals. Use it to offload app servers, deliver content with low latency worldwide, and reduce bandwidth cost.
Avoid it only for truly dynamic, per-user content that cannot be cached; even then, hybrid setups serve the static shell statically and fetch dynamic data via APIs.
Trade-offs
Cache invalidation is the classic challenge: updated content may be stale at edges until caches expire or are purged, so versioned filenames are preferred over manual purges. Static hosting alone cannot run server-side logic, so dynamic needs a separate path. Access control for private static content requires extra mechanisms such as signed URLs.
The benefits, lower cost, lower latency, and near-infinite scale for assets, make it a default for modern web delivery.
Related Patterns
It is foundational for global delivery alongside the Geode pattern and edge caching. Valet Key (signed URLs) secures private downloads. Cache-Aside caches dynamic API responses that complement static assets.
Example
A single-page React app builds to fingerprinted files (app.8a2f.js) uploaded to S3. CloudFront fronts the bucket and caches assets at edges with long max-age headers. The HTML and bundles load from the nearest edge for every user, while the app calls a separate API gateway for dynamic data. A new release uploads new fingerprinted files and updates the HTML reference, so clients fetch the new version without manual cache purges.