Press slash to focus this field, or Escape to return home.
How does this site ship 21KB with no framework?
BuildThis site is built on a React platform. The page you are reading contains no React, loads no framework bundle, and weighs 21KB gzipped. That is not a trick, it is where the request stops.
I wanted to host with a tool I already use, and I wanted a site that renders as plain HTML for the reasons the rest of this site argues. Those two goals look opposed. They are not, because of how the deploy target works.
Where the request actually stops
The platform deploys to Cloudflare Workers with a static assets binding. Cloudflare checks for a matching static asset before it invokes the Worker. If there is a file, it is served and the Worker never runs.
So a complete HTML document at public/about.html is served at /about, by the edge, with no framework involved. The React app is still in the deploy. It just never gets asked.
| Request | What happens |
|---|---|
/ | Static file served. Worker never runs. |
/about | Static file served. Clean extensionless URL. |
/about.html | Redirects to /about. Canonical URLs come free. |
| no matching file | Falls through to the Worker, which serves the 404. |
The numbers
Measured on the built output, 6 August 2026:
- What this page ships: 21,464 bytes gzip. HTML, one stylesheet, one script.
- What the framework route would have shipped: 171,382 bytes gzip, before any of my own content.
- Difference: eight times smaller, 146KB saved on every first visit.
The homepage references the framework bundle exactly zero times. I check that on every build, because the failure mode here is silent: everything keeps working while quietly loading 160KB you thought you had removed.
The part that will catch you out
The preview environment has no asset layer. It is a dev server, so it never sees the static files and every page except the root 404s, while production is perfectly fine.
I lost an afternoon to that. The fix is a server route that reads the same HTML file and returns it verbatim, so the preview serves byte-identical output to production without holding a second copy of the page. If you ever find yourself editing that route to change the page, you are editing the wrong file.
What it costs
Honesty about the trade, because this is not free.
No components. The navigation is duplicated in every file. When I add a page I add a link seventeen times, or I write a script to do it. For a site this size that is cheaper than a build step. At a hundred pages it would not be.
No framework conveniences. Routing, state, and data fetching are mine to write. The whole client is one script with no dependencies, which I consider a feature, but it is a real constraint.
You have to actually verify it. Everything above is checkable in one command, and I run it because a claim about page weight that nobody measures is just a claim.
cat index.html site/styles.css site/app.js | gzip -c | wc -cWhy bother
Because this site's argument is that a page a machine can read is a page a person can find, and a site making that argument on top of 167KB of framework would be arguing against itself.
The design has to be the proof. So does the build.