Why Static Sites Still Win
Every few years, the web development world rediscovers static sites. We add a new acronym — JAMstack, then “static-first,” now “hybrid rendering” — and the cycle repeats. Under all of it, the idea is the same: pre-render what you can, serve HTML directly, and only reach for a server when you genuinely need one.
I built this blog as a static site. Not because it’s trendy, but because it’s the right tool for the job. Here’s why that reasoning holds up.
The deployment is boring, and that’s good
A static site is a folder of files. When I deploy this blog:
bun run build
# Outputs to ./dist
# Upload dist/ to Cloudflare Pages
# DoneThere’s no database to migrate, no server to patch, no runtime to keep alive. The CDN serves files it already has. If Cloudflare has an incident in one region, users hit another edge node — same files, same response.
Compare this to a server-rendered app where every page load involves:
- Route hit at the edge
- Cold start (or warm, if you’re lucky)
- Database query
- Template render
- Response
That’s four more things that can fail.
Performance isn’t an afterthought
When your “server” is a CDN edge node 50ms away from the user holding a pre-built HTML file, performance is structural — not something you optimize into existence.
A 1-second delay in page load time can result in a 7% reduction in conversions. A static site delivered from a CDN edge removes most of the variables that cause that delay.
For a blog, the math is simple:
| Approach | TTFB (typical) | Complexity |
|---|---|---|
| Static + CDN | 10–50ms | Low |
| SSR + edge | 50–200ms | Medium |
| SSR + origin | 200–800ms | High |
The numbers aren’t surprising. What’s surprising is how often people choose the slower option when they don’t need to.
What static sites can’t do
Let me be direct about the tradeoffs:
- No user authentication (without a third-party service)
- No server-side personalization per request
- No real-time data without client-side fetching
- Build times increase with content volume
For a blog? None of these matter. For a marketing site? Same. For a SaaS app with user accounts and live data? You need a server — but you probably still want static assets for your public-facing pages.
The Astro approach
This site uses Astro, which handles the “when do I need a server?” question elegantly. The default is static. You opt into server rendering per-page when you actually need it:
---
// This page is server-rendered
export const prerender = false;
// Everything else builds to static HTML
---The adapter pattern means you’re not locked in. Static today, add a Cloudflare Worker for a contact form endpoint later, without rewriting anything.
The boring conclusion
Static sites win for content-heavy sites because boring infrastructure is good infrastructure. The best deploy is the one where nothing interesting happens.
Build the HTML ahead of time. Put it on a CDN. Go write more posts.