React vs. Svelte: The Bundle-Size Argument Server Components Change
React ships a 221 KiB react-dom runtime; Svelte compiles it away instead. Why that gap matters less once Server Components mean most of a page never hydrates.
React ships a runtime to the browser and reconciles a virtual DOM against the real one; Svelte compiles your components into direct DOM-mutation instructions at build time, so there's no framework runtime to ship at all. That difference is real and Svelte's bundles are smaller for it. It's also not the number that decides bundle weight for a marketing site built with React Server Components, where most of the tree ships zero client JavaScript regardless of which client-side framework sits underneath it — a distinction this codebase's own component split makes concrete.
The bundle-size argument, and where it stops applying
Svelte's pitch is real: a minimal Svelte app is a handful of kilobytes because there's no virtual-DOM reconciler shipped to the client — the compiler already resolved what changes when state changes, and wrote the DOM-mutation code directly. React's runtime cost is the mirror image: react-dom alone is 221 KiB raw / 70 KiB gzipped in this codebase's own production build, paid before a single line of app code runs — measured when we compared this same storefront against an Astro rebuild. If the entire page is interactive — a dashboard, a canvas app, anything where most components hold state — that gzip figure is close to the whole story, and Svelte wins it outright.
A landing page is not that case, and the reason isn't a framework trick — it's what Server Components change about which cost you're even paying.
What this codebase's own component split shows
Server Components render to HTML on the server and ship no client JavaScript for their own logic at all — not "small JavaScript," none. Client Components are the ones that opt in with "use client" because they hold state or bind an event handler. Measured across this codebase's 91 components:
| Layer | Client Components | Total | Share |
|---|---|---|---|
| Atoms | 0 | 6 | 0% |
| Molecules | 19 | 41 | 46% |
| Organisms | 5 | 33 | 15% |
| Templates | 0 | 11 | 0% |
| All | 24 | 91 | 26% |
Interactivity concentrates in the molecule layer — the reusable leaf units that actually hold local state, like a form, a card's wishlist heart, or an accordion row — while the layers that shape a page (organisms, templates) are almost entirely server-rendered. Of the 33 organisms, only 5 are Client Components at all: Header (mobile-menu state), TemplatesExplorer and YourProductsGrid (client-side filter state), SavedTemplatesGrid, and DashboardTabs. The other 28 — every section on the home page below the header, every section of every landing-category product page — render to static markup with no client-side framework cost of their own, React or otherwise.
This is the axis a raw "React vs. Svelte" bundle comparison misses: the question for a marketing site isn't "how small is the client runtime," it's "how much of the page needs a client runtime at all." Server Components make that answer "not most of it," independent of which client-side library handles the remaining 26%. SvelteKit has its own version of server-only rendering, so this isn't an argument that Svelte can't do the same thing architecturally — it's that the bundle-size framing most React-vs-Svelte comparisons lead with already assumes every component hydrates, which is the wrong assumption for a page built this way regardless of framework.
What actually is a React-only cost here
To be direct about the side of this comparison that doesn't favor us: this codebase runs React 19.2.4 on Next.js 16.2.9 with the React Compiler not enabled — no experimental.reactCompiler flag in next.config.ts. That means the 24 Client Components pay ordinary manual-memoization tradeoffs (a missing useMemo/useCallback can still cause an avoidable re-render) that Svelte's compiler-driven reactivity and React's own opt-in compiler both exist to remove. Turning the compiler on is a real, available lever this codebase hasn't pulled — worth naming rather than glossing over, since a fair comparison isn't "React the concept" vs. Svelte, it's this specific configuration vs. Svelte.
When Svelte's model actually wins the argument
- The page is mostly interactive. A dashboard, an editor, a canvas tool — anywhere most of the tree holds state — is exactly the profile Svelte's compiled-reactivity model was built for, and the 221 KiB
react-domfloor becomes a real tax rather than a rounding error against a mostly-static page. - Team size and hiring pool matter more than raw performance. React's ecosystem and hiring pool are larger; Svelte's learning curve is gentler for a small team building alone. Neither is a technical argument, and both are legitimate ones.
- You're optimizing for the smallest possible shipped bytes on a highly constrained connection, where every kilobyte of framework runtime is measurable against real user latency.
None of those describe a template-marketplace landing page whose job is mostly rendering marketing copy, a pricing table, and a handful of interactive widgets — which is why this comparison is framework-fit, not a verdict on either framework in general.
The part of "compile-time vs. runtime" that's easy to overstate
It's tempting to read "Svelte compiles away the framework" as "Svelte has zero runtime cost," which overstates it. Svelte 5's compiler still emits a small runtime for its signal-based reactivity (runes) — it's dramatically smaller than shipping a virtual-DOM reconciler, but it isn't nothing, and comparing "Svelte: 0 KB" against "React: 221 KB" is the kind of framing that makes for a persuasive tweet and a wrong number. The accurate claim is directional, not absolute: Svelte's compiled output scales with how much of your actual component code needs reactivity, where React's react-dom cost is closer to a fixed floor paid once regardless of how little of the page is interactive — which is exactly why the Server Components split earlier in this post matters more than either framework's raw runtime size for a page that's mostly static content.
Common mistakes
| Mistake | Symptom | Fix |
|---|---|---|
| Comparing bundle size without accounting for Server Components | React looks strictly heavier than it is for a mostly-static page | Measure client JS actually shipped per route, not the framework's theoretical floor |
| Treating "React ships more JS" as true of every React page | Ignores that Server Components ship zero client JS for non-interactive sections | Count Client Components as a share of the tree, the way the table above does |
| Assuming Svelte can't do server-only rendering | SvelteKit has its own SSR/server-load story | The comparison that matters is bundle weight of the client-hydrated portion, in either framework |
| Citing React's bundle cost without naming the React Compiler | Implies the cost is unavoidable rather than a configuration choice | State plainly whether the compiler is enabled, as this post does |
| Choosing a framework on benchmark microbenchmarks alone | Team hiring pool and ecosystem maturity dominate real project cost | Weigh ecosystem and team fit alongside runtime numbers |
Frequently asked questions
Is Svelte actually faster than React in production, not just smaller? For DOM updates on equivalent components, yes, typically — no virtual-DOM diffing step to run before the real DOM mutation happens. Whether that shows up as a user-perceptible difference depends entirely on how update-heavy the page is; a landing page re-rendering a handful of components on scroll rarely spends enough time in reconciliation for the difference to be visible.
Does using Next.js instead of plain React change this comparison?
Substantially, in the direction this post argues: plain client-side React ships the full runtime for the whole page, which is the comparison most "React vs. Svelte" articles are actually making. Server Components change what fraction of a Next.js page pays that cost at all, which is why the comparison for this codebase isn't React vs. Svelte in the abstract — it's "a mostly-server-rendered Next.js app" vs. "a mostly-server-rendered SvelteKit app," and the client-JS delta between those two is much smaller than react-dom's raw size implies.
Should I pick React or Svelte for a new project based on this post? Based on bundle weight alone, for a highly interactive app, lean Svelte; for a mostly-static marketing site or one already invested in React's ecosystem, the Server Components architecture closes most of the practical gap. Either way, the honest framework-choice question is broader than one axis — see the entitlement-driven reasoning for why edition choice on this marketplace isn't really about framework performance at all.
Is Svelte 5's "runes" reactivity fundamentally different from React 19's hooks? Mechanically yes — runes are compiler-recognized primitives that produce direct reactive bindings, where React's hooks run inside a component function on every render and rely on the reconciler to reconcile the result. The user-facing effect for a simple counter or form is similar; the difference shows up under load, in exactly the update-heavy scenario the bundle-size section above describes.
Templates where a lean, mostly-static build like this already ships
ASoc Axiom is a neural-networks AI-consultancy landing page — four services, an FAQ accordion, and project-based pricing, the kind of page where the Server Components split above does most of the work. ASoc Beaker is a science-lab services site built the same way: analytical capabilities, research projects, and pricing, almost entirely server-rendered. ASoc Canvas is the one genuinely interactive build of the three — a no-code page-builder marketing site with a drag-and-drop editor demo — closer to the profile where a compiled-reactivity framework earns its keep.
Browse the full set: Next.js landing page templates and Tailwind landing page templates. For the bundle measurement this post cites rather than re-derives, read Astro vs. Next.js for a marketing site, and for the hand-rolled-vs-library trade at the component level, when hand-rolling 91 components actually wins.