Static, server-rendered or app: which kind of website are you buying?

A website quote rarely says what kind of website it is. It names a platform or a framework and moves on to the price. But under every quote is one of three shapes, and the shape decides what runs when a visitor arrives, what has to be patched, and what you will pay to keep it up. This post explains the three, shows how to spot each one in a quote, and says which one we build and why.

The three shapes

Google’s guide to rendering on the web, by Addy Osmani and Jason Miller, gives the definitions the industry uses^[1]. We will use plainer names for the same three.

Static files. The site is built once, in advance, into finished pages. Google’s term is static rendering or prerendering: “Running a client-side application at build time to capture its initial state as static HTML.”^[1] When a visitor arrives, nothing is computed. A file is sent. The guide notes that “you can deploy static renders to multiple CDNs to take advantage of edge caching”^[1]: the pages can be copied to servers around the world and served from the nearest one.

Server-rendered. The page is assembled fresh on a server each time someone asks for it. Google defines server-side rendering as “Rendering an app on the server to send HTML, rather than JavaScript, to the client.”^[1] WordPress works this way: every visit runs code on a server, reads a database and builds the page. The cost is in the same guide: “generating pages on the server takes time, which can increase your page’s TTFB”^[1], the time before the first byte reaches the visitor.

Client-side application. The server sends an almost empty page and a large JavaScript program, and the visitor’s browser draws the site. Google calls this client-side rendering: “Rendering an app in a browser, using JavaScript to modify the DOM.”^[1] MDN, Mozilla’s reference for web developers, describes the result: such applications “load a single HTML shell, and continually update the DOM inside it (referred to as single page apps, or SPAs) without navigating users to new addresses on the web”^[2]. The drawback, in Google’s words: “the amount of JavaScript required tends to grow as an application grows, which can impact a page’s INP”^[1], Google’s measure of how quickly a page responds to a tap.

How to tell from the quote

Proposals rarely use these words. They leave clues.

• “WordPress”, “theme”, “plugins”, “page builder”, “hosting plan”, “cPanel”. Server-rendered. A program runs on a server for every visit, and the plugins run with it.
• “React app”, “Angular”, “Vue”, “single-page app”, “web app”, “dashboard”. A client-side application. The browser does the work.
• “Static site”, “Astro”, “Hugo”, “Eleventy”, “deployed to a CDN”, “Cloudflare Pages”, “Netlify”. Static files. The site is built in advance and copied to a network.

If the quote does not tell you, ask one question: “When a customer opens my home page, does anything run on a server?” The answer sorts the quote into a row of the table below.

The comparison

Kind of site	What the server does per visit	What the browser downloads	What has to be patched	Typical fit
Static files	Sends a finished file. No code runs[1]	HTML, CSS, images; little or no JavaScript	The build tools, at build time only	Marketing sites, brochures, blogs, documentation
Server-rendered	Runs the application, queries a database, assembles the page[1]	HTML, CSS, images, plus the theme’s scripts	The server, the language runtime, the CMS, every plugin and theme[3]	Sites with logins, personalised pages, frequent editor changes
Client-side application	Sends an empty shell and the program[2]	The whole application as JavaScript, then data	The framework and its dependencies, plus any API it calls	Software: dashboards, tools, anything that behaves like an app

The middle column is where visitors feel the difference. The HTTP Archive’s 2024 Web Almanac, which measures millions of real pages, reports “the median JavaScript payload rising by 14%, reaching 558 kilobytes on mobile and 613 kilobytes on desktop”^[4], with “approximately half the bytes downloaded being unused during page load”^[4]. A static site has no reason to be anywhere near that median. The islands post shows what a content page on this site sends instead.

What each one costs to host

A server-rendered site needs a server that is switched on, waiting, for every visitor. That is a hosting plan: a monthly fee whether anyone visits or not, and it has to be big enough for your busiest hour.

A static site needs somewhere to keep files and a network to serve them. We use Cloudflare Pages, which describes itself as a way to “Deploy full-stack applications instantly to the Cloudflare global network”^[5]. Its published free-plan limits are 500 builds a month, up to 20,000 files per site and 100 custom domains^[6]. There is no server to size, because there is no server.

A client-side application is often hosted like a static site, because its shell and JavaScript are files. The cost moves to whatever it talks to: an API, a database, a login service. Ask who pays for that.

What each one costs to secure

This is the column that decides most of the ongoing bill, and it is the least discussed.

