Your SPA Is a 7x Mobile Performance Tax

You spent six months perfecting that React checkout flow. Client-side routing, optimistic UI updates, a state management pattern that would make Dan Abramov weep with joy. Then you tested it on a real 4G network with a $200 Android phone.

The cart page took 11 seconds to become interactive.

Here’s the part that hurts: a plain HTML page with a sprinkle of JavaScript would have loaded in under 2 seconds. Your “modern” architecture is charging your users a 7x performance tax they never agreed to. And the worst part? You knew. Somewhere in the back of your mind, you knew that shipping 400KB of JavaScript to render a product description was absurd. But the industry told you this was the way. The conference talks, the job postings, the framework wars—they all whispered the same lie: single-page applications are the future.

The future is slow. And it’s costing you real money.

The Metrics Nobody Talks About

The surface-level assumption is simple: SPAs provide a better user experience. Smooth transitions, instant navigation, app-like feel. This was true in 2018. It’s dangerously wrong in 2025.

Real production data tells a different story. On 4G networks, server-rendered HTML with islands of interactivity achieves a Time to Interactive of under 3 seconds on 90% of e-commerce checkouts. Client-side rendered React? Over 8 seconds for the same metric. That’s not a marginal difference. That’s the difference between a user completing a purchase and them rage-quitting to Amazon.

Blockquote time: “The median e-commerce SPA ships 1.2MB of JavaScript before first paint. The median server-rendered alternative ships 180KB.”

The juxtaposition is brutal: we built faster phones, faster networks, faster frameworks—and somehow made the web slower. Every abstraction layer we added for developer experience became a tax on user experience.

The Market Already Voted

You know what’s interesting? The companies with the most to lose—Shopify, Gumroad, Substack—have quietly been moving back to server-rendered architectures. Not because it’s trendy. Because their conversion data screamed at them.

Here’s what the market discovered:

  • Every 100ms of load time drops conversion by 1%
  • Every second of TTI on mobile costs 20% in revenue
  • Users abandon carts at 3x the rate on SPA checkouts vs server-rendered ones

The numbers are brutal. But the emotional reality is worse: you’ve been shipping slow apps for years, convincing yourself hydration was fine, that code splitting solved everything, that your users would wait. They didn’t wait. They just left.

The smart money is already gone. They’re not building SPAs for checkout flows anymore. They’re building server-rendered HTML with targeted JavaScript islands—small, scoped interactions that enhance without destroying performance.

The Blindspot Developers Refuse to See

Why does everyone keep building SPAs? Because it’s comfortable. Because the tooling is amazing. Because hot module replacement feels like magic. Because rewriting your entire architecture around server rendering sounds like a nightmare.

But here’s the uncomfortable truth: you’re optimizing for your own productivity, not your users’ experience.

The industry blindspot is ego disguised as engineering excellence. We convinced ourselves that complex state management, client-side caching, and optimistic updates were signs of sophistication. They’re not. They’re workarounds for a fundamental architectural mistake: trying to make the browser do things the server was always better at.

Checkout flows are not apps. They’re forms. They’re sequential steps with validation, payment processing, and confirmation. The server needs to be involved in every step anyway. So why are you shipping a JavaScript framework to manage state that the server already knows?

The Only Architecture That Makes Sense in 2025

The forward path is clear but painful to accept: you need to burn the SPA.

Not everywhere. Not for everything. But for e-commerce, content sites, and anything where page load speed correlates with revenue, the answer is server-rendered HTML with islands of interactivity. Think of it as progressive enhancement finally getting its revenge.

What this looks like in practice:

  • Server renders the full HTML for each page
  • Small JavaScript components hydrate independently
  • Navigation uses native browser navigation (gasp)
  • Forms submit to endpoints, not APIs
  • The “app” weighs 50KB, not 500KB

This isn’t a regression. It’s recovery. We spent a decade making the web slow by pretending it should work like native apps. The pendulum is swinging back, and this time it’s swinging with the weight of real performance data behind it.

So What Should You Actually Do?

Here’s the insight that keeps me up at night: we built an entire generation of tools and frameworks on a bad assumption. We assumed the client should do more work. We were wrong.

The web is fast by default. It’s our frameworks that make it slow. Every abstraction layer, every JavaScript bundle, every client-side router—they’re all performance taxes dressed up as engineering progress. Your users don’t care about your dev experience. They care about whether they can buy something before the train arrives at their station.

The Uncomfortable Truth

Stop building SPAs for content. Stop pretending your checkout flow needs client-side routing. Stop measuring your performance in a dev environment and start measuring it on a real 4G network with a mid-range phone.

The architecture you choose is a statement about who matters more: you or your users. Server-rendered HTML with islands of interactivity isn’t a compromise. It’s a return to sanity. The web was always fast. We just forgot how to let it be.

Your users are waiting. Literally.