For years, the industry treated SPAs like a universal solvent—drop one into every project and everything gets “modern.” But if you’ve built or maintained a content-heavy site, you already know the bill came due: brittle performance, fragile SEO, and accessibility compromises that took longer to fix than they did to ship.

The good news is that course-correction is no longer theoretical. Multi-page apps (MPAs), delivered as HTML and progressively enhanced, are back—and for most content websites, they never should have left.

Why the SPA model broke content sites (not just “SEO”)⌗

An SPA optimizes for one primary goal: an app-like experience after the initial load, typically with most data and UI transitions handled client-side. That’s a great fit when the product is the UI—think Figma-style collaboration or Google Docs-like document editing—where the user continuously interacts with stateful interfaces.

Content websites are different. A blog, a landing page, a documentation portal, or a storefront is primarily about information retrieval: render content quickly, let users skim, make pages discoverable, and ensure assistive technologies can follow structure.

When you force an SPA architecture onto that job, you usually inherit several cascading problems:

  • First meaningful paint suffers. SPAs often ship a JavaScript bundle first, then render content later once the client hydrates and runs UI logic. Even if the final interaction is smooth, the initial “I can read this” moment can lag.
  • Indexing becomes a moving target. You can make SPAs work with server-side rendering or pre-rendering, but it turns a simple content pipeline into a complicated system with multiple render paths and edge cases.
  • Accessibility gets harder than it needs to be. SPA routing and dynamic content require careful focus management, live region announcements, history handling, and robust semantic structure. You can do it—but it’s not “free,” and it’s easy to regress.
  • Complexity creeps upward. A content site shouldn’t need a full application framework, client routers, state managers, and build pipelines to publish articles. Yet many teams ended up with exactly that.

In short: the SPA made content sites behave like applications. But content sites aren’t applications—they’re documents plus navigation.

The real reason MPAs are winning again: they ship HTML first⌗

The winning pattern is straightforward: render HTML on the server, send it over the wire, and enhance it progressively for interactions that actually need JavaScript. This approach is less about nostalgia and more about engineering leverage.

When you deliver meaningful HTML immediately:

  • Users see real content quickly, even on slow devices or spotty networks.
  • Search engines receive structured, crawlable pages without guessing what the client might render later.
  • Assistive technologies get semantic markup by default—headings, links, tables, lists—rather than reconstructed DOM trees.

Concrete example: a documentation page.

With an SPA, you often pay for:

  • A client-side router
  • A hydration step
  • A “loading” UI that replaces the server markup
  • Extra client logic to build headings, anchor links, and code blocks

With an MPA + progressive enhancement, you simply render the documentation page as HTML. If you want “copy code” buttons, collapsible sections, or client-side search, you add that on top—without turning the entire page into a JavaScript application.

The key is not “no JavaScript.” The key is “JavaScript when it helps,” not “JavaScript as the delivery mechanism for core content.”

Astro, server-rendered frameworks, and htmx: the modern toolkit for HTML-first⌗

The industry didn’t just “go back.” It improved the mechanics of shipping HTML-first while keeping developer experience sane.

Astro and component-driven static generation⌗

Astro’s core idea—ship less JavaScript by default and keep components composable—fits content sites like a glove. You can build a site with pages that are generated as HTML, then selectively hydrate interactive components only where necessary. The result is a clean separation between “content delivery” and “interactive behavior.”

Practical advice:

  • Prefer Islands of interactivity: buttons, modals, forms, widgets—hydrate only those.
  • Keep your routing and page structure server-rendered so deep links and sharing behave predictably.

Server-rendered frameworks (React/Vue/Svelte on the server)⌗

Server-rendered frameworks have matured: streaming, routing, data loading conventions, and tooling that make “render HTML on the server” a first-class default. If you need a component model, you can still have one—just don’t force the browser to become the primary renderer.