A server-rendered site is running code that can be attacked. The Web Almanac’s 2024 CMS chapter reports that “51% of the websites in the Web Almanac’s desktop dataset were powered by a CMS” and that “WordPress sites account for the majority of the relative market share—with over 35% adoption on mobile in 2024”^[7]. Patchstack, a WordPress security company, reports that “7,966 new security vulnerabilities were found in the WordPress ecosystem in 2024”, “a 34% increase over 2023”, and that “96% of the vulnerabilities were uncovered in plugins, and 4% were found in themes. Only seven vulnerabilities were uncovered in WordPress core itself.”^[8]

The plugins are the point. WordPress’s own hardening guide says “make sure your plugins are always updated”^[3], and warns that once a fix is released “the information required to exploit the vulnerability is almost certainly in the public domain”^[3]. Whose job is that? Web hosts “are not responsible for the application you choose to install”^[3]. Somebody has to log in every week, press update, and check that nothing broke. That is the maintenance retainer in a WordPress quote.

A static site has no application running on the server, so there is nothing for that class of attack to reach. MDN puts the advantages in one line: “performance (your user’s device isn’t building the page with JavaScript; it’s already complete) and security (static pages have fewer attack vectors)”^[2]. What remains to secure is the build pipeline and the one or two small functions that handle things like a contact form.

A client-side application sits between the two. Its files are static, but MDN warns it is “possible to write a fragile application that depends entirely on JavaScript and will not function without it”^[2], and its dependencies need updating as plugins do.

Which one we build

We build static sites, and add a server only where a page needs one. That is the design of Astro, the framework under this site. Its principles are “Content-driven” and “Server-first”; the documentation states that “Websites run faster when they render HTML on the server” and that it “should be nearly impossible to build a slow website with Astro”^[9]. By default, “Astro pages, routes, and API endpoints will be pre-rendered at build time as static pages”^[10]. Pages can be switched to on-demand rendering, “generated per visit, and can be customized for each viewer”, but Astro’s advice is to “Start with the default ‘static’ mode until you are sure that most or all of your pages will be rendered on demand!”^[10]

This site follows that advice. Every page you can visit is a static file. The one thing that runs on a server is the handler behind the brief form, a Cloudflare Pages Function, which Cloudflare describes as a way to “deploy server-side code to enable dynamic functionality without running a dedicated server”^[5]. The form gets a server for the second it needs one; the rest of the site never does. Three parts of the site are React islands, for the reasons in the React post, and the resulting page weight and Lighthouse scores are published on the home page with the date they were measured.

MDN gives the test we apply: if a project has “a few pages, and those pages have little or no interactive capability, a framework (and all of its JavaScript) may not be necessary at all”^[2]. That describes most marketing sites.

When the other two are right

A static site is the wrong answer for some briefs, and we will say so. If visitors log in and see their own data, a page rendered on demand “can show a logged-in user their account information or display freshly updated data without requiring a full-site rebuild”^[10], and that needs a server. If the site is really a product, with accounts and workflows, it is an application, and the JavaScript is the point rather than the cost. We do not build ecommerce stores or web applications; if your brief describes one, we will point you to a specialist.

What you can do next

Take the quote you have and find its row in the table. Then ask what the server does per visit, who patches what, and what the monthly figure covers once the build is done. If you do not have a quote yet, the brief builder takes about three minutes, and the reply names the kind of site we recommend and a fixed price.

Reference list

All sources accessed 17 March 2026.

1. Osmani, A. and Miller, J. (2019, updated 2026) Rendering on the Web. web.dev, Google. https://web.dev/articles/rendering-on-the-web
2. MDN contributors (n.d.) Introduction to client-side frameworks. MDN Web Docs, Mozilla. https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Frameworks_libraries/Introduction
3. WordPress.org (n.d.) Hardening WordPress. WordPress Developer Resources, Advanced Administration Handbook. https://developer.wordpress.org/advanced-administration/security/hardening/
4. Amjad, A. H. and Goel, N. (2024) 'JavaScript', in The 2024 Web Almanac. HTTP Archive. https://almanac.httparchive.org/en/2024/javascript
5. Cloudflare (n.d.) Cloudflare Pages. Cloudflare Docs. https://developers.cloudflare.com/pages/
6. Cloudflare (n.d.) Limits. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/platform/limits/
7. Wold, J., Raykova, L. and Kaleev, N. (2024) 'CMS', in The 2024 Web Almanac. HTTP Archive. https://almanac.httparchive.org/en/2024/cms
8. Patchstack (2025) State of WordPress Security in 2025. Patchstack. https://patchstack.com/whitepaper/state-of-wordpress-security-in-2025/
9. Astro (n.d.) Why Astro? Astro documentation. https://docs.astro.build/en/concepts/why-astro/
10. Astro (n.d.) On-demand rendering. Astro documentation. https://docs.astro.build/en/guides/on-demand-rendering/