Static site vs server side rendering

What each one means

Static site generation runs the site's code once during the build and writes an HTML file for every route it knows. Those files, with their scripts and styles, go onto a content delivery network that serves them from a location near each visitor. Server side rendering runs the same kind of code on a server when a request arrives, fetches whatever data the page needs, and returns fresh HTML. Frameworks such as React Router support both, and let one site mix them: its prerender option turns known paths into files at build time, while other routes can stay dynamic.

How they differ in practice

A static page is ready before anyone asks for it, so the first byte arrives quickly and the server does no work per visit. The trade off is freshness: if prices change in the database, the static HTML still shows the old ones until the site is rebuilt, unless the page loads live data in the browser after it appears. Server rendering always shows current data, but each visit costs compute time, and a slow database call slows the page. After either kind of HTML arrives, the browser loads the JavaScript and hydrates the page so buttons and forms work.

When to choose which

Most small business pages, such as home, services, about, contact and blog posts, change rarely and suit static generation. Pages that depend on the visitor, such as an account area, an order history or an admin screen, can be a static shell that loads the person's own data in the browser after sign in, or be rendered on the server. Server rendering earns its cost on pages with many dynamic URLs that must be indexed with fresh content, such as a large listings site. A booking site with a dozen pages rarely needs it.

Common mistakes

Calling a site static because it has no database, or dynamic because it has a contact form; the terms describe when HTML is made, not whether a site has features. Prerendering pages that show prices, then forgetting to rebuild after a price change. Rendering personal data into static HTML, where a CDN could cache it for the next visitor. Putting secrets in code that runs in the browser because a framework blurs which code runs where. And reading browser only values, such as the window size or the time, during the first render, which causes hydration mismatches.

Where it shows up in OneCraft

A OneCraft website is a React Router, Tailwind and shadcn/ui project written as code. Every build runs a typecheck, ESLint and the production build, then a layout check opens every prerendered page in headless Chromium at 375, 768 and 1280 pixels and fails on sideways overflow and on runtime or hydration errors. Publishing, on a paid plan, builds a chosen version and copies it to the CDN. When a capability needs data, such as bookings or orders, the agent gives the site its own database with row level security on every table, so changing data does not depend on rebuilding pages.

Questions people ask