SPA vs. Hypermedia: Real-World Performance Under Load

Measured February 2026, again in October 2026 · Lighthouse + Chrome DevTools Performance Profiling · View source & raw data →

Methodology: The Vercel Reference App as Baseline

We compared our own PHP/Datastar hypermedia implementation against the Vercel AI SDK Chatbot, Vercel’s reference implementation of an AI chat on Next.js, with around 80 contributors.

Both applications implement the same core features: real-time AI streaming, chat history, document artifacts, and authentication. Test conditions were identical: Chromium 154 with Lighthouse 13.5 in October (Chrome 144 in February), Slow 4G network simulation (1.6 Mbps, 150 ms RTT), and 4× CPU throttling to simulate mid-range mobile devices. Lighthouse figures are the median of three runs.

Lighthouse Scores: The Mobile Gap

On desktop with fast connections, both architectures perform reasonably well. The real differences emerge under constrained conditions, precisely the environment where most of the world’s users operate.

Desktop (Unthrottled)

Mobile (Slow 4G + 4× CPU Throttling)

This is where architectural choices become visible. The JavaScript bundle that’s barely noticeable on a fast desktop connection becomes a critical bottleneck when the network is slow and the CPU is constrained.

The SPA’s Total Blocking Time of 898 ms vs 0 ms means the main thread is blocked for nearly a full second just parsing and executing JavaScript: time during which the page is visually present but completely unresponsive to input. The hypermedia version eliminates blocking entirely: its server-rendered HTML is immediately usable the moment it arrives.

What Gets Sent Over the Wire

The 27× reduction in transferred bytes directly translates to faster loads on slow networks. On a 1.6 Mbps connection, downloading 1.4 MB takes about 7 seconds before the browser can even begin parsing. 51.8 KB takes about a quarter of a second.

Visual Proof: Where the CPU Time Goes

Performance profiling during actual page loads and chat interactions reveals how each architecture uses CPU resources. The flamegraphs below show Chrome DevTools Performance traces under identical conditions: Slow 4G network throttling and 4× CPU slowdown. This section shows the February run.

• Scripting: JavaScript execution
• Rendering: Style/layout calculation
• Painting: Pixels to screen
• System: Browser internals
• Loading: Network activity
• Idle: Available for user input
• Memory: JS heap (bottom graph)

Page Load Comparison

Drag the slider to compare SPA (left) vs Hypermedia (right)

The key visual difference in the flamegraphs: the SPA shows tall, dense stacks of JavaScript execution (yellow blocks) that dominate the trace. Hypermedia’s flamegraph is shallow and sparse: most of the time is spent idle or in native browser rendering, not executing JavaScript. Note: Scripting Time and Main Thread Time are from different DevTools views. The Summary panel tallies all scripting across threads (including workers), while Main Thread Time is the aggregate task duration from the Activity tab. The two overlap but don’t cover identical scope, which is why Scripting can appear higher than Main Thread Time.

The higher DOM node count in Hypermedia (963 vs 326) reflects server-rendered content that’s immediately visible. The SPA starts with a minimal DOM and builds it client-side through hydration, which explains why it has 5.9× more event listeners attached despite fewer nodes.

Chat Response Comparison (Streaming)

Drag the slider to compare SPA (left) vs Hypermedia (right)

During streaming, the SPA spends over 4× more time executing JavaScript than the hypermedia version (10,500 ms vs 2,485 ms). Hypermedia compensates with more rendering and painting time, because Datastar patches the real DOM on every incoming SSE chunk rather than buffering updates in a virtual DOM. The browser’s native HTML parser does the heavy lifting, which shows up as rendering cost rather than scripting cost. Overall Hypermedia completes the full chat response cycle 37% faster (12,500 ms vs 19,686 ms).

¹ V8 Node Allocs counts all nodes in the V8 heap, attached and detached (pending GC). Datastar replaces DOM patches on each SSE event, creating orphaned nodes that accumulate until garbage-collected; the live DOM after streaming completes is ~400 to 600 nodes. React reconciles mostly in-place, so far fewer detached nodes accumulate (+428 vs +31,395). This metric reflects GC pressure, not live DOM size.

Streaming Efficiency: SSE Compression

Real-time AI chat relies on Server-Sent Events (SSE) for token-by-token streaming. The two architectures differ not just in compression, but in the fundamental connection model: Hypermedia keeps a single persistent SSE stream open for the whole session, while the SPA opens a new streaming POST for every message turn. That difference compounds dramatically over a conversation: after 10 turns, Brotli on a persistent stream achieves a 58.5× compression ratio, turning a 29× raw-data disadvantage into a 2× transferred-data advantage. The figures in this section are from the February run.

Single Turn (Claude 4.5 Haiku, same prompt)

