Traffic shape decides your stack, not benchmarks

Every framework comparison measures the wrong thing. Hydration cost in a synthetic lab test tells you almost nothing about whether your marketing site should be static.

What decides it is traffic shape. How often the content changes, who reads it, and whether the page has to rank. Get those three right and the framework argument mostly answers itself.

Wrong cheap beats right expensive. Ship the boring thing, measure it, then fix what actually hurts.

Start with how often the content changes

Content velocity is the first fork in the road. A pricing page edited twice a year and a product feed updated every ninety seconds are not the same problem, even though both are "a website".

If the content settles for days at a time, you can build it once and serve it from the edge. Nothing computes per request. There's no database to fall over at 2am, and hosting rounds to zero.

If it changes constantly, that model breaks. You'll spend more engineering time inventing cache invalidation than you saved on servers.

When static wins

Marketing sites, documentation, changelogs, careers pages. Anything where search traffic matters and the content is written by humans on a human schedule.

We build these on Astro or Next.js, depending on how much interactivity the team expects to add later. Astro ships less JavaScript by default, which matters more than most teams assume. Google's Core Web Vitals thresholds are strict enough that a heavy hydration payload will quietly cost you rankings before anyone notices.

The tell that static is right: you can describe every page's data as "whatever was true when we last published".

When it flips

Behind a login, everything inverts. Content is personalised, search engines can't see it, and caching gets genuinely hard. Server components earn their complexity here, because the alternative is shipping a large client bundle that then makes six requests before showing anything useful.

The tell that you've crossed over: two users loading the same URL should see different things.

There's a middle case worth naming. Dashboards that are personalised but not sensitive, like an analytics view keyed to an account id, can often be served as a static shell with the data fetched client-side. You keep the instant first paint and skip the server round trip entirely. It's not fashionable, and it's frequently the right call.

What it costs when you get this wrong

We got it wrong once. A client dashboard, entirely behind auth, and we server-rendered all of it because that was the framework default and nobody questioned it.

It was slower than the single-page app it replaced. Every navigation went to the origin for data that hadn't changed. We'd added latency and removed the client-side cache that used to hide it.

Two weeks to unpick. The lesson wasn't "server rendering is bad". It was that we'd picked a rendering mode for the project instead of for the route.

The cost nobody prices in

Hosting is cheap. Engineering time isn't.

A stack your team already knows will ship faster than the theoretically optimal one they have to learn first. If your three engineers have shipped Rails for a decade, a Rails app you can maintain beats a distributed edge architecture you can't.

That's the answer most agencies won't give you, because "it depends on your team" doesn't sell a rebuild.

How we actually decide

1. List every route, not every page. Group them by how often the data changes.
2. Mark which routes need to be indexed by search engines.
3. Mark which ones differ per user.
4. Static for the first group, server-rendered for the third, and argue about the middle.
5. Pick the framework your team can staff, then optimise the routes that show up in real user monitoring.

Step five is where most of the wins are. You'll usually find two or three routes doing ninety percent of the damage, and none of them are the ones you worried about in the planning meeting.

If you want a second opinion before committing, our custom development team does short paid audits, and the MDN performance docs are a solid free place to start.