Practical advice:

  • Treat hydration as an enhancement, not a requirement for correctness.
  • Avoid client-side-only “blank pages.” If a page can’t render meaningfully without JavaScript, you’re back to SPA territory.

htmx for incremental interactivity⌗

If you want a particularly pragmatic approach, htmx is hard to ignore. It lets you sprinkle interactivity into server-rendered pages using declarative attributes—fetch partial HTML, swap DOM fragments, and keep the browser in charge of only the interaction.

A classic example: a product list with filtering.

  • The server renders the initial catalog as HTML.
  • When users filter, htmx requests the filtered HTML from the server and swaps the relevant section.
  • No SPA routing. No client-side state gymnastics. No hydration dependency.

This is not “less modern.” It’s just closer to how the web already works.

Progressive enhancement isn’t a vibe—it’s a discipline⌗

Progressive enhancement is often described as a principle, but in practice it’s a set of decisions. If you apply it consistently, it becomes a competitive advantage.

Here’s what it looks like in a content website build:

  1. Core content is server-rendered HTML.
    Your page must make sense with JavaScript turned off.

  2. Navigation works without a SPA router.
    Standard links should load new pages. If you want transitions, layer them on later.

  3. Forms work reliably.
    Use server-side validation and render form errors in HTML. Enhance with client-side validation only to improve usability, not to provide the only validation path.

  4. Interactive components are isolated.
    If a widget needs JavaScript, make it a self-contained enhancement. Don’t let one widget decide the rendering architecture for the entire page.

  5. Accessibility is part of the contract.
    Don’t treat focus states and announcements as afterthoughts. With HTML-first rendering, you get much of the semantic foundation for free.

Opinionated takeaway: if your “content site” behaves like an SPA core, you’re likely violating at least two of these disciplines—usually #1 and #2.

Performance isn’t just faster—it’s more predictable⌗

SPA defenders often argue that once the initial bundle loads, navigation becomes fast. That can be true in ideal conditions. But content websites live in real conditions: slow networks, low-power phones, distracted users, and frequent back/forward navigation.

MPA + HTML-first designs have a different performance profile:

  • The browser has something meaningful to display immediately.
  • Cache behavior is simpler.
  • Page loads are stateless and consistent across sessions.

Practical guidance when reviewing an existing SPA content site:

  • Measure time to first contentful paint and time to interactive, not just route transitions.
  • Check whether content is available in the initial HTML response or only after hydration.
  • Validate that your pages have meaningful metadata and structured headings before client code runs.
  • Test with JavaScript disabled. If the page collapses into an error state, you’ve built a fragile system.

A sharp rule of thumb: if the page is primarily consumed as a document, make the server deliver the document.

The cost of the SPA era—and why the “default” is changing⌗

The SPA wasn’t a mistake because SPAs are “bad.” They’re bad as a default architecture for everything.

The industry conflated “single-page feel” with “better user experience,” then standardized tooling around client-first rendering. Over time, teams accumulated complexity to fix the shortcomings: SSR, pre-rendering, client routing workarounds, SEO adapters, and accessibility patches. You could keep going, but you were treating symptoms instead of questioning the underlying assumption.

Now the assumptions are being challenged:

  • Content should be delivered as HTML first.
  • Interactivity should be added where it provides value.
  • Framework choice should follow product needs, not fashion.

And crucially, we have better options than we did a decade ago. Astro, server-rendered frameworks, and htmx prove that you can build modern experiences without forcing every page into an SPA mold.

Conclusion: Build like the web still matters⌗

The SPA for content websites didn’t fail because developers lacked talent—it failed because the architecture was misaligned with what content websites actually are. The web is at its best when it ships documents efficiently, lets users navigate naturally, and makes accessibility and SEO the default outcome rather than the result of heroic engineering.

Multi-page apps with progressive enhancement aren’t a trend. They’re the correction: HTML-first delivery, interactive enhancements on demand, and a cleaner, more resilient foundation for every blog, doc site, marketing page, and storefront that wants to be fast and readable everywhere.