Most people still think “WordPress for everything” is a sane default. I learned the hard way that for many sites, that is like installing a full database cluster to serve a 3‑page business card.
If you want the short answer: static site generators are better when your content changes rarely, your traffic can spike hard, and you care about security, speed, and low hosting cost. A dynamic CMS is better when you need frequent content edits from non‑technical users, complex editorial workflows, user logins, and real‑time features. The real tradeoff is between where the complexity lives: at build time and in Git (SSG) or at request time in a database‑driven app (dynamic CMS).
If you can describe your site as “mostly read‑only” and you are comfortable with Git, a static site generator is probably the right default. If your site is a “living application” with user accounts or constant edits from non‑technical staff, a dynamic CMS is still the safer bet.
What “Static” and “Dynamic” Actually Mean
Everyone throws these terms around, but they map to very different deployment models.
Static Site Generators (SSG)
An SSG takes source files (Markdown, templates, config) and builds plain HTML, CSS, and JS. That build runs on your machine or in CI. The output is a folder of files that you put on a web server or object storage.
Key examples: Hugo, Jekyll, Eleventy, Astro, Next.js SSG mode, Gatsby.
At request time:
– The server just serves prebuilt files.
– There is no database query for each page view.
– Any “dynamic” behavior usually runs in the browser (JS) or as separate APIs (serverless functions, external services).
Dynamic CMS
A dynamic CMS builds each page (or retrieves it from a cache) when the request arrives. Content is stored in a database and rendered, often with plugins, themes, and custom code.
Key examples: WordPress, Drupal, Joomla, Laravel‑based CMSs, custom Node/Python/Ruby apps with admin panels.
At request time:
– The server runs application code.
– It reads from a database.
– It composes the response based on the current state: content, user session, permissions, etc.
Static puts almost all work at build time. Dynamic spreads work across every request.
Core Tradeoffs: Performance, Security, Control, and Workflow
At this point it helps to stop thinking “technology stack war” and instead look at the practical dimensions that actually hurt or help you.
- Performance and caching behavior
- Security surface
- Content workflow and editorial UX
- Hosting and cost model
- Extensibility and integrations
- Developer experience and maintenance
Performance: Static Is Fast by Default, Dynamic Needs Help
Static files served via a CDN have trivial response paths. No PHP interpreter, no framework bootstrap, no SQL. Latency comes down to:
– Network distance to the nearest CDN POP
– File size
– TLS handshake overhead
Dynamic CMS setups must fight for similar numbers. They rely on:
– Page caches (reverse proxies, plugin caches)
– Object caches (Redis, Memcached)
– Query tuning
– Application optimizations
Here is a rough comparison for a basic article page under load, assuming a sane config in both cases:
| Aspect | Static Site (CDN) | Dynamic CMS (no page cache) | Dynamic CMS (with full-page cache) |
|---|---|---|---|
| Time to first byte | ~20-70 ms | ~200-800 ms | ~40-120 ms |
| Requests per second on mid‑range VPS | Mostly limited by network | Few hundred | Thousands |
| Failure mode on traffic spike | Usually fine, CDN absorbs it | Likely 5xx / timeouts | Better, but origin can still choke on cache misses |
| Performance tuning work | Minimal | Ongoing | Initial setup, then monitoring |
Dynamic can match static performance, but only if you treat caching as a first‑class feature. Most teams do not. They just install “yet another cache plugin” and hope it works.
Static wins here by virtue of being boring.
Security: Fewer Moving Parts vs Constant Patch Cycle
Static sites have no runtime that an attacker can reach on your origin for normal page views. There is nothing to “log in” to on the public side.
Threat model comparison:
| Vector | Static Site | Dynamic CMS |
|---|---|---|
| SQL injection | Not applicable | Common problem class |
| RCE via plugins | Possible in your build stack, not exposed to visitors | Frequent incident type |
| Brute force login attempts | Only on separate services (e.g., headless CMS) | Constant background noise on wp-login.php and friends |
| Supply chain risk | Build dependencies (Node, Go, etc.) | Plugins, themes, core, server packages |
Static does not remove security work; it changes where you worry: CI/CD, build dependencies, and developer machines instead of public PHP endpoints and live admin panels.
Dynamic CMS installations require:
– Core updates
– Theme and plugin updates
– PHP and database patches
– Access hardening (WAF, login protection, 2FA)
Teams that ignore this patch treadmill end up hosting malware or spam pages inside their own sites.
Content Workflow: Who Edits, How Often, and With What Skills
This is where many static setups fall apart. A Git‑based content flow is natural for developers and miserable for non‑technical editors.
Static content flow (typical):
1. Editor writes Markdown in Git.
2. Commit, push, CI runs build.
3. Site deploys.
If your team is comfortable with branches, pull requests, and basic Markdown syntax, this is clean and auditable. If you have content people who live in browsers and WYSIWYG editors, it feels like a regression to the 1990s.
Dynamic CMS content flow:
1. Editor logs into admin.
2. Edits content, clicks save/publish.
3. Site reflects changes immediately or after cache purge.
The UX is familiar. Revisions, drafts, comments, user permissions, scheduling, and media handling are already there. For content‑heavy teams, that matters more than a few hundred milliseconds of latency.
There are hybrid options:
– Static frontend with headless CMS (e.g., Contentful, Sanity, Strapi).
– Editors use a web UI; site still builds statically.
That gets close to the best of both worlds, but you have now added separate hosting for the CMS, plus token management, plus build hooks. Simpler than a full monolith for some teams, overkill for others.
Hosting and Cost Model
Static hosting is cheap because static files are what CDNs and object stores were built for.
Typical static deployment:
– S3 or similar + CloudFront (or any CDN), or
– Netlify / Vercel / Cloudflare Pages type service
You pay for:
– Storage (tiny for most sites)
– Bandwidth
– Maybe build minutes
No data stores to tune, no PHP pool, no scaling logic. Very few things to misconfigure in a way that takes the site down.
Dynamic CMS hosting:
– Web application server (PHP/Node/Ruby/…) + database
– Optional cache servers
– Often, some managed platform like managed WordPress or PaaS
You pay for:
– Persistent CPU and RAM
– Storage for code + uploads + database
– Possibly scaling tiers for traffic spikes
If your site is heavily visited, static can handle 10x or 100x traffic at almost no extra complexity. Dynamic stacks can handle it too, but you will talk to support, read tuning guides, and pay more.
If your monthly hosting bill for a static marketing site crosses into serious money, something is very wrong with the architecture or the pricing model you picked.
Extensibility and Integrations
Dynamic CMS platforms earned popularity because adding features is “install plugin, click activate.” Forms, SEO helpers, galleries, e‑commerce, membership, almost everything has prebuilt plugins.
Static generators instead lean on:
– Client‑side JS that talks to SaaS APIs.
– Serverless functions for backend logic.
– Custom build hooks.
Basic things like contact forms now involve third‑party services (Formspree, Netlify Forms, self‑hosted functions, etc.). That is not inherently bad, but it moves complexity into separate systems.
Static works well for:
– Read‑only content (blogs, docs, marketing pages)
– Light dynamic features (search, forms, comments) offloaded to services
– Sites where “features” are mostly UI, not deep business logic
Dynamic CMS is still the sensible choice when:
– You need heavy admin features (complex taxonomies, user roles, workflows).
– You need many integrations with internal systems.
– You expect lots of custom behavior tied to user sessions.
Developer Experience and Maintenance
With a static generator, your “CMS” is your Git repository.
Benefits:
– Full history, diffs, blame.
– Content and code move together.
– Same deployment pipeline as the rest of your stack.
Costs:
– Editors must learn basic Git and Markdown, or
– You must bolt on a Git‑based editor (Netlify CMS, TinaCMS, etc.), or
– You must use a headless CMS and treat SSG as frontend only.
Dynamic CMS developer experience varies. WordPress feels simple at first, then plugin conflicts and theme inheritance start wasting your time. Drupal is powerful, but configuration and module complexity can be relentless.
For many tasks, though, spinning up a plugin in a dynamic CMS is still faster than writing a custom integration for an SSG, wiring up serverless auth, and debugging CORS.
Where Static Site Generators Win Clearly
At this point, we can map some concrete scenarios.
Use Static When the Site Is Mostly Read‑Only
Examples:
- Blog or personal site
- Documentation site or knowledge base
- Marketing site with a handful of forms
- Portfolio, event landing pages, micro‑sites
Why static fits:
– Content change frequency is low to moderate.
– Few people edit the content.
– Interactive parts are simple.
Technical upsides:
– Every page is cache friendly by default.
– Build failures happen before deploy, not in production.
– Incident response usually involves rolling back a deploy, not recovering a database.
Security‑Sensitive Contexts With Simple Content
If you handle anything that regulators care about, you do not want your main public site to be a PHP playground full of plugins from random developers.
Static helps when:
– You need to limit exposed services on public IPs.
– You want to keep sensitive apps on separate domains and stacks.
– You know your content can be prebuilt.
You can still run real apps, but you do it on separate domains or subdomains with tighter control.
Extreme Traffic or Spiky Load
Product launches, viral posts, big announcements. Static shines when you need your site to survive being posted on a massive subreddit or front page.
Static with CDN:
– CDN bears almost all of the traffic.
– Origin gets hit for cache misses only.
– Scaling is mostly a bill, not an outage.
Dynamic CMS without bulletproof caching tends to fall over in these conditions.
Engineering‑Driven Teams That Live in Git
If your team is mostly developers, you are already using pull requests, code review, and CI. For these people, having content in the same repo is natural.
Benefits:
– PRs for content changes.
– Automated linting for content as well as code.
– Easy environment parity between staging and production.
For developer‑heavy teams, storing content as files is closer to reality than pretending you “need” a web UI for every text change.
Where Dynamic CMS Still Makes More Sense
Static is not magic. For a large class of sites, sticking with a seasoned CMS is both less risky and more efficient.
Frequent Content Edits by Non‑Technical Staff
If you have:
- Editors who do not write Markdown
- Marketing teams that live in web UIs
- Complex publishing workflows (draft, review, approval, schedule)
then forcing them into Git is asking for friction and errors. A WYSIWYG admin panel with roles, revision history, previews, and media libraries saves time every single day.
In theory, headless CMS + SSG gives you this with a static frontend. In practice, you now pay for:
– CMS hosting.
– Build pipelines.
– Warming of caches at the edge.
For many organizations, a well‑maintained WordPress or Drupal install on a managed platform is enough and simpler.
Rich User Interaction and Auth‑Heavy Apps
If your site is really an application:
- User registration, profiles, dashboards
- Custom workflows based on user roles
- Per‑user content, notifications, messaging
then fully static becomes awkward. You either:
– Push more logic into the browser (SPA with API backend), or
– Fall back to traditional dynamic behavior.
At that point, calling it a “static site” is a mislabel. You have an application with an API backend. That is fine, but you are no longer in the same simplicity class.
Dynamic CMS platforms at least have:
– Session management built in.
– Permission models.
– Libraries and patterns for these flows.
Heavy Use of Existing Plugins and Modules
If you rely on:
– WooCommerce or similar for e‑commerce.
– Complex membership or LMS plugins.
– Advanced taxonomy and search plugins.
then ripping all of that out for an SSG rebuild is often a waste of time and budget. You gain some speed and security, but you throw away years of plugin ecosystem work.
In many of these cases, it is more sane to:
– Harden and modernize your existing dynamic stack.
– Introduce aggressive caching and CDN.
– Use static exports or edge caching for a subset of pages.
Large, Non‑Technical Organization With Many Editors
Static plus Git scales badly across dozens or hundreds of editors who are not developers. Even if you layer a Git‑based CMS on top, you add:
– Training overhead.
– More moving parts in CI and build triggers.
– New classes of failures when CMS and build pipeline drift out of sync.
For these organizations, a mature dynamic CMS with sane governance, backups, and security policies is dull, but it works.
Hybrid Approaches: Trying to Get the Best of Both
Not everything must be either fully static or fully dynamic. There are several practical mixes that work well when done intentionally.
Static Frontend With Headless CMS
Pattern:
– Use a headless CMS (Contentful, Sanity, Strapi, Ghost headless mode, etc.).
– Build a static frontend (Next.js, Gatsby, Astro, Hugo).
– Trigger builds when content changes via webhooks.
Benefits:
– Editors get a modern web UI.
– Frontend remains static, cacheable, and CDN friendly.
– Tighter control over public endpoints.
Costs:
– Two systems to host and monitor (CMS + build/deploy).
– Build times for large content sets can grow.
– Preview workflows require more plumbing.
You need to care about:
– Incremental builds.
– Content modeling discipline (no more “just install a plugin” mindset).
– Observability for build failures that block updates.
Dynamic CMS With Static Exports for Parts of the Site
Some platforms let you:
– Export static versions of certain routes.
– Cache them aggressively at the edge.
Typical pattern:
– Blog or marketing pages are rendered once and cached as static.
– Authenticated or admin areas stay dynamic.
This can be done with:
– Plugins that pre‑render popular pages.
– Reverse proxy configurations.
– Edge workers that cache at the CDN layer.
You keep your dynamic tooling, but shift high‑traffic, low‑change segments closer to static performance.
SSR and ISR in Modern JavaScript Frameworks
Modern frameworks blur the line:
– Static Site Generation (SSG): Build HTML at deploy time.
– Server Side Rendering (SSR): Build HTML at request time.
– Incremental Static Regeneration (ISR): Rebuild pages in the background on a schedule or trigger.
This gives you a gradient:
– Pages that rarely change get pure SSG.
– Pages that need “fresh but not real‑time” data use ISR.
– Highly dynamic parts use SSR or client‑side rendering.
From an architecture view, these are all just tradeoffs about where and when you render. The core distinction is still:
– Precompute as much as possible.
– Only compute at request time for things that truly require it.
Questions That Actually Help You Decide
If you are stuck between static and dynamic, stop debating stack names and answer specific questions.
1. Who edits content, and how comfortable are they with Git?
– Mostly developers: Static with Git is fine, sometimes ideal.
– Mixed team: Consider headless CMS + SSG.
– Mostly non‑technical: Default to dynamic CMS or a very good headless CMS with static frontend.
2. How often does content change, and how urgent are edits?
– Weekly or monthly changes: Static builds are trivial overhead.
– Daily changes with no urgency: Static can still work, but build times and editor patience matter.
– Constant edits, time‑sensitive publishing: Lean to dynamic or a fast incremental SSG setup tied to a CMS.
3. How much user interaction does the site require?
Purely read‑only or near‑read‑only:
– Static is ideal.
– Forms, comments, basic search are easy to bolt on.
Heavy interactivity:
– Auth, complex personalization, internal tools: conventional application stack or headless architecture is more honest.
4. What are your security and compliance obligations?
– If audits and security reviews are common, reducing public attack surface with static where possible helps.
– If you must run multiple complex apps anyway, an extra dynamic CMS might not be the main risk.
5. What is your tolerance for operational complexity?
Static:
– Simple runtime, but more CI/CD thinking.
– Harder for non‑technical staff without extra tools.
Dynamic:
– Rich features, but patching and hardening never stop.
– Debugging performance and plugin conflicts is routine.
If your team is small and already buried under support tickets, picking the architecture with fewer moving parts is rarely a bad call.
Practical Recommendations by Use Case
To avoid vague advice, here are concrete pairings that tend to work well.
Blogs and Personal Sites
Preferred:
– Static site generator (Hugo, Jekyll, Eleventy, Astro).
– Hosted on Netlify, Vercel, or S3 + CDN.
When to pick dynamic instead:
– You want to hand publishing to someone who will never touch Git.
– You want quick plugin‑based features (visual builders, comment plugins, etc.).
Company Marketing / Brochure Sites
If the site is:
– Mostly “About”, “Services”, “Contact”, “Blog” pages,
– Managed by a small team that can adapt tooling,
then static or headless CMS + SSG is a good long‑term move.
Dynamic CMS is still reasonable when:
– Marketing insists on page builders and live previews.
– You expect non‑technical teams to build landing pages on their own.
Documentation and Developer Portals
Static wins almost by default:
- Versioned content maps cleanly to Git branches/tags.
- Developers are comfortable with Markdown and PRs.
- Search can be offloaded to Algolia or similar.
Dynamic docs platforms exist, but they rarely offer enough to justify the extra runtime overhead unless your docs are deeply tied to user accounts and internal tools.
Newsrooms, Magazines, and High‑Velocity Content
Dynamic CMS is still the pragmatic choice for:
– Heavy editorial workflows.
– Many contributors and editors.
– Frequent updates and corrections.
Static can play a role for archives, special reports, or high‑traffic landing pages, but rebuilding the entire site for every edit can become painful without careful design.
E‑commerce and Membership Sites
Static is best used carefully:
– Static for product marketing pages and content.
– Dynamic for cart, checkout, account, dashboards.
You can:
– Use a headless commerce API with static product pages and dynamic checkout.
– Or stick with a mature e‑commerce CMS and focus on caching.
Trying to turn a full e‑commerce flow into a pure static experience usually ends up recreating a dynamic app anyway.
When You Should Not Force Static
There is a pattern where teams get excited about static generators, rebuild everything, and then quietly add more JS, more APIs, and more complexity until they effectively have a brittle SPA with a fragile build system.
Warning signs:
- Editors frequently complain about publishing friction.
- Builds take many minutes for small content edits.
- You are bolting on more and more external services for simple tasks.
- Incidents now involve broken CI pipelines instead of simple admin fixes.
At that point, a well‑managed dynamic CMS might actually be simpler.
Do not pick static just because dynamic had problems. Those problems may come from how it was run, not the model itself.
Summary: Static vs Dynamic in One View
| Criterion | Static Site Generator | Dynamic CMS |
|---|---|---|
| Performance | Fast by default, trivial CDN caching | Fast if caching is done correctly, slower otherwise |
| Security surface | Small public surface, more focus on build chain | Larger public surface, constant patch cycle |
| Content editing UX | Great for technical users, awkward for others unless headless CMS is added | Friendly for editors, mature tooling for workflows |
| Hosting and cost | Cheap and simple; scales well with traffic | More expensive at scale; requires tuning |
| Interactivity | Good for mostly read‑only; powered via JS and APIs for extras | Good for apps, auth, per‑user features |
| Team fit | Engineering‑centric teams, simple content orgs | Large content teams, mixed skills, complex organizations |
If you want a blunt heuristic:
If your site is 80 percent content and 20 percent application, start from static or headless CMS + SSG. If it is 20 percent content and 80 percent application, start from a dynamic stack and accept that you are running an app, not just a site.
