Svelte vs React, and What It Took to Make an App Feel Instant

Before moving a data-heavy admin application off React, I built the same heavy feature three times, in React 19, Svelte 5 and SolidJS, and measured all three through one harness against a rubric I froze before seeing any results. Svelte won. Then I spent months making the resulting app fast, and discovered that almost everything I had assumed about where the time was going was wrong.

Why we left React

The application before was React and Next.js, and it was not broken. Three arguments made the move worth testing:

• Svelte compiles the framework away. There is no virtual DOM shipped to the browser and no reconciliation happening at runtime. What arrives is closer to the DOM operations you would have written by hand. When your target is sub-100 ms navigation, starting with less runtime work is a structural advantage rather than a micro-optimisation.
• The design language survived the move. A shadcn-for-Svelte port meant we kept the same component and design system we had under React. Nothing was lost on the UI side, which removed the usual argument against migrating.
• Runes are a better foundation for what we needed. Svelte 5's $state and $derived give fine-grained signal reactivity, and the client-side caching and optimistic-update layers described below are built directly on top of that. In a coarser reactivity model those layers are harder to keep correct.

The controlled bake-off: React 19 vs Svelte 5 vs SolidJS

Before committing to the migration I ran a controlled bake-off, because "which framework is fastest" is usually answered with a to-do-list demo on a fast laptop and I did not want to make an expensive decision on vibes.

The setup: one realistic heavy feature, an authenticated Customer-360 workbench with a virtualised 20,000-row grid, debounced server-side search, faceted filters, optimistic inline edit with a deliberately server-rejected rollback, a cross-service detail panel, and a live server-sent-event invalidation bus, implemented three times, in React 19, Svelte 5 and SolidJS. Same backend, same 20k seed data, same design tokens, same harness, same pinned browser at a fixed viewport on one machine. Solid was included as a near-vanilla-JS runtime upper bound rather than as a serious hiring candidate.

The fairness controls

A bake-off is only worth as much as its controls, and these were the load-bearing ones:

• Equal DOM, asserted before timing. Steady-state node count, overscan and keying were checked equal across variants first, otherwise the test measures grid libraries, not frameworks.
• The rubric was frozen before any numbers existed. Runtime 40%, maintainability and hireability 25%, build and CI 20%, design and accessibility 15%. No result could retroactively reshape the criteria.
• Time-to-interactive measured post-authentication, so the login round trip never contaminated the runtime figure.
• A fixed-latency mock backend for the speed board to remove database jitter, with a separate read-only pass against the real backends to prove writes never bypassed them.
• Four CPU-throttle tiers, cold and warm reported separately, repeats with median, p75 and p95, because fast machines hide exactly the gap you are trying to measure.

Time to interactive, by CPU throttle

Svelte 5 React 19 SolidJS

The gap opens under load. React and Svelte are indistinguishable at 1×, and 277 ms apart at 6×. Solid climbs off the top of the field at every tier.

Bundle and memory

Where nothing separated them

Worth reporting the null result too. Steady-state interaction was excellent in all three: interaction p75 around 16 ms and roughly 60 FPS scrolling everywhere, far inside the 100 ms bar. Under throttle Svelte held the fewest long frames and the fastest view switches, but the honest summary is that once loaded, all three feel fine. The separation is in getting loaded, and in behaviour under CPU pressure.

The verdict, and what it does not mean

Svelte 5 won the frozen rubric, ahead on runtime under throttle, comfortably inside the bundle budget, and idiomatic enough that the React architecture ported over without harness changes, while remaining a mainstream and hireable choice in a way Solid is not. React held its own at light load and passed every interaction bar; this is not a claim that React is bad.

Solid's poor showing deserves a qualifier, which I have put in the caveats at the end. The durable findings here are the directions rather than the absolute milliseconds: Svelte degrades more gracefully under CPU pressure, ships meaningfully less JavaScript, and Solid pays for its small bundle in memory.

One more thing the bake-off surfaced, which turned out to matter more than the framework choice: the biggest wins came from architecture applied identically to every variant. Menus opening from already-loaded state instead of fetching on open, modules code-split and prefetched on hover through a single-flight loader, visited modules staying mounted so a view switch is a one-frame visibility flip rather than a re-virtualisation, and entitlement enforced structurally so a restricted module has no reachable import() at all. With that layer in place, every shell control resolved under 35 ms p75 at both 1× and 6× CPU, in both React and Svelte. The throttle barely moved those numbers, which is the signature of painting from state you already hold.

So: the framework sets the floor, the architecture decides where you land. The rest of this article is that architecture, measured on the SvelteKit application we ended up with. The harness and the raw tables are reproducible if you want to argue with the numbers.

How I measured

