Static vs Dynamic Websites: The Definitive Guide

A static website is built into files before anyone requests it, and the server just hands those files over. A dynamic website holds code that assembles each page at the moment it’s requested. Static is faster, cheaper to run, harder to break into, and readable by every crawler on the web including the AI ones. Dynamic is the right call when every visitor needs to see something different. Most marketing sites, blogs, docs, and portfolios don’t.

Want to see the difference? Open a terminal and run curl <https://yoursite.com>. Whatever comes back is roughly what ChatGPT, Claude, and Perplexity see when they visit. If your content only shows up after JavaScript runs in a browser, they see an empty div and move on.

That test didn’t matter much when I first wrote this guide in 2022. It matters a lot now.

What is a static website? # Direct link to this section

A static website is one where every page exists as a file on a server before a visitor asks for it. Someone requests /about/, the server checks whether it has that file, and sends it. That’s the whole transaction.

’Static’ has nothing to do with how the page looks. You can have video, animation, interactive components, a live search index, all of it. The word refers to delivery, not design. Think of it as a printed magazine already sitting on the shelf: the pages were laid out, printed, and bound before you walked into the shop, and every copy is identical.

Static sites are built by static site generators like Astro, Hugo, Eleventy, Jekyll, and the static output modes of Next.js, Nuxt, and SvelteKit. You write templates and content, the generator runs, and you get a folder of HTML.

What is a dynamic website? # Direct link to this section

A dynamic website assembles each page when the request arrives. This is how WordPress, Drupal, and most traditional platforms work. A visitor asks for /about/, and the server runs code that loads a theme, queries a database, initializes whatever plugins are installed, renders a template, and returns the result.

If the static site is a printed magazine, a dynamic site is print-on-demand. Nothing exists until you ask, and it gets re-assembled every time you turn the page.

To a visitor, the two can look identical. The difference is what happens in the gap between the click and the pixels.

What actually happens on a request? # Direct link to this section

A static request is short:

Browser: Can I have the homepage?
Server: Here it is.

A dynamic request has more steps:

Browser: Can I have the homepage?
Server: Sure, give me a moment.
Browser: …
Server: Talking to the application server.
Browser: …
Server: Loading plugins.
Browser: …
Server: Querying the database.
Browser: …
Server: Building the page.
Browser: …
Server: Here it is.

Every step in that second conversation is a place where things go slowly, or go wrong. A slow database query, a plugin that hangs, a server under load. None of those failure modes exist when the answer is already sitting on disk.

Why does this matter more now than it did in 2022? # Direct link to this section

Because a large share of your audience now arrives through systems that don’t run JavaScript.

Vercel and MERJ analyzed more than 500 million GPTBot fetches and found zero evidence of JavaScript execution. Not delayed execution, not partial. None. GPTBot downloads JavaScript files in about 11.5% of its requests and ClaudeBot in about 23.8%, but neither runs them. The same holds for PerplexityBot, Meta-ExternalAgent, CCBot, and Bytespider.

There are two exceptions worth knowing. Google’s AI Overviews inherit Googlebot’s rendering, and Microsoft Copilot inherits Bing’s. So a client-rendered page can show up in AI Overviews and be completely invisible in ChatGPT, Claude, and Perplexity at the same time. If someone tells you ’an AI read my SPA fine’, ask which one.

For answer engine optimization, this reorders the priority list. Schema markup, clear headings, and question-shaped content all matter, and none of them matter at all if the crawler receives an empty shell. Server-rendered or pre-built HTML is the floor, not a nice-to-have. A static site clears that floor by definition.

How fast does a page actually need to be? # Direct link to this section

Google’s Core Web Vitals thresholds have been stable since Interaction to Next Paint replaced First Input Delay in March 2024:

Each is measured at the 75th percentile of real Chrome users, not in a lab. According to the 2025 Web Almanac, only 48% of mobile origins and 56% of desktop origins pass all three.

