Why we build static sites (and when we don't)

When a client asks for “a fast website”, the technical answer almost always starts the same way: generate the HTML ahead of time. A static site loads faster, costs less to host and has fewer ways to break or get attacked. It’s not right for everything, but it’s right for a lot more than most people assume.

What “static” means

A traditional CMS-driven site assembles each page at the moment someone requests it: the server receives the visit, runs code, queries a database, puts the pieces together and only then responds. That happens on every visit, for every visitor.

A static site does that work once, when the content is published. The output is a folder of finished HTML, CSS and image files. When someone visits, the server simply hands over a file that already exists.

“Static” doesn’t mean frozen or boring. A static site can have animations, forms, search, 3D and content edited from an admin panel. What’s static is how the page is delivered, not what the page can do.

Four concrete advantages

Speed

Server response time is the floor for everything else: nothing gets painted until the HTML arrives. If the file is already built, that time is minimal. It’s the most direct way to protect LCP, one of the three metrics we cover in Core Web Vitals explained.

CDN: the site close to whoever visits

Because the site is just files, it can be copied to a CDN (content delivery network): servers distributed around the world. Someone in Miami gets the site from a nearby node; someone in Buenos Aires or Madrid gets it from another. For a business selling across the US and Latin America, that’s a difference visitors feel with no extra work.

It also handles spikes. If a campaign or a press mention multiplies your traffic in an afternoon, there’s no single server to overload and no database to fall over: the CDN keeps serving files.

Security

Most attacks on websites target things a static site doesn’t have: an exposed login panel, a database, outdated plugins. Without those pieces in production, the attack surface is much smaller. No site is invulnerable, but there’s far less to patch and watch.

Cost

Serving files is cheap. Several static hosting platforms have free tiers that comfortably cover a corporate site or a landing page, SSL included. Maintenance drops too: no PHP version to upgrade, no plugins to renew every year. In the total cost of a site, which we break down in how much a website costs, this weighs more than it seems.

Static vs. dynamic, side by side

	Static site	Traditional dynamic site
When the page is built	At publish time	On every visit
What the server does	Hands over a file	Runs code and queries a database
Hosting	CDN, free or low-cost	Server with a monthly fee
Attack surface	Small	Exposed admin, database and plugins
Technical maintenance	Low	Frequent updates
Per-user or real-time content	Needs extra pieces	Handled natively

How we do it: Astro and islands

We use Astro, a framework designed for content-driven sites. Two of its traits matter to us.

First, it ships no JavaScript to the browser by default. Pages arrive as HTML and CSS. If a component needs interactivity, you opt in explicitly.

Second, islands architecture. A carousel, a validated form or a 3D viewer are interactive “islands” inside a page that’s otherwise static. Each island loads its own code, and can be told to do so only when it’s about to scroll into view. The rest of the page doesn’t pay for it.

This very site is built that way: pre-generated pages, published to a CDN, with JavaScript only where there’s something to animate or submit.

So how do you edit content?

It’s the most common question, and a fair one: if the pages are already built, how do you change a sentence? Through an admin panel. You edit, save, and the site rebuilds and publishes itself. The difference from a traditional CMS is that the panel isn’t part of what the public sees: it’s a separate tool.

Forms follow the same logic. The form is HTML; the submission is received by a small server-side function that runs only when someone sends a message.

When static isn’t enough

There are cases where pre-generated HTML won’t cut it:

• Content that differs per user: a dashboard, an account with order history, anything behind a login.
• Data that changes by the minute: live inventory, prices that update, a feed.
• Very large catalogs with constant changes: regenerating thousands of pages for every edit stops being practical.
• Applications: when the product is the interaction itself, not the content.

Even then, it’s rarely all or nothing. In an online store, product pages can be static and fast while the cart and checkout are dynamic. In a web application, the public marketing site can be static while the app itself isn’t. Astro also lets specific routes render on the server on demand, without changing the rest.

Our rule

Static by default, dynamic where justified. The question we ask for every page is simple: does this change depending on who’s looking, or on what minute it is? If the answer is no, it gets built ahead of time.

Next step

If your current site is slow to load, needs security updates every month or pays for hosting it can’t justify, it’s worth checking whether the architecture is the right one. This is how we build custom websites; if you want to know how it would apply to your case, get in touch.