Static Sites Are Back (Actually, They Never Left)

There's a pattern on the web that I find quietly hilarious. Every few years, we invent a new, more complex way to serve pages. Then, a few years later, someone writes a blog post called "Maybe We Should Just Ship HTML" and everyone nods like it's a revelation.

I'm writing that post now. Sorry. But hear me out.

What "static" actually means

A static site is one where the pages are built ahead of time. When someone visits, the server doesn't run any code or query any database — it just hands over a file that already exists. Usually that file lives on a CDN, physically close to the visitor.

That doesn't mean static sites can't be interactive. Modern frameworks blur the line beautifully: you pre-render everything you can at build time and sprinkle in dynamic bits only where you need them. This blog is built that way. Every post is plain HTML by the time it reaches you.

Why I keep coming back

It's fast without trying. There's no server warming up, no database round trip. The page is just there. On a patchy connection in a mountain town, that difference is enormous.

It's cheap — often free. Most hosting platforms will serve a personal static site for nothing. I've paid more for coffee this week than I've paid to host every website I own combined.

It's hard to break. No server to patch, no database to back up, no plugin with a security hole waiting to be found. My old WordPress blog got compromised twice. My static sites never have.

It ages well. A folder of HTML files from 2010 still opens in a browser today. Try saying that about a decade-old app that depends on a specific runtime, an abandoned framework, and a database schema nobody documented.

The honest trade-offs

Static isn't magic. It's a bad fit when:

• Content changes constantly — think live scores or stock prices. Rebuilding on every change gets silly fast.
• Every page is personalized. A dashboard showing your data can't be pre-built for everyone.
• You have a huge number of pages. Building a million product pages on every deploy takes real time, though incremental builds help a lot.

Most of these have hybrid solutions now. You can pre-render the shell and fetch the dynamic parts, or rebuild individual pages on demand. But it's worth being honest: there's a point where a traditional server is simply the right tool.

My rule of thumb

Start static. Add a server when a real requirement forces you to, not when a tutorial suggests it.

For blogs, portfolios, documentation, landing pages, and most small business sites, that requirement never comes. You get a site that's faster, cheaper, and more resilient than the alternative, and you get your weekends back.

The web didn't forget about static sites. We just keep getting distracted by shinier things. And then, inevitably, we come home.