Static-first: when a small site doesn't need a single-page app

Somewhere in the last decade the single-page app stopped being a tool you reached for when a project needed it and became the default starting point for almost any new website. Spin up the popular framework, and before you have written a line of your own logic you are shipping an application: a bundle of JavaScript that downloads to the browser, boots up, and then renders your content on the user’s device. For a genuinely app-like product — a collaborative editor, a dashboard, a design tool — that machinery is worth it. For a small content site, a blog, a marketing page, or a single-purpose tool, it is usually a heavy answer to a question nobody asked, and reaching for it by reflex quietly costs you load time, complexity, and durability you did not have to spend.

The alternative is not a step backwards into 2005; it is a deliberate posture I will call static-first. The idea is simple: ship real HTML that the browser can render the instant it arrives, and add JavaScript interactivity only to the specific places that actually need it, rather than wrapping the whole site in an application by default. This article makes the case for that posture — what a SPA really costs, why most "sites" are content with a little interactivity rather than apps, what progressive enhancement buys you, how to decide feature by feature instead of all-or-nothing, and the honest list of cases where a SPA still earns its keep.

It helps to be precise about the thing we are weighing. In the classic model of the web, each page is a document the server sends as finished HTML; the browser, which is extraordinarily good at rendering HTML, paints it immediately, and clicking a link fetches the next finished document. A single-page app inverts that. The server sends a nearly empty HTML shell plus a large JavaScript bundle; the browser downloads and executes that bundle, which then constructs the page in the user’s device and takes over navigation, so that subsequent "page" changes happen by JavaScript rewriting the current document rather than fetching a new one. Modern frameworks blur this with server rendering and hydration, but the defining trait remains: the application code is the thing that runs the site, and the user’s device pays to boot it.

None of that is bad engineering in itself — it is the right architecture for software that lives in a browser tab and behaves like a desktop application. The problem is purely one of fit. When you adopt the SPA model for content that does not need it, you inherit all of its costs — the bundle, the boot, the hydration, the client-side routing, the build complexity — while using almost none of the capabilities that justify those costs. You are paying the application tax on something that was never an application, and the bill arrives as slower first loads and a heavier project for every visitor and every future change.

The most visible cost is time to first meaningful paint. A static document appears as fast as the network can deliver a small file; a SPA shows nothing useful until the bundle has downloaded, parsed, and executed, which on a mid-range phone over an ordinary connection is a measurable, sometimes uncomfortable, delay. That gap is exactly the window the Core Web Vitals are designed to measure and penalise, and it is felt most acutely by the visitors least able to absorb it — people on older devices and slower networks, who are a larger share of the real-world audience than the developer’s fast laptop suggests.

The less visible cost is everything that is not load time. A SPA needs client-side routing, state management, a build pipeline, and a hydration step that re-attaches behaviour to server-rendered markup — and each of those is a system that can break, drift out of date, or simply demand attention that a content site never should. There is a reliability cost too: when the whole page depends on JavaScript executing correctly, a single bundle error can blank the entire screen, whereas a static page with a broken script still shows its content. For a one-person project especially, the cheapest code is the code you never had to write, and the SPA-by-default choice signs you up to maintain a great deal of it.

The case for static-first rests on an honest look at what most websites actually are. A blog is a set of articles. A marketing site is a handful of pages that explain a product. A documentation site is structured reading. A small tool is one focused interaction surrounded by explanation. In every one of those, the overwhelming majority of the experience is content the user reads, and only a small, well-defined slice is genuinely interactive — a search box, a filter, a contact form, the tool’s one canvas. Treating the whole thing as an application because of that slice is letting the tail wag the dog.

Static-first takes the opposite view: the content is the site, and it should be delivered as fast, robust HTML; the interactive slice is an enhancement layered on top of that solid base. This is not a compromise that sacrifices interactivity — the interactive parts are exactly as capable as they would be in a SPA — it is a reordering of priorities so that the 90% that is reading loads instantly and never depends on a bundle, while the 10% that is interactive carries its own weight only where it sits. The result is a site that feels fast everywhere and only spends the visitor’s battery and patience where there is genuine interaction to justify it.

The technique that makes static-first work is progressive enhancement, which sounds academic and is really just common sense about layering. You start with a baseline that works using the most reliable building blocks — HTML for content and structure, a little CSS for presentation — so that the core of the page is useful before a single line of your JavaScript runs. Then you enhance: you add JavaScript that improves the experience for the browsers and devices that can run it, in a way that fails gracefully where it cannot. A link that works as a plain link gains instant client-side navigation when the script loads; a form that submits the ordinary way gains inline validation on top. Nothing essential is gated behind the enhancement.

