How to Choose a Web Framework for a Content-Driven Site

Choose a web framework by how it fetches content, not by how popular it is. For a content-driven site, the deciding factor is the fetch boundary. That means when your content is pulled, and where it turns into HTML. Get that wrong and no amount of tuning saves the page.

This matters more than most rankings admit. Only 48% of mobile origins pass all three Core Web Vitals. (Web Almanac 2025) Your framework sets the starting point on that scale. So does the CMS behind it. Draftbase serves content over a plain REST or GraphQL API. The fetch model stays your call.

What Makes a Content-Driven Site Different?

A content-driven site shows the same page to almost everyone. Blogs, docs, marketing pages, and product catalogs all fit. The bytes change on a publish, not on a click.

An app is the opposite. A dashboard renders per user and per session. It cannot be built ahead of time.

That split drives the whole choice. Most framework roundups rank tools on app problems. They weigh state, routing depth, and hydration speed. A content site barely touches those.

It needs two things. Bytes on screen fast. A clean way to pull content from a CMS.

Name which one you are building first. If you cannot answer that, the rest of the list is noise. The framework basics guide covers the vocabulary.

Which Rendering Model Fits Your Content?

Every framework picks a default moment to render. There are three. Each suits a different content shape.

Model	Renders at	Fits	Cost
Static	Build time	Docs, blogs, marketing	Rebuild to publish
Server	Each request	Per-user or fast-moving content	Server cost, slower TTFB
Incremental	First request	Large catalogs, mixed freshness	First visitor sees stale

Static wins on speed. The HTML already exists when the request lands. Nothing has to run.

Astro defaults to this model. It ships zero JavaScript unless a component asks for it. (Astro Docs)

Server rendering wins on freshness. Next.js leans here, with server components on top. That fits signed-in content. It is dead weight on a static blog.

Incremental rendering sits between them. A page builds on its first request, then caches. The tradeoff is real. The first visitor after a change gets the old version. (Stack Overflow Blog)

Most frameworks can do all three. The default still matters. You will fight anything you set against the grain.

How Often Does Your Content Change?

Publish rate is the second axis. Teams skip it constantly.

Static builds scale in a straight line with page count. Double the pages and you double the build. That is fine at 200 pages. It breaks at 50,000.

A big catalog with a dozen editors can make full rebuilds impossible to schedule. (Stack Overflow Blog)

Run the math before you commit. Multiply your page count by build time per page. Compare that to how often someone hits publish.

Say a rebuild takes 20 minutes. Editors publish hourly. Pure static is already wrong, and you want incremental or server rendering.

Now flip it. Editors publish twice a week. That same 20-minute build costs you nothing.

There is a third case worth naming. Some sites are huge but rarely change. A docs archive fits here. Long builds are fine when they run once a month.

Which Framework Do the Numbers Favour?

Adoption tells you about hiring and plugins. It does not tell you about fit. Read it that way.

React sits at 44.7% use among surveyed developers. Next.js reached 21.5%. (Stack Overflow Developer Survey 2025) Those are the widest hiring pools by far.

Developer sentiment tells a different story. Astro leads meta-framework scores over Next.js by 39 points. (State of JavaScript 2025) Next.js also drew the largest drop that year.

Do not read that as "Astro wins." Read it as a fit signal. Astro users mostly build content sites, and Astro is built for content sites.

Next.js carries a wider load. It covers apps that Astro would not suit at all. Vercel's own comparison makes the same split. (Vercel)

A high score from a narrow user base is not proof of a better tool. It is proof of a tighter match. Aim for that match yourself.

The Factor Most Comparisons Skip: LCP, Not Clicks

Here is the part almost every roundup misses. They benchmark how fast a page responds to input. The real failure is loading.

Break the Core Web Vitals numbers apart. On mobile, 81% of origins record a good CLS. 77% record a good INP. Only 62% manage a good LCP. (Web Almanac 2025)

INP measures how fast a page answers a tap. It is mostly a solved problem now. LCP measures how fast the main content paints. That is the metric still failing, on nearly four in ten origins.

So the framework feature that counts is not hydration strategy. It is how early the content bytes arrive.

A build-time fetch beats a request-time fetch on LCP every time. The work already happened. Nothing waits on a network call.

This reframes the whole question. Stop asking which framework hydrates faster. Ask which one gets your CMS content into HTML soonest.

That points straight back at the content layer. A CMS that only ships a heavy client SDK forces a request-time fetch. A CMS with a plain cached HTTP API lets you fetch at build time instead.

Draftbase serves REST and GraphQL over a cached delivery API. Either model works without a workaround.

What Does the Fetch Boundary Look Like in Code?

The difference is smaller than it sounds. Both fetch the same API. They differ on when.

In Astro, the fetch runs at build time by default. The result is baked into the HTML.

---
const res = await fetch('https://api.draftbase.co/delivery/entries?templateId=blogPost', {
  headers: { Authorization: `Bearer ${import.meta.env.DRAFTBASE_KEY}` },
});
const { items } = await res.json();
---
<ul>{items.map((post) => <li><a href={`/blog/${post.slug}`}>{post.title}</a></li>)}</ul>

In Next.js, the same call runs per request unless you cache it. One option changes that.

const res = await fetch('https://api.draftbase.co/delivery/entries?templateId=blogPost', {
  headers: { Authorization: `Bearer ${process.env.DRAFTBASE_KEY}` },
  next: { revalidate: 3600 },
});

That revalidate value is the whole decision in one line. Set it low and you pay per request. Set it high and editors wait to see changes.

Pick the number from your publish rate, not from a default. This is the same math from the section above, now in code.

Where the CMS Limits the Framework

Framework and CMS are one choice in two parts. Teams pick them in sequence and regret it.

The trap is content format. Say your CMS stores rich text in its own tree shape. A framework swap now means moving the content too, not just the templates.

Draftbase stores rich text as plain MDX strings. There is no vendor tree to convert if you move from Next.js to Astro later.

Check the delivery API shape as well. Confirm it is cacheable, keyed, and rate-limited before you build against it. A slow API caps your build speed, whatever the framework does.

The headless CMS evaluation framework covers the rest of that checklist. For the fetch-and-cache pattern in code, see using a headless CMS with React.

Conclusion

Choosing a web framework for a content site comes down to three questions. What shape is the content? How often does it change? How early can it turn into HTML?

Answer those and the shortlist writes itself. Mostly static and slow-moving points to Astro. Per-user or fast-moving points to Next.js. Huge and mixed points to incremental rendering.

Then pick the content layer in the same pass, not after. Draftbase's Hobby plan is free, and Startup runs $49/mo. Both serve the same MDX over REST and GraphQL, so your framework choice stays reversible. See the pricing page for the full breakdown.