Static sites vs dynamic websites, explained

A static website has its pages built once, in advance, as plain files ready to be served exactly as they are. It does not get assembled fresh by a server every time a visitor requests one. That single difference is where nearly all of a static site’s distinctive advantages and limitations come from.

How static websites differ from dynamic websites and the platforms already covered

WordPress, Shopify’s storefront and most CMS-driven sites are, by default, dynamic. A server receives a request, fetches content from a database, assembles the page, and sends it — every single visit. A static site skips that assembly step at the moment of the visit. The page was already assembled ahead of time, during a separate build process. The server’s only job is to hand over a file that already exists.

Why this makes a static site fast almost by default

Serving a pre-built file needs none of the database queries or template processing a dynamic request does. That removes a large share of the work that typically slows a page down. This is a genuine, structural speed advantage, not a configuration choice. The mechanics of why are covered fully in why websites are slow — static architecture removes several of the most common causes before they can occur.

Why this makes a static site a smaller security target

A database that is queried on every visit is also a database that can be attacked on every visit. A static site generally has no live database exposed to visitor requests at all, and no server-side application code processing visitor input on each page load. That removes an entire category of the vulnerabilities covered in why small-business websites get compromised. This does not make a static site unhackable. It removes a specific, common attack surface, not every conceivable one.

What a static site gives up

Anything that must be different for each visitor, or that changes between visits without a full rebuild, is harder to do on pure static architecture. Some things need more than the static core provides: a logged-in account area, a live shopping cart, real-time content that changes independently of a rebuild, and comment sections. Each of these needs something added on top. Commonly that means a separate, dynamic service handling just that one function, or a rebuild triggered whenever content changes. This is a real limitation for a site whose core function is dynamic. It is largely irrelevant for a site that is mostly brochure content plus occasional updates.

The static site generators (SSGs, or just an SSG) that pre-rendered these pre-built pages

The pre-built HTML files a static site serves are usually produced by a static site generator. SSGs such as Astro, Hugo, Eleventy or Next.js in its static-export mode take source content and templates. They pre-render every page’s HTML at build time, rather than leaving that work to a server-side process on each visit. Different generators make different trade-offs. Some lean toward content-heavy static websites with minimal JavaScript shipped to the browser. Others lean toward static sites that still run substantial client-side JavaScript once loaded. But all of them share the same core idea: do the assembly work once, ahead of time, rather than repeating it per request the way a dynamic website does. Use static generation for the content that does not change per visitor, and layer anything that genuinely does on top.

Editing a static site — where the headless CMS question resurfaces

A pure static site still needs someone to write and manage its content. The modern pattern pairs static output with a separate, often headless, content management layer. An editor writes and publishes as normal, and a build process converts that content into static files behind the scenes. What a custom-built website actually is covers this headless pattern directly. In practice, static architecture and headless CMS pairing are frequently the same decision, viewed from two different angles.

Who static sites genuinely suit, versus dynamic websites

A largely content-driven site — services, information, a blog, a portfolio — with modest or no need for logged-in, per-visitor functionality, is close to the ideal case. It gains real speed and security advantages with little given up in exchange. By contrast, a site whose core function is inherently dynamic — a marketplace, a booking system with live availability, a membership area — is working against the grain of the architecture, rather than with it.

What happens when content changes on a static site

A static site’s pages are built in advance, rather than assembled per request. So a content change does not appear instantly the way it would on a traditional CMS. It triggers a rebuild instead, regenerating the affected pages as static files, which then need to be redeployed. Modern static-site tooling generally automates this rebuild-and-deploy step, so it completes within moments of a content change being published. But it is a genuinely different mechanism from a traditional CMS’s immediate database update. It is worth understanding, so an editor is not confused by a brief delay between publishing a change and seeing it live.

Hybrid approaches, briefly

Many modern static-site setups are not purely static in the strictest sense. They generate most pages statically in advance for speed. A smaller number of genuinely dynamic elements — a live contact form submission, say, or a personalised element — are handled through a separate, narrowly scoped dynamic service layered on top. This hybrid pattern captures most of static architecture’s speed and security advantage. It still supports the handful of interactive features an otherwise content-led site actually needs.

Why hosting a static site is often cheaper too

Because there is no live application server processing every request, static sites can frequently be hosted on lower-cost infrastructure than an equivalent dynamic site would need. They are also well suited to distribution across a content delivery network by default. This cost advantage compounds with the speed and security advantages already covered. That combination is a large part of why static architecture has grown in popularity for content-led business sites specifically.

Where to go from here

The build decision between static architecture and a traditional CMS is one dimension of what a custom-built website actually is, which covers the fuller decision. And whether static architecture is the right fit for a specific business’s requirements is exactly the kind of question choosing a platform for your business works through.