Static Sites Still Win

This site you're reading is static HTML. No React. No Next.js. No server-side rendering. Just files served from a CDN. And it loads faster, costs less, and breaks less than almost any dynamic site you've ever built.

The industry spent two decades adding complexity to web development. Databases. Application servers. Caching layers. Build pipelines that take longer than the original PHP script they replaced. Meanwhile, the simplest possible architecture (HTML files served from a CDN) keeps outperforming everything else.

This isn't nostalgia. It's engineering. Having built content management systems since MSNBC in the 90s, I've watched architecture choices come and go. The pattern is clear: the projects that lasted were the ones that stayed simple.

Updated February 2026: This site now has 145+ articles, interactive scorecards, 16 widget types, client-side search, and math rendering, all while maintaining 100% Lighthouse scores across Performance, Accessibility, Best Practices, and SEO. Static sites don't mean static features.

The Unhackable Server

How do you hack a WordPress site? You exploit a PHP vulnerability or a SQL injection. How do you hack a Static Site? You cannot.

• The Physics: There is no database to inject. There is no server-side code to exploit. There is just a read-only HTML file on a CDN.
• The Reality: The most secure server is the one that is not there. If you are running a CMS for a marketing site, you are paying a "Security Tax" for a "Dynamic Feature" you do not even use.

Every WordPress plugin is an attack surface. Every database connection is a potential breach. Every line of server-side code is a vulnerability waiting to be discovered. Static sites have none of this. The attack surface is: "Can you hack an HTML file?" The answer is no. You cannot execute code on something that does not execute code.

The Performance That Can't Be Beat

Static sites are fast in a way dynamic sites can't match. According to industry benchmarks, static sites consistently load in under 100ms from CDN edge locations. No database query. No application server. No runtime processing. The browser asks for a file; the CDN hands it over.

The math is simple:

• Dynamic request: DNS → CDN → Origin server → Application code → Database query → Template rendering → Response
• Static request: DNS → CDN → Response

Don't believe me? View Source. Right-click this page and inspect it. Look at the Network tab. Check the payload size. This page (with interactive calculators, syntax highlighting, and full styling) transfers under 50KB compressed. No framework bundle. No hydration payload. Just HTML, CSS, and minimal JavaScript that loads only when needed. The browser does less work, which means faster rendering and less battery drain on mobile.

You can optimize a dynamic site. You can add caching layers, edge functions, and smart invalidation. But you're optimizing toward something static sites already have by default. The layer tax is real: every abstraction you add is latency you pay.

The Security That Comes Free

Static sites have almost no attack surface. As Contentstack's security analysis notes: with no database, there's no SQL injection. With no server-side code, there's no code injection. With no CMS admin panel, there's no credential stuffing.

The vulnerabilities that plague dynamic sites simply don't exist:

• No database. Can't inject into what doesn't exist.
• No server-side execution. Malicious input has nowhere to run.
• No admin interface. Nothing to brute-force.
• No plugins. No supply chain to compromise.

WordPress sites get hacked because WordPress is complex software running PHP that connects to MySQL with a plugin ecosystem that nobody fully audits. Static sites get hacked... almost never. The attack surface is a web server returning files. That's it.

The Cost That Approaches Zero

According to SysPree's 2025 analysis, static sites can run on platforms like Netlify, Vercel, or Cloudflare Pages for $0-50/month, compared to $100-500/month for comparable WordPress hosting with equivalent traffic.

This site runs on Cloudflare Pages. The hosting cost is zero. Not "basically zero." Actually zero. Cloudflare makes money on enterprise features I don't need. My 145+ articles, with interactive widgets, charts, and search, serve unlimited traffic at no marginal cost.

Compare that to what "modern" architectures cost:

• Managed WordPress: $30-300/month depending on traffic
• Serverless with database: $50-500/month at scale
• Kubernetes deployment: Don't ask

Static hosting on a CDN is essentially the serverless promise actually delivered. You deploy files. They serve globally. You don't manage anything.

The Tooling That Finally Matured

Static sites used to mean writing raw HTML. Now we have mature tooling that gives you modern development workflows without runtime complexity:

Hugo builds thousands of pages in milliseconds. It's a single Go binary with no dependencies. For content sites, it's the obvious choice.

Eleventy (11ty) offers flexibility without opinions. Bring your own templating language, your own folder structure. It stays out of your way while reliably growing in usage as the choice for purely static sites.

Astro bridges static and dynamic. It ships zero JavaScript by default, hydrating only the components that need interactivity. For sites that need some dynamic behavior without becoming SPAs, it's clever engineering.

All of these deploy to free-tier hosting with global CDN distribution. The tooling barrier that used to exist is gone.

The best part: these tools have been around long enough to prove they're stable. Hugo has been reliable since 2013. Eleventy since 2018. They're not trendy anymore. They're boring. And boring technology is usually the right choice.

