What is Static Content?

Static content is served from a stored representation that ordinarily remains identical across requests. It changes only when the underlying resource is updated, rather than through per-request generation.

How Static Content works

Static content is a delivery property: the server can return bytes that already exist, such as a file on disk or an object in a bucket, without running application logic for the request. The file may have been written by hand, emitted by a build, or exported by a media pipeline, so “static” does not mean it never changes. It means the content changes when the stored file is replaced, not when a request arrives. Two HTTP mechanisms therefore do most of the work. Freshness, set with Cache-Control, tells browsers and CDNs how long they may reuse a copy without asking. Validators, an ETag or a Last-Modified date, let a cache ask whether its copy is still current and receive a 304 response without a body when it is. Images, video segments, fonts, style sheets, scripts, and prebuilt HTML pages are typical static content; a response assembled per request from application state is dynamic content.

Key facts

Is a static file cached automatically? Not reliably, and not for a predictable time. Without explicit freshness from Cache-Control or Expires, HTTP lets a cache apply heuristic freshness: RFC 9111 allows it to estimate a lifetime from Last-Modified and gives 10% of the time since the last modification as a typical setting. MDN recommends an explicit Cache-Control header on every response for that reason. CDNs add defaults of their own. Cloudflare, for example, caches by file extension and not by MIME type, does not cache HTML or JSON by default, and does not cache a response that carries Set-Cookie.
Should a static file keep its URL when its content changes? Decide per file. A file whose URL changes with its content, such as a bundle with a hash in its name, can be served with a long max-age (MDN’s example uses one year) plus immutable, because a new version arrives under a new URL. A file that must keep its URL, such as an HTML page, should not get a long lifetime: updating the file on the server does not replace a fresh copy that a browser has already stored, because, as MDN notes, requests for it no longer reach the server, so the browser can keep using that copy until its lifetime expires. A CDN that offers purging can drop its own copy, but a purge does not reach copies already stored in browsers. Serve those files with no-cache and validators, so that every reuse is checked and an unchanged file costs only a 304.
Does serving from a file make a response safe for a shared cache? No. Cacheability follows the request and the response headers, not how the body was produced. RFC 9111 forbids a shared cache from reusing a response to a request that carried Authorization unless the response allows it with public, s-maxage, or must-revalidate. It has no such rule for a request that carried a Cookie header, and MDN notes that a cookie alone does not make a response private. The RFC also notes that Set-Cookie does not inhibit caching, so a static file sent with a cookie can be stored and reused for later requests by a cache that follows the standard. A CDN may apply a rule of its own instead: Cloudflare, as noted above, does not cache such a response by default. Prefer not to set cookies on static paths. Where a response must carry one, or is personalized by a cookie, mark it private: a shared cache such as a CDN must then not store it, so that file is cached only in browsers.
What changes when files are precompressed? The compressed and uncompressed files are two representations behind one URL, so responses need Vary: Accept-Encoding, and RFC 9110 states that a strong ETag for a content-encoded representation has to be distinct from that of the unencoded one, to prevent conflicts during cache updates and range requests. Servers differ in how much of this they do for you. nginx’s gzip_static sends an existing .gz file in place of the regular file, but it adds Vary: Accept-Encoding only when gzip_vary is on, which is not the default. Neither of the two nginx module pages says how the ETag of a .gz response is formed, so request a file with and without Accept-Encoding: gzip, confirm from Content-Encoding that only the first response is compressed, and compare the Vary and ETag headers of the two responses. Repeat the check through the CDN: gzip_static also takes gzip_proxied into account, and its default, off, disables compression for requests that carry a Via header, so a request forwarded by a CDN may receive the uncompressed file. Apache’s mod_deflate, which compresses on the fly, appends the compression method to the ETag by default, and its documentation says this prevents 304 responses to conditional requests for compressed content.

How Transloadit helps with Static Content

Files that an Assembly exports with a storage Robot are static content from then on: they sit in your bucket under the path you chose, and your storage or CDN serves them. The /s3/store Robot takes a headers object that is set on the stored file, and /video/adaptive gives each segment and playlist a relative_path so that the stored layout matches what the playlists reference. Smart CDN is the on-demand counterpart: a result is generated when it is first requested and then cached, and the /file/serve Robot sets the Cache-Control header that browsers and the CDN receive, with cache_duration to change it.

A browser player that loads HLS or MPEG-DASH files from a different origin than the page, such as a bucket or CDN hostname, needs CORS headers on the server that serves the files; the /video/adaptive page lists them. Cache headers for exported files are your storage’s or CDN’s responsibility once the files are stored.

Explore Transloadit’s delivery capabilities

What is Static Content?

How Static Content works

Key facts

When Static Content matters

How Transloadit helps with Static Content

Sources

Turn media knowledge into a working pipeline