The pay-off is robustness that a JavaScript-first build cannot match. The page is useful the moment the HTML arrives, so the slowest, flakiest part of the stack — downloading and running a bundle on an unknown device — is never on the critical path to seeing your content. When the enhancement does load, the experience gets nicer; when it is slow, blocked, or broken, the visitor still reads the article and submits the form. Building this way is also a forcing function for restraint: because the baseline has to stand on its own, you end up writing less speculative interactivity and more of it where it genuinely helps.

The framing that trips people up is treating this as a single, site-wide religious choice — SPA or not — when the useful unit of decision is the individual feature. A site is rarely uniformly static or uniformly interactive; it is a reading-heavy body with a few interactive organs. So the right question is not "should this site be a single-page app" but "does this particular feature need client-side application behaviour, and does the rest of the site need to pay for it." Asked that way, the answer for the article, the about page, and the docs is almost always no, while the answer for the one live tool might be yes — and crucially, the second answer does not have to drag the first three into the application model.

In practice that means letting the content pages be static and fast, and scoping the genuinely app-like behaviour to the component or route that needs it, so the JavaScript loads where the interaction lives rather than everywhere. A reader on an article should not download the tool’s engine; a user of the tool can, because that is what they came for. This per-feature discipline is how you get the best of both: the instant, durable delivery of static content and the rich interactivity of an application, without forcing every visitor to pay the application tax to read a paragraph.

Static-first is a default, not a dogma, and there is a real class of product where the single-page application model is exactly right. The honest test is whether the experience is fundamentally an application that happens to run in a browser rather than a document the user reads. If the user spends a long, continuous session manipulating live state — a spreadsheet, a design canvas, a collaborative document, a trading interface, a complex configurator — then full page loads between every interaction would be absurd, and the SPA’s client-side state and instant in-place updates are the entire point. There, the bundle and the boot are paying for capabilities the product cannot exist without.

The distinction to hold onto is that these are interaction-dominated experiences, not content-dominated ones, and the population of sites that genuinely qualify is much smaller than the population of sites built as SPAs. A useful gut check: if you can imagine the experience working acceptably as a set of distinct pages with a little interactivity sprinkled in, it is a content site and belongs on the static-first path; if distinct pages would obviously break the experience, you have a real application and the SPA machinery has earned its place. Reaching for the application model when the gut check says "content site" is the specific mistake static-first is meant to prevent.

There is a quieter benefit to static-first that matters enormously for small, self-funded projects: static content is radically cheaper and sturdier to host. Finished HTML, CSS, and images are just files, and serving files from a content delivery network is close to free at the scales most small sites operate at, with no servers to scale, no runtime to crash under a traffic spike, and a cache that absorbs a sudden surge without you lifting a finger. A static page that goes viral is a non-event; a server-rendered application that goes viral is a capacity problem. For a portfolio of free tools funded by ads rather than subscriptions, that difference is the line between a traffic surge being pure upside and being an outage.

Reliability compounds the savings. Fewer moving parts means fewer things that can fail, and the things that remain fail more gracefully, because the content does not depend on a runtime executing correctly. This is the same instinct behind keeping the whole operation lean — every system you do not run is a system that cannot page you at midnight — and it is why static-first is not only a performance choice but an operational one. The fastest, cheapest, most reliable request is the one your infrastructure can answer with a cached file, and static-first arranges for as much of the site as possible to be exactly that.

You do not have to tear down a working site to move in this direction, because static-first is a posture you can adopt incrementally. The first move is simply to stop reaching for the application model as the default for new pages: when you add an article, a landing page, or a docs section, ship it as static HTML and resist wrapping it in client-side machinery it does not need. The second move is to audit the interactive features you already have and ask, one at a time, whether each truly needs to run as part of an application or whether it could be a self-contained island of JavaScript on an otherwise static page. Most can be the latter, and each one you convert lightens every page it used to weigh down.

The mindset that makes this stick is to treat JavaScript as a cost you justify rather than a capability you assume. Every kilobyte of script the browser must download and run is a kilobyte the visitor pays for in time and battery, so the bar for shipping it should be "this interaction genuinely needs it," not "this is how we build things now." Hold that bar and a site naturally settles into the static-first shape: fast, robust content everywhere, with interactivity concentrated exactly where it earns its weight. That is not a nostalgic rejection of modern tooling — it is using the modern tools with judgement, so the user, and your future self, get a lighter, sturdier site.