The Migration Path Nobody Talks About

What if you have an existing dynamic site? The migration doesn't have to be all-or-nothing. I've seen teams successfully move to static incrementally:

Start with the pages that change least. Marketing pages, documentation, blog content: these are often rendered from databases but rarely change. Pre-render them first. You reduce server load immediately without touching the core product.

Keep dynamic where it earns its complexity. Your checkout flow probably needs server-side processing. Your user dashboard probably needs real-time data. Don't pretend otherwise. The goal isn't religious purity; it's matching architecture to requirements.

Use edge functions for the gray areas. Contact forms, newsletter signups, light personalization: these don't need full application servers. A single Cloudflare Function or Vercel Edge Function handles the dynamic bits without the dynamic infrastructure.

The hybrid approach works because it's honest about what each page actually needs. Marketing site? Static. User authentication? Dynamic. Blog with comments? Static pages, dynamic comment widget. You don't have to choose one architecture for everything.

When Dynamic Actually Makes Sense

I'm not saying static is always right. Some things genuinely need servers:

• User-generated content at scale. A site where users create content needs a database. Comments, profiles, uploads: these need persistence.
• Real-time features. Chat, live dashboards, collaborative editing require WebSockets and state.
• Personalization. If every user sees different content, you need server-side rendering or client-side hydration.
• Transactional operations. E-commerce checkout, banking, anything with ACID requirements.

But here's what I've observed: most sites that claim to need dynamic don't. A marketing site doesn't need server-side rendering. A blog doesn't need a database. A documentation site doesn't need React. They use these tools because that's what the team knows, not because the requirements demand it.

The honest question is: does your content change per-request, or just per-publish? If it's per-publish, you can pre-render. And pre-rendering wins.

I've done technical due diligence on dozens of startups. A surprising number of them run complex infrastructure for what amounts to a brochure site with a contact form. The architecture choices were driven by resume building, not requirements. That's expensive in ways that compound: hosting costs, maintenance burden, security exposure, and engineering time that could go to actual product work.

Static vs Dynamic Decision Matrix

The Test: Does your content change per-request, or per-publish? If per-publish, go static. The security, performance, and cost savings are free.

What This Site Proves

This blog is my proof of concept, and it's grown far beyond a simple static site. 145+ articles. Interactive scorecards. Client-side search. Math equations. Code syntax highlighting. Dark mode. RSS feeds. And 100% scores on all four Lighthouse metrics: Performance, Accessibility, Best Practices, and SEO. The site also scores A+ on Website Carbon Calculator, cleaner than 99% of pages tested. No framework, no CMS, just static HTML. See our stats for the full breakdown.

Here's what's running on this "simple" static site:

• 16 widget types: interactive scorecards, decision matrices, risk audits, diagnostic checklists, calculators. All rendered at build time with optional JavaScript hydration.
• Pagefind for full-text search across 145 articles, running entirely in the browser.
• KaTeX for mathematical notation (when articles need it).
• Prism.js for syntax-highlighted code blocks in 15+ languages.
• Chart.js for data visualizations.
• Mermaid/PlantUML diagrams rendered to SVG at build time via Kroki.
• Conditional loading: libraries only load on pages that use them. No 300KB JavaScript bundle on every page.
• SQLite database for content management: sources, tags, article metadata, widget configurations. The database powers the build; it never runs in production.

And because it's semantic HTML, it degrades gracefully everywhere:

• No JavaScript? All content remains readable. Try it: disable JS and refresh.
• Console browsers? Works in lynx, w3m, and text-mode browsers. Proper heading hierarchy, semantic landmarks, alt text on images.
• Screen readers? 100% Lighthouse Accessibility score. ARIA labels, skip links, logical tab order.

React apps fall apart without JavaScript. This site just shows you the content. That's progressive enhancement done right: the core experience works on any client that can parse HTML.

The workflow is still simple:

1. Write content in HTML
2. Run a Python script that templates it with data from SQLite
3. Deploy to Cloudflare Pages

No build server. No CI/CD pipeline (though you could add one). No runtime database. No dependency updates that break things. The site will work identically in ten years if I never touch it again, because the output is just HTML, CSS, and vanilla JavaScript.

The key insight: build-time complexity, runtime simplicity. The Python scripts, the SQLite database, the diagram generators: all that complexity lives on my laptop. What gets deployed is the simplest possible output: files on a CDN.

That durability matters. I've watched framework churn kill projects. React apps from 2018 are legacy code. Angular 1 sites are archaeology. But HTML from 1995 still renders in every browser. Static sites inherit that permanence.

The lesson from three decades of web development: the technologies that age well are the ones that don't require constant maintenance. Static HTML is the ultimate in low-maintenance architecture. There's nothing to update, nothing to patch, nothing to migrate. The files just work.

"Static sites aren't a step backward. They're a step sideways, out of the complexity trap that modern web development fell into."