Why we ship static-first, even for dynamic products

A marketing page does not need a client-side router. It needs to arrive fast, be readable, and let one or two interactive pieces work. Serving pre-rendered HTML and hydrating only what moves is not a backward step — it is the lowest-risk way to hit performance budgets on a 4G connection in a tier-2 city.

What the numbers look like

On this site the HTML is under 30 KB, CSS under 12 KB gzipped, and the only JavaScript is a single deferred file handling navigation, scroll reveals, form submission and the pricing calculator. There is no framework runtime, no hydration cost and no layout shift from late-loading fonts because the font is loaded with display=swap against a matched fallback stack.

Where static stops being enough

Static does not mean "no backend". The enquiry pipeline behind this site is a real HTTP service with validation, rate limiting and a database. The distinction is between rendering and state: pages are computed at build time, while anything user-specific goes through a small, auditable API.

The trade-off, stated honestly

• Content changes need a rebuild — fine when publishing is intentional, annoying if ten editors change copy hourly.
• Highly personalised pages belong in a server-rendered app, not here.
• Search, filtering and accounts need a service layer; we add one rather than pretending static covers it.

For an agency site, a product marketing site or a documentation portal, static-first is usually the fastest and cheapest thing that can possibly work. We would rather spend the budget on the parts customers notice than on a runtime that exists to re-render text that never changed.