Migrating to Svelte 5 increased my bundle size on 30%

[brenoliradev]

Describe the bug

So, I'm updating my project to Svelte 5 and I ran into a a problem.

Just by updating it the bundle-size of my project grew by aproximatedly 9kb. Since it was on my example project, it increased more than a third of it's total bundlesize i.e. from 23kb to 32kb aproximatedly.

Since I'm building my code onto small standalone apps I really feel this increase on bundle size.

I guess it's expected but I'm opening a issue to seek some help to understand if has something that I can do. Tbh at visualizer my code itself is smaller than before, so I guess it's just some weird pattern on my configs that I couldn't really made fully functional.

Also I'm using this project on my daily job and I tried updating the code there I also got the same amount of 9kb increase in my standalone widgets. - In this case, it grew from somewhere from 35kb to somewhere of 43kb.

Reproduction

Svelte 5 version: visualizer .min.js

Svelte 4 version: visualizer .min.js

Repo: svelte-standalone

Logs

No response

System Info

Svelte 5:
    System:
    OS: Linux 6.5 Pop!_OS 22.04 LTS
    CPU: (12) x64 AMD Ryzen 5 5600 6-Core Processor
    Memory: 23.55 GB / 31.24 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 20.16.0 - ~/.nvm/versions/node/v20.16.0/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.1 - ~/.nvm/versions/node/v20.16.0/bin/npm
    pnpm: 8.6.1 - ~/.local/share/pnpm/pnpm
    bun: 1.1.26 - ~/.bun/bin/bun
  Browsers:
    Brave Browser: 129.1.70.117
    Chromium: 128.0.6613.84
  npmPackages:
    svelte: ^5.1.0 => 5.1.0

Svelte 4:
  System:
    OS: Linux 6.5 Pop!_OS 22.04 LTS
    CPU: (12) x64 AMD Ryzen 5 5600 6-Core Processor
    Memory: 23.46 GB / 31.24 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 20.16.0 - ~/.nvm/versions/node/v20.16.0/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.1 - ~/.nvm/versions/node/v20.16.0/bin/npm
    pnpm: 8.6.1 - ~/.local/share/pnpm/pnpm
    bun: 1.1.26 - ~/.bun/bin/bun
  Browsers:
    Brave Browser: 129.1.70.117
    Chromium: 128.0.6613.84
  npmPackages:
    svelte: ^4.2.7 => 4.2.19

Severity

annoyance

[webJose]

Generally speaking, smaller projects should grow in bundle size while larger projects should decrease in bundle size. As I understand things, Svelte v4 generates all the needed code to fulfill the expected reactivity of variables on the fly, on demand. From nothing to everything, on every component. This is why Svelte v4 doesn't have a runtime: It's all built in-situ.

Svelte v5's reactive system, on the other hand, depends on a runtime so Svelte compilation now has a base to work with. Now components can enable reactivity by leaning on this runtime. So on small projects, the apparition of the runtime is significant in terms of percentage, but in larger projects, the amount of generated code that can be cut far surpasses that of the addition of the runtime, resulting in smaller builds.

[brenoliradev]

Yeah, that's what I thought seing the benchmarks. I'm just reaching out to see if I can configure it to mitigate these loss.

[Thiagolino8]

One way to counterbalance this might be to use astro instead of sveltekit if you don't need sveltekit's robust router.

[brenoliradev]

@Thiagolino8 I'll check something in this aporoach to see if I can mitigate the size.

But I don't thinks that's the point right now. The ideia behind my project is to build solely the svelte components and not the sveltekit app. itself.

I do use the sveltekit router to handle how the scripts are being loaded (and a configured storybook to also check the behavior of the components itself) but once I parse the .svelte files I don't use most of the sveltekit itself.

[benmccann]

Your usecase looks to be that you're building Svelte into .js to embed on other sites. The only thing I can think of that might be a potential savings is perhaps if you have multiple .js built this way that you're including on a page it might be possible to have it share a version of the Svelte runtime. I don't actually know if this is possible and wouldn't be the right person to ask about that, but that's basically the only way of avoiding the Svelte runtime that I can think of. You always need at least one copy of it.

The runtime is tree-shakable, so if you use fewer features you'll get a smaller version of it. But you'll basically always end up with the base reactivity library

[brenoliradev]

Your usecase looks to be that you're building Svelte into .js to embed on other sites. The only thing I can think of that might be a potential savings is perhaps if you have multiple .js built this way that you're including on a page it might be possible to have it share a version of the Svelte runtime. I don't actually know if this is possible and wouldn't be the right person to ask about that, but that's basically the only way of avoiding the Svelte runtime that I can think of. You always need at least one copy of it.

The runtime is tree-shakable, so if you use fewer features you'll get a smaller version of it. But you'll basically always end up with the base reactivity library

Yeah, that's summarize it perfectly. The idea behind is to write code that's reusable/shareable between the embedables using the Svelte as a manager. Something like react-email but niched to embeds.

About being tree-shakable, I'll give some time to checking what's going on because sound like these ~9kb increasing will be the "bare minimum" that'll be increasing as I adopt the new Svelte 5 runtime.

[webJose]

This topic interests me if it takes the route of runtime-deduplication, which is something I would like to see happening to create Svelte micro-frontends where foreign signals can participate reactively in any micro-frontend, not just the one that created it.

[benmccann]

It looks like css hash name might be another area for opportunity: #8826 (comment)

sound like these ~9kb increasing will be the "bare minimum" that'll be increasing as I adopt the new Svelte 5 runtime.

Probably something in that ballpark. For most websites you should be coming out ahead because the components compile to much smaller output. But if you're building something small like a single component then that trade-off unfortunately doesn't work to your advantage

[brenoliradev]

It looks like css hash name might be another area for opportunity: #8826 (comment)

Thanks for sharing this issue, I'll investigate it but maybe this wouldn't give me any gains since I'm using Tailwind and purging/embedding the styles.

Probably something in that ballpark.

Sad to hear but totally get the point

[Metehan-Altuntekin]

I am also getting an increase from

• ~26KB on Rollup + Svelte 4
• ~44KB on Rollup + Svelte 5
• ~35KB on Vite + Svelte 5

on a web components project. Rollup ones have terser enabled and treeshake is default

[dummdidumm]

We need a reproducible here (also is that minified+gzip or something else)

[PuruVJ]

I can also attest this, on a project, the bundle size nearly increased by 50% on svelte 5 migration. Turns out there was a stray customElement: true in the svelte.config.js. Removing it fixed the issue and reduced the size by 68%!!! But yeah, if WC is what you're going for, it might be too big in v5