Static, server or edge? Choosing where your website should run

Modern frameworks let you choose, often page by page, where and when your HTML is produced. That flexibility is powerful, but it also creates a question many teams answer by habit rather than by need: should this be static, server-rendered or running at the edge?

The choice affects your hosting bill, how fast pages load around the world, how fresh your content is and how much can go wrong. Here is a plain-language comparison.

The three options

Static

Pages are rendered once, at build time, into plain HTML, CSS and JavaScript files. Those files are uploaded to a content delivery network (CDN) and served from locations close to each visitor. Nothing runs on a server when someone requests a page. This website is built this way, as a static export of a Next.js app.

Server-rendered

Each request reaches a server (or a serverless function) that fetches data, renders the HTML and sends it back. Pages can be personalised and always reflect the latest data. Results can still be cached for a period to reduce load.

Edge

Small functions run on the CDN’s own network, in many locations worldwide, before or instead of reaching a central server. They start quickly and are close to users, but run in restricted environments with limits on execution time, memory and which libraries and APIs are available.

Side-by-side comparison

When static is the right choice

• Marketing sites, documentation, blogs and landing pages.
• Content that changes a few times a day at most, where a rebuild on publish is acceptable.
• Sites that must stay up under unpredictable traffic, such as launches or campaigns.
• Projects where low running cost and minimal maintenance are priorities.

Static does not mean non-interactive. Forms can post to a form service or an API, search can run in the browser or through a hosted search service, and logged-in areas can live in a separate app.

Where static delivery saves money

The saving is not only a cheaper hosting plan. Static delivery removes per-request rendering, avoids paying for idle application servers and lets the CDN absorb sudden traffic without scaling the database. Compare a representative month including compute, load balancing, bandwidth, build minutes, image handling and monitoring rather than comparing headline plan prices.

Choose how content becomes fresh

• Publish-triggered builds suit marketing pages and documentation where editors expect an explicit release.
• Timed revalidation suits catalogues where content may be a few minutes behind the database.
• Client-side fetching suits a small live region, such as availability, inside an otherwise static page.

When you need a server

• Pages that depend on who is logged in: dashboards, account pages, admin tools.
• Data that changes constantly and must be current, such as stock levels, live listings or prices.
• Very large numbers of pages where rebuilding them all is impractical, such as a marketplace with hundreds of thousands of listings.
• Server-side work such as payments, file processing and sending email.

When edge functions make sense

• Redirects, rewrites and A/B test assignment that must happen before the page loads.
• Lightweight personalisation based on country, language or device.
• Authentication checks that decide whether a request may continue.
• Adding security headers or blocking obvious bot traffic.

Hybrid is the normal answer

Most products benefit from mixing approaches. A common, cost-effective setup looks like this:

1. Marketing pages, blog and help centre: static, served from a CDN.
2. Public listing and category pages: server-rendered with CDN caching, or incrementally regenerated.
3. Logged-in application: server-rendered or a client-side app talking to an API.
4. Edge middleware: redirects, locale detection and simple access checks.

Questions that decide it

A worked example: a classifieds marketplace

Consider a jobs or property marketplace with a public website, thousands of listings that change every hour and a logged-in area where employers or agents manage their ads. A sensible split looks like this:

• Home page, about pages, pricing and the blog are static. They change rarely, must load instantly and should survive any traffic spike from a campaign.
• Category and location pages, such as jobs in a given city, are server-rendered with a short CDN cache of a few minutes. Search engines and visitors get fast HTML that is never more than a few minutes out of date.
• Individual listing pages are server-rendered on first request and cached until the listing changes, with the cache cleared when the advertiser edits or the listing expires.
• The advertiser dashboard is fully dynamic, because every page depends on who is signed in.
• Edge middleware handles redirects from old URLs, language detection and blocking abusive bots before requests reach the servers.

This arrangement keeps the hosting bill low, because most traffic is served from cache, while every page that needs fresh or personal data gets it. It also means a sudden surge of visitors from a news story mostly hits the CDN rather than your database.

Common mistakes

• Server-rendering pages that are identical for every visitor, paying for compute on every request for no benefit.
• Making everything static and then fighting slow, fragile rebuilds as the number of pages grows into the hundreds of thousands.
• Moving logic to the edge for speed while it still waits on a database on another continent.
• Turning off caching to fix one stale-data bug instead of invalidating the cache when the data changes.

Choosing the right rendering strategy early saves money every month for the life of a product. If you are planning a new site or app, or your hosting bill has crept up, we are happy to review your setup and recommend the simplest architecture that does the job.