Why Is This Site So Fast?

Because there's nothing here.

← All posts

The confession

The person who built this site has never built a website. No training in HTML (the language web pages are written in). No training in CSS (the language that controls how web pages look). No web development experience of any kind. He's a data engineering manager who spends his days writing database queries. He once described his front-end skills as "I know what a browser is."

This site loads faster than almost anything you've visited today.

Those two facts are related.

What happens when you visit a typical website

When you click a link to most websites, your browser and the website's server play a long game of catch before you see anything:

Steps 2 through 4 are the server doing work. Steps 6 through 10 are your browser doing work. All of that work exists to turn stored data into the page you see. But what if the page already exists? What if there's no assembly required?

That's this site. The page you're reading was built before you got here. It's a file sitting on a shelf. Amazon's storage service just hands it to your browser. Done.

What is here

That's the entire system. Files in a bucket. One stylesheet. One script that wakes up when we publish something new, rebuilds the table of contents, and goes back to sleep. Your browser never talks to a server, never waits for code to run, never downloads a software library. It just reads a file.

Why does every other website do it the hard way?

Most websites use a system called a CMS — a content management system. The most popular one is called WordPress. It powers about 40% of all websites on the internet. Here's what WordPress does every time someone visits a page:

1. A programming language called PHP wakes up on the server
2. PHP asks a database called MySQL for the page content
3. PHP applies a visual template (called a "theme") to the content
4. PHP runs any plugins the site owner has installed
5. PHP assembles the final page and sends it to your browser
6. Your browser downloads and runs additional code files the theme requires

All of that happens on every single visit. The same page, assembled from scratch, every time someone asks for it. It's like a restaurant that builds a new kitchen for every order.

This site pre-builds the meal and puts it in the window. You just take it.

The content management system that isn't one

The hardest part of running a website with multiple authors is this: two people might try to edit the same file at the same time. One person's changes overwrite the other's. This is why CMS platforms have databases, login systems, and version tracking — to manage that conflict.

We solved it differently. We separated what humans write from what humans read:

Humans write individual content files. Each file is standalone — one person, one file, no overlap. A short script (150 lines of Python) watches for new uploads, reads all the content files, sorts them, and rebuilds the shared table of contents automatically. No human ever edits the index page. The machine owns it.

Two people can upload posts at the same time. The script rebuilds the index after each upload. No collision. No merge conflict. No "someone overwrote my changes." The problem that CMS platforms exist to solve simply doesn't exist here, because the architecture made it impossible.

The cost

The scale

Here's a question nobody asks about a small website until it matters: what happens if a million people show up tomorrow?

For a WordPress site, the answer is: it falls over. The server can only handle so many people building pages at once. When traffic spikes — say, a post goes viral, or a news site links to you — the server runs out of capacity. Pages load slowly, then not at all. The site goes down. To prevent this, you need an entire infrastructure layer:

S3 is the same storage service that powers Amazon.com — the site that handles Black Friday, Prime Day, and the entire AWS cloud. It is engineered to serve trillions of objects to billions of requests. This site is a rounding error on Amazon's daily traffic. A million visitors wouldn't register as a blip.

The math at scale: each page on this site is about 10–15 kilobytes. Amazon charges $0.0004 per thousand page requests. One million pageviews costs forty cents. Not forty dollars. Forty cents. And the first hundred gigabytes of data transfer each month are free.

A WordPress site handling a million visits needs load balancers (traffic directors), CDNs (worldwide file caches), database replicas (backup copies of the database for overflow), caching layers (systems that remember recently built pages to avoid rebuilding them), auto-scaling (automatically spinning up new servers), and a monitoring system to page someone at 3 AM when it breaks. Total cost: $200–$850 per month, minimum. And even with all of that infrastructure, a sudden traffic spike — the front page of Reddit, a viral tweet, a major news link — can still bring it down. It happens all the time. There's even a name for it: the "hug of death."

This site can't experience the hug of death. There's no server to overload. Amazon's infrastructure absorbs the traffic the way the ocean absorbs a raindrop. You'd need to generate more traffic than Amazon.com on Prime Day to make S3 sweat, and even then, Amazon would just add capacity automatically. No configuration. No phone calls. No 3 AM pages.

It's like parking a gondola in Venice. You didn't build the canals. You didn't engineer the tides. You just put your boat in the water and the entire city's infrastructure carries you. The canals were built for container ships. Your gondola rides for free.

The attack surface

Every feature on a website is a door. Every door can be picked. Security professionals call the total number of doors the "attack surface." Here's the comparison:

This site doesn't need a cookie consent banner because it doesn't set cookies. It doesn't need security patches because there's no software to patch. It doesn't need a firewall because there's no server to protect. It doesn't need password rules because there are no passwords.

You cannot hack what isn't there.

This site uses HTTPS — the padlock icon your browser shows when a connection is encrypted. HTTPS protects data flowing between your browser and the server so nobody in between can read or tamper with it. Banks need it. Shopping carts need it. Login pages need it. And even though this site accepts no input from you — no forms, no login, no passwords, no personal data in either direction — we added it anyway, because browsers have started treating HTTP sites as suspicious, and there's no reason to make readers wonder.

The encryption comes from Amazon CloudFront, a worldwide network that sits in front of our files and handles the secure connection. It added zero complexity to the site itself. The HTML files didn't change. The publishing workflow didn't change. CloudFront just wraps the delivery in a padlock. Cost: $0/month.

The irony

The person who built this doesn't know web development. That's not a limitation. It's the reason the site is fast.

A professional web developer would have started with a framework — a pre-built software library that provides structure and features. That framework would need a build process. The build process would need a toolchain (a set of programs that prepare the code for the browser). The toolchain would need hundreds of software packages as dependencies (other people's code that your code relies on). Those dependencies would need security audits. The build output would need optimization. The optimization would need configuration. And three weeks in, you still haven't written a single word of content.

Bill said: "I want to put some HTML files on the internet." Claude said: "OK." They put some HTML files on the internet. The site loaded instantly because there was nothing in the way.

Every layer you add between the writer and the reader is delay. Not just technical delay — creative delay. The distance between having an idea and publishing it should be one conversation and one file upload. On this site, it is.

What you can steal from this

1. If your content is mostly text, you don't need a framework. HTML is a perfectly good publishing format. It was literally invented for this.
2. If your site changes weekly, you don't need a database. Files are a database. A folder full of HTML files is a database. You just don't need a special language to query it.
3. If two people might edit the same file, separate the content from the index. Let humans write content files. Let a machine build the table of contents. Conflicts become impossible.
4. If you don't know how to build a website, that might be an advantage. You'll build what you need instead of what the industry tells you to need. The result will be simpler, faster, and cheaper. Every time.

← Back to posts · How this site was built