Static site or content management system.

A static site generates its pages in advance and serves them as files; a content management system generates pages from a database at request time.

This decision does not look like a performance decision, yet it is performance’s single largest determinant. Time to first byte, scaling behavior, security surface and maintenance cost — all four derive from this choice. And the decision is made at the project’s start and rarely reversed.

The debate usually runs on the wrong axis: speed versus convenience. The real axis is different — how often the content changes, and who changes it.

The technical difference

A content management system repeats the same work on every request: it queries the database, renders the template, produces the HTML, sends it. A static site does that work once — at publish time — and afterwards only sends files.

The difference shows directly in the time to first byte. Sending a file is an order of magnitude cheaper than querying a database and rendering a template. This site’s live measurement is 0.302 seconds, and on the three projects it manages the value is under 300 milliseconds.

The second difference is in scaling: static files can be cached without limit on edge servers because they are the same for every user. When traffic grows tenfold, there is no application layer that needs scaling.

The third is security: where no code runs, no vulnerability exists. Database injection, plugin exploits and admin panel attacks — all three are undefined on a static site.

The real trade-off

The price of the static approach is in convenience, and the price is real. When content changes, a rebuild is needed; for a non-technical editor that can be a barrier. And genuinely dynamic content — session-based personalization, live stock, user comments — cannot be static.

1. Static fits — brochure sites, documentation, blogs, portfolios, campaign pages. Content changes rarely and is the same for everyone.
2. Static does not fit — user accounts, carts, live prices, personalized content.
3. Hybrid is possible — most pages static, only the changing pieces on the client or in edge functions.
4. The editor problem is solvable — an interface wired to the build process can give the editor a classic panel experience.
5. The decision criterion — how often does the content change, and who changes it?

The third item is the most common solution today: the page body static, only the genuinely dynamic small pieces handled separately. This site is exactly that — fifty-eight pages sit as files, and the only piece of code running at request time is the contact form’s server-side proxy.

The maintenance side

The most overlooked difference in the long run is the maintenance cost. A content management system is a software stack needing constant updates: the core, the plugins, the themes, the database and the runtime. Each is a separate update and a separate breakage risk.

On a static site, what ships is only files. Even if the build tool is never updated, the live site keeps working — because nothing is running. For brochure sites that must stand for three to five years, that is a marked advantage.

The price: the build chain itself is a dependency, and if that chain breaks, new content cannot be published. Keeping the chain simple and low on dependencies shrinks that risk.

Where no code runs, no code crashes — but if the generating code breaks, no new content ships either.

Migration: moving an existing site

Moving an existing content management system to a static architecture is a more common decision than assumed, and it can usually be done gradually. Instead of a full migration, statifying a share of the pages delivers most of the benefit in most cases.

1. Export the content — the existing system’s data is converted into a structured form.
2. Preserve the URL structure — changing addresses loses the accumulated search visibility; where change is unavoidable, redirects are set up.
3. Start with the highest-traffic pages — the gain comes from there.
4. Separate the dynamic pieces — forms, search, comments. These are handled apart.
5. Solve the editor flow — a non-technical person must be able to change content.
6. Set up measurement first — to show the migration worked, the before must have been measured.

The last item is the most skipped and produces the most regret: to answer “did it get faster” after the migration, the before must have been measured. A measurement set up afterwards can never make that comparison.

The second item is the migration’s riskiest side. When the address structure changes, the accumulated indexing and link value can be lost; even with redirects in place there is some loss. Being able to keep the addresses is the migration’s most valuable design constraint.

A practical checklist

Turning this page into an audit step, here is what to check for the architecture decision. The list is kept short because long lists do not get walked; six items fit in one sitting.

1. How often does the content change — daily or monthly?
2. Who changes it — a technical person or an editor?
3. Is there genuinely personalized content?
4. Does the traffic fluctuate — is scaling a concern?
5. What is the maintenance capacity — who carries the update burden?
6. How wide can the security surface be?

The first two items give most of the decision. Content changed a few times a month by a non-technical person suits a hybrid solution; content changed many times a day by many people suits a classic system better.

A warning to close: this decision is not a matter of ideology. Advocates of the static approach sometimes present it as fitting every case, and that harms the person deciding. Trying to statify a genuinely dynamic system gains no performance and eases no maintenance — it only adds complexity.

The right question is not “which is better” but “which does my content fit.” The answer comes from the content’s change frequency and from who changes it — not from a technology preference. On this site the answer was static, because the content changes rarely and the person changing it is technical — on another project the same question can have a different answer, and that is as it should be.