Every few years someone declares static site generators dead. And every few years, the sites that load fastest, break least, and survive the longest turn out to be static HTML.
Here's why that keeps being true.
Speed is a feature
A static site is a collection of pre-built HTML files served directly by a web server. There's no database query, no server-side rendering, no cold start. The time between request and first byte is the time it takes to read a file from disk.
This matters more than most developers think. Every 100ms of load time costs engagement. A static site served from a CDN routinely delivers sub-100ms response times worldwide.
Security by absence
The most secure code is no code. A static site has no server-side runtime, no database, no admin panel, no login form. The entire attack surface is a web server serving files.
There are no SQL injection vulnerabilities because there is no SQL. There are no authentication bypasses because there is no authentication. There are no plugin vulnerabilities because there are no plugins running on the server.
Version control is your CMS
Every piece of content is a file in a Git repository. This gives you:
- History: every change is tracked, attributable, and reversible
- Branching: draft posts live on branches, merged when ready
- Collaboration: pull requests for content review
- Backup: the repository is the backup
No database dumps. No export tools. No migration scripts. git clone gives you the entire site.
The build step is a feature, not a tax
Critics call the build step a disadvantage. It's actually where the magic happens:
- Markdown is compiled to semantic HTML
- Templates generate consistent layouts
- Images are optimized and resized
- CSS and JavaScript are minified
- Sitemaps, RSS feeds, and social cards are created automatically
All of this happens once at build time, not on every request. The result is a set of files that can be served by any web server, cached aggressively, and deployed anywhere.
When not to use a static site
Static sites are wrong for:
- Applications that require real-time user interaction (chat, dashboards)
- Content that changes per-user (personalization, authentication)
- Sites where non-technical editors need a visual CMS
For blogs, documentation, portfolios, landing pages, and any content that changes less often than it's read — static is the right default.
The web started static. The best parts of it still are.