Static vs. Dynamic Sites: When to Choose Each (And Why It Matters)

The line between “static” and “dynamic” websites has blurred enough that the terms confuse more than they clarify. But the underlying architectural choice - when is the HTML generated? - still shapes performance, security and cost for years.

Here’s how we actually decide, in plain language.

What each one actually means

A static site generates all its HTML at build time. When you push a change, a build process runs, produces a folder full of HTML files, and uploads them to a CDN. Every visitor gets the same pre-rendered page. Examples: Hugo, Astro, Eleventy, Next.js in static export mode.

A dynamic site generates HTML on the fly, per request. The server runs code (PHP, Node, Python) that looks at the URL, queries a database, assembles the HTML, and sends it back. Examples: WordPress, Laravel apps, traditional Rails apps, Next.js in SSR mode.

Modern frameworks blur this line:

SSR (Server-Side Rendering) - dynamic, per-request HTML.
SSG (Static Site Generation) - static, build-time HTML.
ISR (Incremental Static Regeneration) - static by default, regenerates pages on a schedule or webhook.
CSR (Client-Side Rendering) - minimal HTML; JavaScript builds the page in the browser.
Hybrid - some pages static, some dynamic, on the same site.

The choice isn’t binary anymore. But the broad static-vs-dynamic distinction still has real consequences.

Where static wins

Performance

A static page hits the visitor as pre-compiled HTML from the nearest CDN edge - usually 50–150ms anywhere in the world. There’s no database, no server-side code, no rendering. Just bytes.

For a marketing site, this routinely means LCP under 1 second, and Lighthouse scores in the high 90s without any optimisation effort.

Security

A static site has no attack surface. There’s no admin panel to brute-force, no SQL database to inject, no PHP versions to keep patched. The “attack” is “the file already exists or it doesn’t.” This is why static sites are the standard recommendation for journalism in hostile environments - there’s nothing to hack.

Cost

Static sites can run for free on Vercel, Netlify, Cloudflare Pages, GitHub Pages. A site with 100,000 monthly visitors typically costs $0–10/month at this scale.

By contrast, a WordPress site at the same traffic usually needs $30–80/month of managed hosting (smaller and it’ll fall over under traffic spikes).

Reliability

Static sites don’t go down. A CDN serving HTML files has essentially perfect uptime. There’s no database to fail, no server process to crash. Deploys are atomic: either the new version is live, or the old one still is.

We’ve had WordPress clients get a single Hacker News mention and have their site collapse under traffic. A static site barely notices.

Where dynamic wins

Real-time data

If your homepage shows live inventory, current pricing, user-specific content, or anything that changes per visitor - static doesn’t work cleanly. You either rebuild constantly (impractical for high-frequency changes) or you fall back to client-side rendering.

Authentication and personalisation

A logged-in dashboard, a member portal, account settings - these need to know who the visitor is at render time. Static can’t handle this cleanly, though hybrid approaches (static shell + dynamic islands) work for many cases.

Frequent editor publishing

Editors who publish multiple times a day, with the expectation that changes go live in seconds, struggle with build-and-deploy cycles. A 60-second Astro build feels slow when you’re trying to fix a typo three times in 10 minutes.

(Mitigations exist - Vercel and Netlify both offer near-instant draft previews - but the friction is real.)

Complex back-end logic

If your site does anything substantial server-side - processing payments, running scheduled jobs, handling complex form submissions, integrating with multiple APIs - you need server code. Static can complement this (the marketing pages can be static, the app dynamic) but it can’t replace it.

Hybrid: what most modern sites actually are

In practice, most real Sydney business sites we build are hybrid:

The marketing pages (homepage, about, services, blog) are static.
The interactive parts (contact form, search, member login, application processes) are dynamic - either serverless functions or a small back-end.
The two coexist on the same domain, often deployed together.

Astro and Next.js both make this trivial. You don’t have to pick one architecture for the whole site.

A decision flow

For a new build, here’s our internal heuristic:

Is the site primarily marketing/content with infrequent updates? → Static. Default to Astro.
Does the site have a logged-in area? → Hybrid. Static marketing pages + dynamic app area.
Are editors publishing 5+ times a day with real-time deadlines? → Dynamic, or static with near-instant draft previews and webhooks. WordPress, Sanity, or Strapi.
Does the site involve significant business logic (payments, integrations, real-time data)? → Dynamic. The marketing layer can still be static.
Is performance the headline business goal? → Static where possible.
Will the site need to scale to viral traffic? → Static. Dynamic sites can scale but you’ll pay for it.

Common confusion: “We need SEO so it has to be dynamic”

This was true around 2017. It’s not anymore.

Static sites are better for SEO than dynamic SPAs, because the HTML is fully present in the initial response. Google can read it immediately, with no JavaScript execution required. This is exactly why most modern SEO advice recommends static or server-rendered output.

The thing you don’t want for SEO is client-side rendered SPAs - React apps that ship an empty HTML shell and build the page in the browser. Google does render JavaScript now, but it’s slower, less reliable, and treats those pages with lower confidence.

Static-first frameworks like Astro, Next.js (SSG), and Nuxt 3 (SSG/SSR) are the modern SEO-optimal choice.

Common confusion: “We’re going static so we can’t have a CMS”

Also false. Static sites work beautifully with CMSes:

Headless WordPress - editors use WordPress, the static site rebuilds when content changes.
Sanity / Contentful / Hygraph - purpose-built headless CMSes with friendly editor experiences.
Decap CMS (formerly Netlify CMS) - open-source, runs in your repo, edits commit to Git.
Tina - Git-backed visual editor.
Markdown in Git - perfect for developer-edited docs, blog posts, or small teams.

A static site with a connected CMS feels identical to editors as a dynamic site, with build times in the 30–90 second range.

A real-world example

A recent project: a Sydney accountancy firm with 15 pages of marketing content, a careers section, an insights blog, and a portal where existing clients submit documents.

Marketing pages, careers, blog: static. Edited via Sanity. Rebuilds on content change. Loads in under a second globally.
Client document portal: dynamic (Remix on the same domain, behind auth). Handles uploads, status, communication.

Total monthly hosting cost: $48 (Vercel Pro + Sanity team plan). Lighthouse mobile score: 99/100. Editors are happy. Clients have a fast, modern site. The portal scales independently.

This pattern - static marketing front, dynamic interactive back - is the right answer for most modern business sites.

What the move costs

If you’re moving from a WordPress site to a hybrid static stack:

Up front: typically $15,000–$30,000 for a 10–20 page site with a basic CMS.
Monthly hosting: drops from $30–80/month to $0–50/month.
Editor experience: comparable if you use a headless CMS. Better, in many cases.
Maintenance burden: much lower. No plugins to update, no security patches, no PHP versions.
Performance: generally 3–5× faster.

Over a 4-year asset life, you usually save the up-front cost in hosting and maintenance alone, before counting conversion lift.

Considering a static or hybrid rebuild? Get in touch for a 30-minute conversation about what would actually fit your team.