Every number here came from a Playwright harness driving headless Chromium through real navigation and reading timings off the page, not from a synthetic microbenchmark.

• Injected latency. A round-trip-time variable set to 0, 230 or 300 ms, combined with Chrome DevTools Protocol throttling at 25 Mbit and 8 Mbit, covering everything from localhost to a bad cross-continent connection.
• Three regimes measured separately. Cold hard load, warm client-side navigation, and revisiting an already-loaded route. They behave completely differently and averaging them hides the interesting parts.
• Instruments. Performance-timing deltas from navigation to first rendered card, node counts via querySelectorAll, long-task and main-thread timing, and a heap sampler.
• Compressed sizes. All payload figures are brotli or gzip, what actually crosses the wire, not raw JSON size.

Payload size was not the bottleneck on this route

The obvious suspect was payload size. The heaviest view serialised about 900 records into 435 KB, which felt indefensible. So I trimmed it to 18 KB and measured both under identical conditions.

A deliberately empty server render

SvelteKit's load in +page.server.ts is the standard place to fetch data, but we do the opposite of the standard thing: the server load returns nulls and ships no heavy data in the SSR document at all.

What goes out is a 4.3 KB brotli shell with a 29 ms TTFB. The skeleton paints at 153 ms, and the real data is fetched client-side immediately afterwards. Server-side rendering stays on, but it is skeleton-driven: a hard reload paints structure rather than a blank page, and client-side navigation never shows a skeleton at all because the data is usually already cached. For routes where even a reload skeleton was unwanted, ssr=false was available per route.

Client-side caching: the instant-revisit win

If round trips are the enemy, the largest available lever is never making the same one twice. Returning to a route now serves from an in-memory cache seeded from IndexedDB, and the blocking re-fetch is simply gone.

The cache is scope-keyed snapshots persisted to localStorage and IndexedDB with a five-minute TTL. There is a race guard: each hydrate bumps a request counter and nulls the in-flight handle, so a slow older response cannot overwrite a newer one, the same stale-response bug that shows up in every debounced autocomplete ever written, just at a different scale. Navigation intent is anticipated with prefetch-on-hover, and writes are optimistic: a status change repaints in 1–2 ms, long before the server confirms it.

Payload discipline anyway

Payload size was not the latency bottleneck, but trimming it still cut parse time, memory and transfer cost, and it was cheap to do. Two techniques, both measured:

The principle worth keeping: the server should project the shape of the view, not the shape of the database.

DOM volume is the real cost

Once data arrived instantly, what remained was pure rendering, and this is where the second surprise showed up. A full board mounted 20,769 DOM nodes, which is a roughly 2,000 ms main-thread task on its own. Not a reactive-effect loop, not a framework inefficiency. Just node volume. No framework saves you from this.

The fix was virtualisation plus per-column lazy rendering: render the first page in each column and defer the rest.

Why a BFF makes aggressive caching safe

The frontend never talks to a database. Every data path runs through a backend-for-frontend layer: the SvelteKit app calls its own /api/* routes, which proxy to a backend service that owns the PostgreSQL access. No ORM lives in the frontend. A separate mail surface speaks JMAP through its own BFF, selecting per-account credentials from a request header so no secret ever reaches the client.

Field projection, caching hints and rate limiting all live at the BFF, which is both the single source of truth and the security boundary. That is what keeps credentials and database access off the client entirely. It does not, by itself, make cached customer data safe: anything sitting in IndexedDB is still exposed to cross-site scripting, to shared devices, and to stale authorisation if logout does not clear it. So the cached fields are minimised and scope-keyed, they expire after five minutes, and they are purged on logout and on any authorisation change.

Takeaways

• Measure before optimising. The obvious culprit was wrong. 18 KB and 435 KB behaved identically under latency, and I would have spent weeks on serialisation otherwise.
• Round trips dominate. On real networks, RTT and blocking re-fetches set the ceiling. Removing the second fetch was worth roughly 550 ms on revisit; shrinking the first was worth about 150 ms on a cold load.
• Keep SSR thin. A near-empty 4.3 KB document plus a skeleton plus a client hydrate beat shipping data inside the HTML.
• DOM volume is a real, framework-independent cost. Twenty thousand nodes is a two-second task in anything. Virtualization is mandatory at scale.
• Project the view, not the table. A 5.4× payload cut with an identical render, for very little work.
• Benchmark under throttle, not on your laptop. React and Svelte were indistinguishable unthrottled and 277 ms apart at 6×. A fast machine would have told me the choice did not matter.
• The framework sets the floor; architecture decides the outcome. Svelte gave us a lower baseline and a reactivity model that made the caching layer straightforward. But the instant-UI layer hit under 35 ms p75 in React too, so the framework did not make the app fast on its own.

Caveats

Frequently asked questions