Time to first byte sets a hard floor under your LCP. If your server spends 800ms assembling a page before it sends the first byte, you have 1.7 seconds left for everything else: DNS, TLS, the render, the hero image. On a static site served from a CDN, TTFB is usually double-digit milliseconds, because the server isn’t doing any thinking.

Static also helps INP indirectly. Sites that ship less JavaScript to do their rendering have less JavaScript blocking the main thread when someone taps a button. Astro’s zero-JS-by-default position exists for exactly this reason.

Are static sites more secure? # Direct link to this section

Yes, and the reason is pretty straightforward: there’s less running.

Most breaches aren’t personal. They target a known weak point in a widely deployed stack, at scale, indiscriminately. A static site removes three of the most common ones:

1. No application code executing per request. The server hands over a file. There’s no PHP process to exploit, no injection point in a request handler, no template engine to trick into evaluating something it shouldn’t.
2. No database in the request path. Static sites can pull from databases at build time, but the live site doesn’t depend on one. An unpatched or misconfigured database is not a way into your website, because your website never talks to it.
3. A CDN in front of everything. Files distributed across dozens of edge locations are hard to take down and easy to serve under load.

Then there’s the plugin question. Every plugin you install on a traditional CMS puts part of your site’s integrity in the hands of a developer you’ve never met, and re-does that every time it auto-updates. I’ve never met an agency that audits plugin code on every release. I’ve met plenty that got burned by one.

Static isn’t a magic shield. Your forms, your auth, your third-party scripts, and your build pipeline all still need attention. But the attack surface is a fraction of the size.

What about scale and cost? # Direct link to this section

Static sites scale by doing nothing differently. A traffic spike means the CDN serves more copies of files it already has cached. No connection pool to exhaust, no autoscaling group to provision, no database replica to fall over.

Dynamic stacks scale piece by piece. The web server, the application server, the database, the cache layer, and the object store all have their own limits and their own monitoring. When one of them gives out under load, the page doesn’t render slowly. It just doesn’t render.

Cost follows the same shape. Serving files is close to free. Running infrastructure isn’t, and neither is the engineering time to keep it upright.

Isn’t static just what we did in the ’90s? # Direct link to this section

It is, and I don’t think that’s the criticism people mean it as.

We hand-coded pages in the ’90s because we had to, and it was miserable to maintain. Dynamic CMSs solved the maintenance problem by generating pages on the fly. What’s changed is that build tooling got good enough to solve the same problem at build time instead of request time. You get the maintainability of templates and shared layouts, and you still ship plain files.

The tooling in 2026 is genuinely mature. Astro shipped 7.0 in June 2026, and Cloudflare acquired the Astro team that January with a commitment to keep it MIT-licensed. Hugo still builds ten-thousand-page sites in seconds. Eleventy 3.x remains the least opinionated option on the list. Search on static sites is a solved problem thanks to Pagefind, which indexes at build time and runs entirely in the browser.

Meanwhile, W3Techs data shows WordPress declined from a peak of 43.6% of all sites in mid-2025 to 40.3% by mid September 2026, its first sustained decline since tracking began. The category that gained most wasn’t a competing CMS. It was ’None’, the label for sites where W3Techs detects no CMS at all, up from 28.6% in December 2025 to 30.4% in July 2026. Some of that is parked domains and noise. A good chunk of it is generated HTML.

What’s the difference between static, SSR, and ISR? # Direct link to this section

This is the biggest thing that’s changed since 2022: there’s often no clear binary between static and dynamic.

Modern frameworks let you choose a rendering strategy per route, or even per component:

