Written for Svelte 5 (stable release October 2024), compared against React 19 (stable release December 2024). Svelte 5 introduced the runes-based reactivity model, a meaningful change from Svelte 4’s purely compiler-driven reactivity, and the mechanism described below is Svelte 5’s. Current versions as of September 25, 2026:React 19.3 (released September 9, 2026) and Svelte 5.57.
Most articles about Svelte hand you a number and stop. “40% smaller bundles.” “Faster updates than React.” Nobody explains why that number exists, or whether it will show up in the app you are actually building, so you’re left with a benchmark you cannot apply.
This article works the other direction. First, the mechanism: what Svelte’s compiler emits at build time and what React’s virtual DOM does at runtime. Then the implication: which kinds of applications feel that difference, and which kinds never will.
Svelte’s speed comes from moving work out of the browser and into the build step, and that advantage is real for update-heavy, bandwidth-sensitive interfaces while shrinking to near zero for apps bottlenecked by network calls or database queries. Knowing which category your product falls into is what turns a benchmark into a decision.
Table of contents:
- Why Svelte can do less work in the browser
- How does Svelte vs. React performance compare?
- Where Svelte’s advantages hold up at scale
- How to measure and improve a Svelte application
- Frequently asked questions
- Choosing a framework based on the work your product must do
Why Svelte can do less work in the browser
Svelte does less work in the browser because its compiler already figured out, at build time, exactly which DOM nodes depend on which values. React figures that out fresh on every state change, while the app is running.
That single difference in when the work happens is the root of nearly every Svelte performance claim you have read.
What the compiler emits instead of a virtual DOM Diff
Here is what React does when state changes inside a component:
- It calls your component function again, from the top.
- That call returns a new tree of plain JavaScript objects (the virtual DOM).
- React walks the new tree against the previous one, node by node, comparing props and children.
- Wherever it finds a difference, it issues a real DOM operation.
Steps 1 through 3 are pure overhead: no pixel updates on screen during any of them. They exist purely so React can find out what’s different. That discovery cost scales with how much of your tree re-rendered, not with how much the user actually sees change.
Svelte’s compiler skips discovery entirely. It reads your .svelte file, builds a dependency graph linking each reactive value to the exact places it appears in the template, and emits imperative JavaScript that touches those places directly.
The compiled output is the key thing to understand. Here is one small component, written once for each framework, and what each compiler turns it into.
What you write in Svelte:
<script>
let count = $state(0);
let doubled = $derived(count * 2);
</script>
<button onclick={() => count++}>Clicks: {count}</button>
<p>Doubled: {doubled}</p>What the Svelte 5.57 compiler emits:
var root = $.from_html(`<button> </button> <p> </p>`, 1);
export default function Counter($$anchor) {
let count = $.state(0);
let doubled = $.derived(() => $.get(count) * 2);
var fragment = root();
var button = $.first_child(fragment);
var text = $.only_child(button);
var p = $.sibling(button, 2);
var text_1 = $.only_child(p);
$.template_effect(() => {
$.set_text(text, `Clicks: ${$.get(count) ?? ''}`);
$.set_text(text_1, `Doubled: ${$.get(doubled) ?? ''}`);
});
$.delegated('click', button, () => $.update(count));
.append($anchor, fragment);
}The same component in React, and what the JSX compiler emits:
export default function Counter() {
const [count, setCount] = useState(0);
const doubled = count * 2;
return (
<>
<button onClick={() => setCount(count + 1)}>Clicks: {count}</button>
<p>Doubled: {doubled}</p>
</>
);
}
function Counter() {
const [count, setCount] = useState(0);
const doubled = count * 2;
return jsxs(Fragment, { children: [
jsxs("button", { onClick: () => setCount(count + 1), children: ["Clicks: ", count] }),
jsxs("p", { children: ["Doubled: ", doubled] })
] });
}Read the Svelte output above. The markup becomes a static HTML string that is cloned once. The compiler keeps direct references to the two text nodes, and a template effect calls $.set_text on exactly those nodes when count or doubled changes. No tree and no diff.
The React output is a function that returns a description of the UI. Every setCount call runs it again, builds a fresh element tree, and hands it to React’s reconciler to work out which two text nodes changed.
This is how Svelte describes itself in its own GitHub README: it is “a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM.” “Surgically” means something concrete: a compiled $.set_text call that writes to one text node, and only when that node’s value has actually changed.
How fine-grained reactivity produces surgical DOM updates
Svelte 5’s runes make dependency tracking explicit in your code, and the compiler plus runtime uses that graph to route updates.
The three you will use constantly:
- $state(…) marks a value as reactive. Reads of it get tracked.
- $derived(…) computes a value from other reactive values. It re-runs only when one of its dependencies changes.
- $effect(…) runs side effects when its tracked dependencies change.
When a $state value changes, Svelte 5 notifies only the subscribers that read that value. A text node bound to count updates. A sibling paragraph bound to name does not. The component function does not re-run.
React’s default is the opposite. Calling setCount re-runs the entire component function body, including every calculation inside it, then re-renders children unless they are memoized. This is why useMemo, useCallback, and React.memo exist. They are opt-in tools to stop work that React would otherwise do by default.
Svelte 4 was coarser than this. As the Svelte team wrote when announcing Svelte 5, changing one property of a reactive object in Svelte 4 invalidated the entire object, “because that’s all the compiler can realistically do.” Signals-based frameworks had passed Svelte on that axis. Runes closed the gap by making the dependency graph runtime-visible instead of purely compile-time-inferred.
“Fine-grained” at the code level means the unit of invalidation is a single value, not a component.
The version note and claims that need live verification
Any specific number in a framework comparison has a shelf life measured in months, because both frameworks ship changes that move the numbers.
Here is a current snapshot from js-framework-benchmark, checked September 25, 2026, using results committed September 20, 2026. The benchmark tests Svelte 5.42.1 and React 19.2, a few releases behind the current versions, so verify the live numbers before quoting them.
| Measure | Svelte 5.42.1 | React 19.2 | React 19.0 + React Compiler |
| Create 10,000 rows | 231 ms | 389 ms | 428 ms |
| Memory after adding 1,000 rows | 2.9 MB | 4.4 MB | 4.6 MB |
| Compressed size of the benchmark app (brotli) | 9.7 KB | 51.4 KB | 50.0 KB |
Figures are medians of the recorded runs in the project’s published results data.
Treat these three claims as things to re-check rather than facts to memorize:
| Claim type | Why it goes stale | Where to verify |
| “Svelte is X% faster” | Both frameworks release optimizations continuously | js-framework-benchmark live results |
| “React re-renders everything” | React Compiler adds automatic memoization | React’s official compiler docs |
| “Svelte bundles are smaller” | Depends heavily on your dependency tree, not just the framework | Your own vite build output |
The mechanism explanations above don’t expire: they describe what the compiler does, not how much faster that makes it this quarter. The percentages do expire, because both frameworks keep shipping optimizations that move them.
How Svelte’s rendering model compares with React’s
Svelte wins on the work it avoids doing at runtime, and React has closed part of that gap by adding compiler-driven memoization of its own.
The honest comparison is narrower than most benchmark headlines suggest, and it depends on which stage of the render pipeline you look at.
For the wider decision, including hiring, team size, and how long the app needs to live, see our Svelte vs React comparison.
Compiler and rendering models, stage by stage
| Stage | Svelte 5 | React 19 |
| Component analysis | Build time. Compiler maps reactive values to DOM targets. | Runtime. Component function runs on every update. |
| Shipped runtime | Small reactivity runtime plus compiled per-component code | React DOM library plus your component code |
| What ships to browser | A cloned HTML template plus effects that write to specific nodes | Render functions returning element descriptors |
| Change detection | Signal-style dependency tracking per value | Re-render, then virtual DOM diff |
| DOM write path | Direct call to the affected node | Reconciler patches after comparison |
| Optimization work required | Rarely needed; granularity is the default | useMemo / React.memo, or React Compiler |
| Initial mount | Clones a static template, then attaches effects | Reconciler mounts the full tree |
The row that matters most in practice is the last-but-one. In Svelte, you get fine-grained updates for free. In React, you either accept broad re-renders or you add memoization by hand.
How React Compiler changes the comparison
React Compiler is React’s answer to that criticism. It analyzes your components at build time and inserts memoization automatically, so you no longer have to write useMemo and useCallback. It has reached stable 1.0 status, so it is no longer an experimental bet for teams evaluating whether to adopt it.
That matters for the comparison in two ways:
- It removes a real source of accidental slowness in React apps: the missing memo that causes a large subtree to re-render on every keystroke. Teams that never got memoization right will see the biggest improvement.
- It does not remove the virtual DOM. React Compiler reduces how often a component function re-runs. When one does run, React still builds a new element tree and diffs it. Svelte’s compiled update statement skips both.
What reproducible benchmarks can and cannot show
The js-framework-benchmark project is the reference worth reading, because it is open, reproducible, and rerun against current framework releases rather than published once and abandoned.
It measures three families of things:
- DOM operation speed: creating 1,000 rows, replacing all rows, swapping two rows, selecting a row, appending to a large list, clearing rows
- Memory use: heap size after load, after adding 1,000 rows, and after repeated update cycles
- Bundle size: transferred and uncompressed weight of the framework plus benchmark app
Its published results consistently place Svelte in the faster group and React in a slower group on the geometric mean of DOM operations, with Svelte’s memory footprint lower after 1,000-row creation. The exact multipliers change between runs and framework versions, so read the current results page for figures instead of quoting any article’s snapshot, including this one.
Here is the limit that benchmark authors state themselves and most comparison posts ignore: swapping rows in a 1,000-row table is not your application. A synthetic benchmark isolates framework overhead by removing everything else, which is precisely why it cannot predict how a real app with API calls, auth, images, and third-party scripts will behave.
Framework choice is one input among many into real-world performance, alongside dependency management, backend integration, and build configuration, and for most production apps it is not the largest one.
Where Svelte’s advantages hold up at scale
Svelte’s advantage holds up where the browser does frequent, small DOM work and where bytes over the wire are expensive. It fades where the bottleneck sits outside the rendering layer.
Update-heavy interfaces and high-frequency state changes
Interfaces that update many times per second are where compiled fine-grained updates pay off most.
Concrete cases:
- Trading dashboards with streaming price ticks
- Collaborative editors syncing keystrokes across users
- Canvas or SVG visualizations driven by animation frames
- Live log viewers and monitoring panels
- Forms with cross-field validation firing on every input
The reason is arithmetic, not ideology. A dashboard updating 200 values 10 times per second gives React 2,000 chances per second to re-run component functions and diff trees. Svelte’s compiled output does 2,000 targeted node writes. Both are fast for one update; the gap compounds under load.
There is a real caveat here. A React app with correct memoization, or React Compiler doing it for you, narrows this substantially. The difference is that Svelte gets the granular behavior without you thinking about it.
Initial load, bundle size, and hydration cost
Because Svelte compiles most component logic into your bundle instead of shipping a reconciler to interpret it, its framework baseline is smaller, which lowers both download and parse cost on first load.
That matters in specific conditions:
- Mobile users on 3G or congested networks, where every kilobyte of JavaScript adds parse and execute time on a slow CPU
- Markets where data is metered and expensive
- Content sites where Core Web Vitals affect search visibility
- Embedded webviews inside native apps with tight memory budgets
Hydration cost follows the same logic. SvelteKit’s hydration attaches the compiled update functions to server-rendered markup. React’s hydration walks the tree to reconcile the client render against the server HTML.
SvelteKit also ships load-time optimizations by default, including code-splitting so only the current page’s code loads, asset preloading to prevent request waterfalls, and file hashing for permanent caching, per SvelteKit’s performance documentation. React’s equivalents exist through Next.js and similar frameworks, so this is a framework-level comparison, not a compiler one.
These defaults are documented for the current SvelteKit 2 line. SvelteKit 3 has been in release candidate since August 2026, so re-check the performance docs after you upgrade.
Large lists, memory pressure, and expensive application work
This is where the compiler advantage narrows, and being honest about it is more useful than another benchmark chart.
Very large lists converge. Rendering 50,000 rows is a DOM node count problem before it is a framework problem. Both Svelte and React solve it the same way: virtualize the list so you only render the visible window. Once you virtualize, you render 30 rows in both frameworks, and diffing overhead stops being the bottleneck.
Reconciliation-heavy trees converge too. Deeply nested UIs where large sections restructure at once give Svelte less to be surgical about. Recreating a subtree means creating nodes in both frameworks.
Network- and I/O-bound apps see almost nothing. A content site waiting 400ms on a CMS API, or a dashboard waiting on a slow database query, will not get measurably faster from switching frameworks. The rendering layer is idle during that wait. Fix the query, add caching, or move to a rendering strategy that serves cached HTML.
Our guide to wiring a headless CMS into SvelteKit covers choosing a rendering mode for each route and caching at the edge.
Expensive application logic dominates. If a component runs a heavy data transform or parses a large JSON payload, that cost is identical in both frameworks. Svelte doesn’t make your code faster.
If you are weighing a React app against a Svelte rewrite, get data before committing. A practical workflow: use an AI coding assistant to scan your React codebase for components that re-render on every parent update without memoization, have it flag the ten worst offenders by render frequency, then measure those specific components with React DevTools Profiler.
Often you find that adding memoization or fixing a state-lifting mistake recovers most of the gap, which changes the rewrite math considerably. If the math still points to Svelte, the harder part is usually staffing it; our roundup of where to find vetted Svelte developers covers what to screen for beyond framework familiarity.
How to measure and improve a Svelte application
Measure your own production build against real network conditions, because framework-level benchmarks tell you almost nothing about the app you shipped.
Test production builds instead of development mode
Development builds are slower on purpose. Vite serves unbundled modules, Svelte includes dev-mode warnings, and hot module replacement adds bookkeeping. Numbers from npm run dev are meaningless for performance work.
Do this instead:
- Run your production build (vite build or npm run build).
- Serve it with vite preview or your real hosting setup.
- Open Chrome DevTools, throttle to Slow 4G and 4x CPU slowdown.
- Record a Lighthouse run and a Performance trace.
- Repeat after each change so you know what moved the number.
CPU throttling matters more than most teams expect. Mobile CPUs are still meaningfully slower than desktop hardware at parsing and executing JavaScript, even on recent devices, which is exactly where bundle size turns into visible delay.
Profile rendering, network requests, and long tasks
Find the bottleneck before you optimize anything. The DevTools Performance panel splits your trace into scripting, rendering, and painting time, plus a network waterfall.
What to look for:
- Long tasks over 50ms blocking the main thread and delaying input response
- Request waterfalls, sequential requests where each waits on the previous one. SvelteKit’s docs call these “one of the biggest performance killers” and recommend restructuring so requests fire in parallel
- Layout thrashing from code that reads a layout property then writes to the DOM in a loop
- Excessive $effect runs, usually from an effect depending on a value that changes more often than intended
For update-level visibility, svelte-render-scan gives you a visual overlay showing when and where DOM updates fire in a Svelte or SvelteKit app, which makes over-broad reactivity easy to spot.
Optimize images, fonts, dependencies, and data loading
In most Svelte apps, the biggest wins sit outside the framework. Work through them in rough order of payoff.
Images. Reducing image file size is often the single most impactful change you can make to a site’s performance, and Svelte ships @sveltejs/enhanced-img to handle format conversion and responsive sizing, per its performance guidance. Serve WebP or AVIF, set explicit dimensions, and lazy-load anything below the fold.
Dependencies. Run a bundle visualizer on your build output. A single date library or icon set imported wholesale can outweigh the entire Svelte runtime. Prefer per-function imports and drop anything you can write in twenty lines.
Fonts. Subset to the characters you use, self-host, and use font-display: swap.
Data loading. Move fetches into SvelteKit load functions so they start on the server, run them in parallel, and stream slower data with promises so the page renders without waiting for everything.
Consult Svelte’s best practices documentation for the current recommended patterns, since guidance shifts across 5.x releases.
Frequently asked questions
Is Svelte faster than React?
For update-heavy interfaces, yes, and the reason is mechanical, not just a benchmark result. Svelte’s compiler emits targeted DOM update instructions at build time, so a state change touches only the specific node tied to it. React re-runs the whole component function on state change and diffs a virtual tree to figure out what moved. For apps bottlenecked by network calls, database queries, or heavy application logic rather than rendering, the difference shrinks to nearly nothing, since neither framework’s rendering speed is the thing you’re waiting on.
Why doesn’t Svelte use a virtual DOM?
Because Svelte’s compiler already knows, at build time, which DOM nodes depend on which reactive values. A virtual DOM exists to solve a problem Svelte doesn’t have: figuring out what changed at runtime. React needs that discovery step because it doesn’t know in advance what a re-render will produce. Svelte’s compiler does that analysis once during the build and generates direct DOM-update code instead.
Does React Compiler make React as fast as Svelte?
It closes part of the gap, not all of it. React Compiler automatically adds the memoization developers used to write by hand, which removes a common source of unnecessary re-renders. But it doesn’t remove the virtual DOM: when a component does re-render, React still builds a new element tree and diffs it. Svelte’s compiled output skips that step entirely, so the two aren’t doing equivalent work even when React Compiler is doing its job well.
Does Svelte’s performance advantage matter for large applications?
It depends on what “large” means for that app. For large, update-heavy applications, like trading dashboards or collaborative editors, the advantage compounds and matters more as scale increases. For applications with very large lists, both frameworks converge on the same solution (virtualizing the list), so the compiler advantage stops being the bottleneck. And for applications bottlenecked by API latency or database queries rather than rendering, framework choice barely moves the needle regardless of size.
Are Svelte vs. React benchmarks realistic for real applications?
Only partially. Reproducible benchmarks like js-framework-benchmark isolate framework overhead by stripping out everything else, which is exactly why they’re useful for comparing frameworks and exactly why they can’t predict your app’s real-world performance. A real application has API calls, authentication, images, and third-party scripts competing for the same resources. Framework choice is one input into real-world performance, alongside dependency management, backend integration, and build configuration, and it’s often not the largest one.
Choosing a framework based on the work your product must do
Svelte’s performance story rests on a specific, checkable mechanism: the compiler analyzes each component at build time and emits code that clones a static template and updates individual DOM nodes tied to specific reactive values, so the browser never builds a virtual tree or runs a diff. Svelte 5’s runes make that dependency graph explicit through $state, $derived, and $effect, so a change to one value touches one DOM node.
That mechanism produces a durable advantage in two situations: interfaces that update frequently, and users on slow networks or slow devices where bundle size becomes parse time.
It narrows or disappears in others. Both frameworks virtualize large lists. Reconciliation-heavy restructuring gives the compiler less to optimize. Apps waiting on APIs or databases are not rendering-bound at all. React Compiler’s automatic memoization has closed part of the historical gap, even though React still diffs when a component does re-render.
So the useful question is what work your product does. Streaming dashboards, editors, and visualizations favor Svelte’s model. A content site bottlenecked by a 400ms CMS response should fix caching and rendering strategy before touching frameworks. Check any specific number, including the ones above, against the current js-framework-benchmark results and your own vite build output rather than trusting a published snapshot.
If your team is deciding whether Svelte’s performance model matters for what you are building, or you have already decided and need it built right, you need engineers who understand where that advantage is real and where it is not.
Arc pre-vets Svelte developers for domain expertise and English fluency before you see a profile. HireAI matches your requirements against a pool of vetted candidates and returns a shortlist in minutes, not weeks.