Multi-Turn Conversation (10 turns, identical prompts)

58.5× Brotli compression ratio after 10 turns on a persistent SSE stream

Worth being honest about what our PHP implementation did in February: every time the AI output a new word, it re-streamed the entire message HTML fragment from scratch, not just the new token. Each chunk replaced the previous one in full. That was a deliberate simplicity choice, not a Datastar requirement: write the naive thing until you have a reason not to. It explains the 29× raw data gap. Despite that self-imposed inefficiency, the combination of Brotli on a persistent connection beat the SPA over 10 turns. The compression more than compensated for the naïve implementation.

Since the move to php-via, the app still sends the whole fragment, but at most 20 times a second instead of once per token. Ten turns of a 1,091-character answer now cost 34.5 KB over the wire (2.5 MB before compression); after the first turn, each further one takes about 2 KB.

The single-turn advantage (2.4×) already holds: Brotli’s 18.7× compression ratio turns a 7.8× raw-size disadvantage into a net win. The multi-turn advantage grows further: a persistent stream lets Brotli compress all turns together, exploiting the cross-turn repetition in the chat HTML that builds up as the conversation grows. After 10 turns Hypermedia transfers half the data of the SPA, even starting from an implementation that wastes 29× more bandwidth before compression.

² Next.js streaming POST responses (/chat) have no Content-Encoding header. Enabling compression middleware on the streaming route would partially close this gap, but the per-connection overhead and inability to share a Brotli dictionary across turns would remain.

Codebase & Operational Complexity

Fewer dependencies mean a smaller attack surface, simpler security audits, and fewer breaking changes to manage during upgrades. The 155× reduction in production disk usage also translates to faster CI/CD pipelines and simpler container images.

The Economics of Simplicity

Technical metrics are interesting, but what do they mean for the business? Architecture decisions compound over time, affecting not just performance but development velocity, operational costs, and team productivity.

Features vs. Maintenance: Where Does Time Go?

Consider what 592 production dependencies mean in practice. Each dependency is a potential source of security vulnerabilities that need patching, breaking changes that need addressing, and compatibility issues that need debugging. With the JavaScript ecosystem’s rapid release cycles, a significant portion of development time goes to keeping the dependency tree healthy rather than building features.

The Hidden Cost of Complexity

Complex architectures slow down not just the application but also the team. Every architectural layer adds cognitive load: developers must understand React’s reconciliation, Next.js’s rendering modes, the Vercel deployment model, and the interaction between client and server state. This knowledge takes time to acquire and maintain.

In contrast, a server-authoritative hypermedia architecture has one source of truth (the server), one rendering location (the server), and one deployment target (a simple process). New team members can become productive faster, and debugging follows a straightforward request-response model rather than tracing state through multiple layers.

When Simplicity Pays Off

The economic case for reduced complexity is strongest wherever time and money are finite, which is most projects. A small team without a dedicated DevOps engineer or front-end specialist simply cannot afford to babysit a 592-dependency graph. When a transitive package ships a breaking change, it isn’t an abstract inconvenience; it’s a half-day of unplanned work that displaces a feature. The leaner the dependency tree, the fewer of those interruptions accumulate.

For applications expected to live years rather than months, this dynamic becomes even more pronounced. Initial development costs are a one-time investment, but maintenance compounds indefinitely. Every major framework upgrade, every deprecated API, every shift in the JavaScript ecosystem adds to the running total. Fewer dependencies and a simpler mental model keep that cost manageable, and institutional knowledge stays relevant longer.

Hosting economics follow the same logic. Usage-based pricing can absorb a modest traffic spike and return a billing surprise that forces an architecture review you didn’t plan for. A predictable $20/year VPS doesn’t do that. The cost is known in advance, scales to the team’s budget, and keeps the focus on the product rather than on cloud spending dashboards.

Finally, there’s the audience itself. The total elimination of blocking time (0 ms vs 898 ms) and the 8.3× improvement in Time to Interactive aren’t benchmark curiosities: they determine whether a user on a mid-range phone with a patchy connection actually gets to use the product, or abandons it in the first ten seconds.

Limitations & Caveats

When to Choose What

Architecture decisions should be driven by requirements, not trends. Here’s a framework for thinking about the tradeoffs:

Many applications don’t need the complexity of a full SPA. The question isn’t “which is better” but “which tradeoffs match your constraints.”

Summary

Hypermedia wins all 9 measured categories outright.

These results don’t mean SPAs are “bad” or that every application should use hypermedia. They demonstrate that the default choice of SPA architecture carries real costs that become significant under constrained conditions, and that alternatives exist.

Raw data: GitHub repository
All benchmark data, Lighthouse reports, and Chrome DevTools traces are available for independent verification.