The stack behind genuinely fast web apps
Speed is an architecture decision made a hundred times over. A tour of the choices — rendering, data, and delivery — that keep our apps fast under real load.
A fast web app is not the result of one clever optimisation. It is the accumulated effect of dozens of small, deliberate choices about where code runs, when data is fetched, and how bytes reach the browser.
Render on the server, hydrate what needs it
Most of a page is content, not interaction. Rendering that content on the server and shipping it as HTML means the browser has something meaningful to paint immediately, while only the truly interactive islands carry JavaScript. The result is a page that is useful before it has finished loading.
Treat data fetching as part of the design
Where and when you fetch data shapes how fast a page feels more than almost anything else. We colocate data with the components that need it, cache aggressively at the edge, and stream results so the shell appears the instant it can.
- Static-render anything that isn't personalised.
- Cache at the edge and revalidate on a schedule, not on every request.
- Stream long responses so the first paint never waits on the last byte.
- Ship images in modern formats, sized for the layout that requested them.
Measure what users feel
Synthetic scores are a starting point, not a finish line. We watch the metrics that map to perception — how soon the page is interactive, how stable the layout stays, how quickly the next navigation resolves — and we treat regressions in those as bugs, not cosmetics.
Fast is not a feature you add at the end. It is a constraint you honour at every layer, and the payoff is an app that feels effortless no matter the network it lands on.