Single-file websites

01The definition

A single-file website is one HTML document that carries everything it needs inside itself: markup, styles, scripts, geometry, textures and fonts, with no <script src>, no <link rel=stylesheet>, no CDN and no font host. Open it and the browser has already received the entire site. Nothing is fetched afterwards, so there is no waterfall, no second round trip, and no request that can fail or be blocked.

The word that matters is self-contained, not small. Both objects sold here are larger than a typical HTML file and make exactly zero requests after the document arrives — which is the trade a single-file page makes: one bigger response instead of many small ones.

02How to verify it yourself

Do not take a seller's word for it, including ours. Two checks settle it in under a minute, and they work on any file from anyone.

First, grep the document for outbound references. A truly self-contained file returns zero:

grep -oE '(src|href)="https?:[^"]*"' page.html | wc -l
# 0

Second, open the file from disk with devtools' network panel recording and reload. Count the requests. One document request, nothing else. If the page renders identically with the network disabled, it is self-contained — and if it does not, something in it was never really inside it.

Specimen 01 does both checks for you in the browser, on any file you drop on it, without uploading anything anywhere. It is free.

03What it buys you

• No dependency surface. Nothing to install, pin, audit, or update — and no package that can be unpublished, compromised, or abandoned under you.
• No third-party requests at runtime, so the page does not hand a visitor's IP address to a CDN, a font host or an analytics vendor unless you add one yourself.
• No build to keep working. The file that renders correctly today renders correctly in five years, because nothing about it is resolved at build or run time.
• It runs anywhere a file can sit: file:// from a USB stick, an S3 bucket, nginx, Netlify, Vercel, GitHub Pages, or one route inside a site you already have.
• It is archivable in the literal sense — one file is the whole artifact, so a copy is a backup and a copy is a deployment.

04What it costs you — honestly

• The bytes arrive up front. There is no lazy loading and no code splitting; the visitor pays for the whole page in the first response.
• No cross-page caching. If you ship five single-file pages, each carries its own copy of whatever they share.
• Cache-busting is by filename. Update the file and you either accept a must-revalidate header or publish a new name.
• There is no CMS behind it. Changing the words means editing the document — which is fine for a page, and wrong for a blog.
• Diffs are large and version control sees one enormous file, so it suits finished artifacts far better than code under active team development.

The honest boundary: a single file is the right shape for a finished page — a launch, a portfolio, a campaign centrepiece, a signature page. It is the wrong shape for an application with accounts, data, or an editorial calendar.

05Measured, from the files we actually deliver

These are the two objects on sale. The figures are taken from the delivered documents with stat and gzip -9, not estimated, and re-measured whenever an object is re-cut.

Object 01 · The Agent Chronometer — on disk

704,811 bytes

Object 01 — over the wire

187,269 bytes gzipped

Object 01 — runtime requests

0

Object 01 — renderer

Three.js r185, inlined into the document

Object 02 · Visage — on disk

548,530 bytes

Object 02 — over the wire

403,717 bytes gzipped

Object 02 — runtime requests

0

For scale: 187,269 gzipped bytes is the weight of a fairly ordinary JavaScript bundle on a modern marketing site — except that here it is the entire site, arriving in one request, with nothing following it.

06How you publish one

• As the site: upload the file as index.html. That is the whole deployment.
• As one route inside an existing site: drop it in your public directory and link to it. No framework integration, because there is nothing to integrate.
• Embedded: put it in an <iframe>, give the frame an accessible title, and size its container deliberately — an interactive page in an unsized frame is the one way to make it look broken.
• Test the fallback path on a device without WebGL, and with reduced motion enabled, before you call it shipped. Both objects carry those paths; your host cannot add them for you.

The workflow side of this — editing one, and why there is no build step to run — is its own page.

FAQQuestions

Is a 700 KB HTML file slow?

It arrives as 187,269 bytes gzipped in a single request, and then nothing else is requested at all. A conventional page of comparable ambition typically ships a similar amount of JavaScript plus a request waterfall of fonts, textures and third-party scripts on top of it.

Does it work offline?

Yes. Because there are zero runtime requests, the document renders identically opened straight from disk over file:// with no network at all.

Can I put it inside a site I already have?

Yes — either as a standalone route served from your public directory, or inside an iframe with an accessible title and a deliberately sized container. Nothing about it needs to know what framework the rest of the site uses.

How do I know a file is really self-contained?

Grep it for src= and href= references beginning with http, which should return zero, then reload it with the network panel recording and confirm the document is the only request. Specimen 01 on this site performs both checks in the browser on any file you give it.