• Static generation (SSG). Build everything ahead of time. Fastest, cheapest, most durable.
• Server-side rendering (SSR). Render on the server per request. Slower than static, but the crawler still gets real HTML.
• Incremental static regeneration (ISR). Serve a cached static page and rebuild it in the background on a schedule or on demand. Next.js popularized this one.
• Server islands and partial prerendering. Serve a static, edge-cached page with holes in it that render per request. Astro’s Server Islands and Next.js’s Partial Prerendering both do a version of this. A pricing page can be static for everyone while a ’welcome back, Sam’ fragment renders per visitor.
• Client-side rendering (CSR). The browser does the work. Fine for an app behind a login. A poor choice for anything you want cited or indexed.

The useful question right now isn’t just ’Static or dynamic?’. It’s ’How much of this page can be decided before the request, and what can’t be?’. For most marketing sites the answer is: nearly all of it, and almost nothing.

When should you use a static site? # Direct link to this section

Static is the right default if:

• Most visitors see the same content. Marketing sites, blogs, documentation, portfolios, campaign microsites, brochure sites.
• Search and AI visibility matter to how you get found.
• You want predictable hosting costs and no ongoing server maintenance.
• You want to be able to move hosts without a migration project.
• Your content team needs to publish without waiting on a developer.

That last point used to be the catch, and it’s why a lot of teams stayed on WordPress long after the rest of the argument stopped working. It isn’t a catch anymore.

Which CMS should you use with a static site? # Direct link to this section

CloudCannon is a Git-based CMS built for static sites that non-technical people need to edit. It works with Astro, Hugo, Eleventy, Jekyll, SvelteKit, Next.js, and Nuxt. Content stays in your own Git repository as Markdown and YAML. Editors open the Visual Editor, click directly on the rendered page, and change what's there, with no Markdown, no templates, and no terminal. Edits commit back to Git, the site rebuilds, and developers keep working in the repo throughout. CloudCannon builds and hosts the site as well, so there's no separate deployment pipeline to wire up.

It’s our product, so weigh that accordingly. There are alternatives in the category: Decap CMS and Sveltia CMS are free and open source if you'd rather self-host, and TinaCMS and Keystatic work with React-based projects.

When should you use a dynamic site? # Direct link to this section

Dynamic delivery is the right call when the page genuinely differs per visitor and can’t be decided in advance:

• Applications behind a login where the content is the user’s own data. Dashboards, analytics, banking, SaaS product UIs.
• Real-time data that changes faster than you can rebuild. Live scores, stock prices, seat availability, inventory that moves by the second.
• Personalization deep enough that pre-building the variants isn’t practical.
• Large multi-tenant platforms where each customer gets a different application.

Netflix or Amazon are easy examples. Every user’s home screen is assembled from their own viewing history or purchasing habits, and there’s no version of that you can build ahead of time.

Just be honest about which bucket you’re in. A lot of sites run on dynamic infrastructure because a decision was made in 2014, not because anything on the page varies per visitor. Marketing pages on a dynamic stack usually get the costs of dynamic delivery and none of the benefits.

Static vs dynamic at a glance # Direct link to this section

Who’s using static sites? # Direct link to this section

Plenty of organizations that could afford to run anything they like. Cloudflare’s own developer docs, website, and blog run on Astro. IKEA, Porsche, Unilever, Visa, NBC News, and OpenAI all use it for content-driven sites. Kubernetes and Kubeflow publish their documentation as static sites. Large parts of the US government’s web presence are static.

The pattern is consistent. When speed, uptime, and the ability to hand a site to someone else later are the priorities, teams pick prebuilt files.

Where CloudCannon comes in # Direct link to this section

Static sites solved performance, security, and hosting a long time ago. What held them back was the editing experience, and that’s the problem we build for.

CloudCannon is a Git-based CMS. Your site lives in your repository as plain files, built by whichever static site generator your developers picked. Editors get a Visual Editor where they click on the page and change what’s there. Their edits commit back to Git, so developers and editors work on the same files without getting in each other’s way.

Because the whole project is plain files in a repo, AI agents can read and contribute to it too, through the same branch-and-review workflow as any other contributor.

Start a free trial, or book a demo if you’d rather have someone walk you through it.