Static File Hosting

Why It Matters

Speed and predictability come from the same fact: there is no work to do. A page assembled on demand might spend 200 ms building itself before the first byte leaves the server, where a static file can be answered out of an edge cache in under 20 ms. Nothing executing also means very little to attack — no injection into a query that is never made, no runtime to patch on a Tuesday evening, no process to fall over under load. The trade is real: anything genuinely per-visitor, such as a signed-in dashboard, has to happen in the browser or against a separate API, because the server will not do it for you.

How It Works

The host maps a URL path to a stored object and returns it. A request for /docs/guide.pdf finds the object at that key and replies with Content-Type: application/pdf and the file's bytes. A request that ends in a directory, like /docs/, conventionally resolves to the 'index.html' inside it. Headers do the rest of the work: Cache-Control sets how long a copy may be reused, an ETag lets a browser ask whether its copy is still current and be told 304 Not Modified, and Content-Encoding marks a gzip or Brotli transfer. Since none of this varies by visitor, a CDN can hold the finished response at hundreds of locations and answer without ever troubling the origin.

Real-World Example

Common Mistakes

• ✕Expecting a form on the page to do something — with no server-side processing there is nothing to receive the POST unless the form points at an external endpoint
• ✕Using absolute paths like /assets/logo.png in a project served from a subfolder — the request resolves to the wrong place and the asset returns 404
• ✕Setting a long cache lifetime on 'index.html' — visitors keep the old page for hours after you publish, because the file name never changed

Related Terms