Svelte Kit doesn't scale well on large projects

[MrWaip]

Hello, everyone!

I want to share some of the challenges We've faced over the past few years of working with the Svelte/Kit framework, which I think are worth discussing and highlighting to make the future of this framework even better.

First, let me introduce myself. I work as a JavaScript developer at N company. We've been using SvelteKit quite successfully in our work, starting back when it was still in the alpha version. We have around 15+ frontend services built on this framework, a UI kit, micro frontends, and our own application template.

We've also developed our own meta-meta framework around SvelteKit to fine-tune it for production use. We've integrated tracing for microservices, logging, Prometheus for metrics collection, various plugins for handling authorization, automatic generation swagger schemas, and many other useful features.

Next, I'll list the issues we've encountered.

1) IDE

Our IDEs, which we use, have stopped responding efficiently. It takes about a minute for Svelte LSP to initialize. Our laptops are overheating badly. Autocomplete works very slowly or doesn’t work at all. This affects both the autocomplete in component markup, such as props, and in script tags, where autocomplete has become very unresponsive. For some colleagues, Svelte LSP even stops working because it runs out of RAM. This issue affects VS Code, WebStorm, Nvim, and Zed.

Our largest project (in terms of code) has 3,768 Svelte components with 304,411 lines of code and 15,328 TypeScript files with 437,593 lines of code. It might not sound like much compared to the GraphQL service written in Go by a neighboring team, which has 1,714,120 lines of Go code, and everything works as smoothly as it did the first time.

I understand that the issue might not be entirely with Svelte LSP or Svelte itself, but could be rooted elsewhere, such as the fact that the entire JavaScript tooling ecosystem is written in JavaScript and runs on single-threaded Node.js. However, I wanted to highlight that in large projects, the IDE becomes extremely unresponsive, and it would be great if the team supporting the Svelte ecosystem was aware of this.

2) Build speed

Building the application for production takes 10 minutes, and Svelte-check takes an additional 10 minutes. This is quite slow, and it's hard to find a workaround. Neither esbuild, swc, nor rspack currently have good support for Svelte. As projects grow and evolve, this build time is likely to increase.

3) Responsiveness of the development server

The cold start for npm run dev (Vite) takes 1:30 minutes, while the hot restart takes 1 minute. This is also quite slow, especially when you need to restart the server after changing the configuration. Along with the IDE, my MacBook Pro starts to struggle.

4) SvelteKit adapters

SvelteKit has excellent adapters for various use cases. We used adapter-node, which allows some customization of the Node.js server, but only to a limited extent. At the end of the build process, you can replace the entry point in build/index.js and override what you need there (SvelteKit adapter-node documentation).

This can lead to discrepancies between server behavior during development and production, which has repeatedly caused bugs. We managed to work around this issue similarly to how SvelteKit handles the dev mode for Vite (SvelteKit Vite dev mode code).

However, I dislike such workarounds and would prefer having an API for server customization in both dev and production modes.

Here’s a snippet demonstrating a custom plugin approach for Vite:

export const viteAppPlugin = async (): Promise<Plugin[]> => {
	const svelteKitPlugins = await sveltekit();

	const plugin: Plugin = {
		name: 'vite-app-plugin',
		configureServer: async (vite) => {
			const [, moduleId] = await vite.moduleGraph.resolveUrl('src/server/index.ts', true);

			return (): void => {
				const { handle: svelteKit } = vite.middlewares.stack.splice(-1, 1)[0]!;

				let serverPromise = loadApp(vite, moduleId, svelteKit);

				vite.middlewares.use(function appMiddleware(req, _, next) {
					Object.defineProperty(req, 'path', { value: req.url || '', enumerable: true });

					serverPromise.then(() => next());
				});

				const reloadServer = debounce((file: string) => {
					const changedModule = vite.moduleGraph.getModuleById(file);

					if (changedModule && isDependency(changedModule, moduleId, new Map())) {
						serverPromise = loadApp(vite, moduleId, svelteKit);
					}
				}, 300);

				vite.watcher.on('change', reloadServer);
				vite.watcher.on('unlink', reloadServer);
				vite.watcher.on('add', reloadServer);
			};
		},
	};

	return [...svelteKitPlugins, plugin];
};

This snippet helps maintain consistency between development and production environments, but it’s not ideal. It would be better to have a built-in API that allows more straightforward customization in both modes.

5) Runtime perfomance

I appreciate that SvelteKit allows you to write API endpoints out of the box (SvelteKit server routes). However, as experience has shown, this approach isn't always the most performant. For a load of 11k RPS, it required around 200 pods just to proxy requests to other backends and render HTML. This is a significant amount of resources for relatively simple tasks. As a result, we decided that the best approach would be to write endpoints directly on the Node.js server, bypassing SvelteKit.

6) UI kit

Our UI kit isn't the largest, but it contains many icons (about 2,000). Svelte doesn’t currently support compiling libraries to publish as pre-built JavaScript, which means these components are recompiled every time. I’m not sure what can be done about this, but it seems like unnecessary overhead.

Update

7) Playwright testing

I remembered some additional challenges related to testing. On our most demanding project, we have 6,159 Playwright tests. We encountered several issues when testing a SvelteKit application.

SSR: When there’s a lot of server-side rendering (SSR) in a project, and the page is returned already rendered, it’s not very clear how to mock API calls on the SSR side. We’ve had to implement various workarounds and heavily modify the Node.js server to enable such mocks.

Since client-side load functions (+page.js) started serializing responses, it has become impossible to mock them effectively.

Additionally, SSR in SvelteKit can lead to flaky tests. For example, a Playwright selector might click a button before hydration is complete, causing the test to fail because the event handler hasn’t been attached yet.

It would be helpful to have a section in the documentation addressing this issue, offering best practices for handling SSR-related testing challenges.

Update 20/09/2024

8) Microfrontends + Svelte kit

From everything mentioned above, it suggests that the project should be split. And that micro-frontends might be the solution. However, after searching for ready-made solutions, you find nothing.

There is vite-plugin-federation, but it is completely incompatible with SvelteKit. I tried to dig into it and combine them, but without success. The problem is that SvelteKit and Federation handle and generate chunks differently.

If you think about it, a micro-frontend is just a small SPA application. And if you remember, a Svelte component (v4) is a regular class that can be instantiated programmatically, then we have a plan.

In principle, Vite is enough for us to create micro-frontends using Vite's capabilities.

In the service that will expose microfrontends, We can create a file called manifest.ts and export an object from it with dynamic imports of components.

const unwrapDefault = async (promise: Promise<{ default: unknown }>) => {
  return (await promise).default;
};

const manifest = {
  MyApp: () => unwrapDefault(import('./apps/MyApp.svelte')),
};

export default manifest;

And in the host application, where we want to embed the micro-frontend, we can do something like this:

<script>
  let node;

  onMount(async () => {
    const manifest = await import('https://my-host/manifest.js');
    const { MyApp } = manifest;
    const app = await MyApp();

    new app({
      target: node,
      props: {},
    });
  });
</script>

<div bind:this={node} />

This is a simplified example. There are some pitfalls with this approach, but it will work. Thanks to Vite, which has a Vite preload feature that will automatically load all dependent chunks of JS and CSS when importing the micro-frontend.

[david-plugge]

Very interesting as i never work on such a large project. But sometimes VSCode starts to struggle even on my smaller projects but i assume its just typescript that is the bottleneck here.

Having to rebuild everything every time is definately annoying. A more incremental way would help a lot.

I've not experienced any performance issues regarding server routes, would love to understand why they are significantly slower in your case (again, my projects do not have that amount of throughput).

[Bewinxed]

One thing I wish sveltekit did is being able to expose the return type of the response, it would make it easier to connect front/backend.

i built svetch.ts but it uses AST Tree for that, it works and does swagger but I can't imagine how much it would take in your kind of project.

[MrWaip]

For that purpose we developed custom vite plugin, that generate typed fetch client and swagger schema from types of api handlers

[TKasperczyk]

I believe tRPC with Svelte Query would solve this problem entirely for both client-side and server-side data fetching. No need for type generation.

[MrWaip]

Trpc has performance cost

[CarsonGH]

Does anyone have experience with an equivalent sized NextJS, Vue SSR, or Angular SSR project and can share numbers comparing build times and hot reload times?

It would be interesting to see if this is even a svelte problem or just a constraint of large javascript projects in general.

The build times don't honestly seem that bad for a project of this size. But i could see how the hot reloading and IDE issues would be problems.

[paoloricciuti]

Hi, Paolo here. Thanks for the detailed feedback. I will try to express my thoughts on some of your comments but consider I never worked on such large projects so take what i say with a grain of salt.

Our IDEs, which we use, have stopped responding efficiently. It takes about a minute for Svelte LSP to initialize. Our laptops are overheating badly. Autocomplete works very slowly or doesn’t work at all. This affects both the autocomplete in component markup, such as props, and in script tags, where autocomplete has become very unresponsive. For some colleagues, Svelte LSP even stops working because it runs out of RAM. This issue affects VS Code, WebStorm, Nvim, and Zed.

Svelte LSP is likely at least partially responsible about this but i'm not sure it's the main culprit. You made a comparison with Go but that's a different language and a different toolchain. Did you have any other experience with other frameworks at the same scale? Would be interesting to see how well Vue, React perform at the same scale. We are also trying to dive into the performance of the language server but as you might imagine is difficult to create a coherent very large project to test it. If you have any suggestions about such large projects possibly open source so that we can test on them that would be sweet.

This same answer basically apply to points 2 and 3 too (although the svelte-check one is more interesting because we own more of the process).

However, I dislike such workarounds and would prefer having an API for server customization in both dev and production modes.

What kind of customization do you need? And what would be your ideal API for such customizations?

This snippet helps maintain consistency between development and production environments, but it’s not ideal. It would be better to have a built-in API that allows more straightforward customization in both modes.

Can you elaborate a bit more about why this is not ideal? It is because you are separating the code for dev and the code for prod? Vite if famous for some small discrepancy between dev and prod and i guess that maybe between rolldown and the environment api that they are about to launch we might be able to get more consistency.

I appreciate that SvelteKit allows you to write API endpoints out of the box (SvelteKit server routes). However, as experience has shown, this approach isn't always the most performant. For a load of 11k RPS, it required around 200 pods just to proxy requests to other backends and render HTML. This is a significant amount of resources for relatively simple tasks. As a result, we decided that the best approach would be to write endpoints directly on the Node.js server, bypassing SvelteKit.

Don't have much to say here...there's probably a bit of overhead because those could be generic endpoints while you can write more performant specific endpoints directly in node but i think this is definitely something we should look into.

Our UI kit isn't the largest, but it contains many icons (about 2,000). Svelte doesn’t currently support compiling libraries to publish as pre-built JavaScript, which means these components are recompiled every time. I’m not sure what can be done about this, but it seems like unnecessary overhead.

Technically you could pre-compile them to JS and mount them. The reason it's not ideal to do so is because the compiled output depends on the version of the compiler. This means that if you compile that library with a compiler that has a bug in it and a future version fixes that bug upgrading to the new version in your project doesn't actually fix the bug for your precompiled component.

SSR: When there’s a lot of server-side rendering (SSR) in a project, and the page is returned already rendered, it’s not very clear how to mock API calls on the SSR side. We’ve had to implement various workarounds and heavily modify the Node.js server to enable such mocks.

I suggest you to take a look at MSW... it's a fantastic mocking suite that allow you to have a service worker for api calls from the browser but also a node server to mock requests on the server side, you can use the same handlers for both and it's very declarative.

Since client-side load functions (+page.js) started serializing responses, it has become impossible to mock them effectively.

Personally i would use a different approach here...there's no reason to mock sveltekit requests....you need to mock the request at the data layer. When sveltekit goes and fetch from your external api/db/whatever that's where you return the mocked data. This way you let sveltekit do his job with that fake data that you provide.

Additionally, SSR in SvelteKit can lead to flaky tests. For example, a Playwright selector might click a button before hydration is complete, causing the test to fail because the event handler hasn’t been attached yet.

I've encountered this problem myself and i copied the same solution sveltekit test suite is using: you can write a playwright fixture like this one

page: async ({ page, javaScriptEnabled, context }, use, testInfo) => {
    // automatically wait for kit started event after navigation functions if js is enabled
    const page_navigation_functions = ['goto', 'goBack', 'reload'] as const;
    page_navigation_functions.forEach((fn) => {
        const pageFn = page[fn];
        if (!pageFn) {
            throw new Error(`function does not exist on page: ${fn}`);
        }
        // substitute the actual function with a new function that waits
        // for the selector that we've set in +layout.svelte
        page[fn] = async function (...args: Parameters<typeof pageFn>) {
            // eslint-disable-next-line @typescript-eslint/ban-ts-comment
            // @ts-expect-error
            const res = await pageFn.call(page, ...args);
            if (
                javaScriptEnabled &&
                (args[1] as { waitForStarted: boolean })?.waitForStarted !== false
            ) {
                // eslint-disable-next-line playwright/no-wait-for-selector
                await page.waitForSelector('body[data-kit-started]', { timeout: 15000 });
            }
            return res;
        };
    });
    await use(page);
},

and then you just need to add this to your root layout

onMount(() => {
    document.body.setAttribute('data-kit-started', '');
});

this will make sure that every playwright navigation will wait for svelte to hydrate before start interacting with the page.

[MrWaip]

Did you have any other experience with other frameworks at the same scale

No, I don't have experience with other frameworks on similarly large projects

[MrWaip]

What kind of customization do you need? And what would be your ideal API for such customizations?

https://github.com/sveltejs/svelte/discussions/12974#discussioncomment-10600170

[MrWaip]

Can you elaborate a bit more about why this is not ideal? It is because you are separating the code for dev and the code for prod

What I mean is that I would like to have a framework-level API to extend the Node.js server, and for it to work consistently during both npm run dev and npm run build.

A large application can't exist in production without metrics collection, logging, and other modifications.

[MrWaip]

Thanks for reply @paoloricciuti

[paoloricciuti]

What I mean is that I would like to have a framework-level API to extend the Node.js server, and for it to work consistently during both npm run dev and npm run build.

Ok i think i get it...just throwing ideas out there...could you imagine a configuration on the adapter node a viable solution for this?

[eltigerchino]

Keep an eye out for Rolldown which will replace Rollup, improving build and dev server speeds (where bundling is concerned).

[benmccann]

6) UI kit Icons

Our UI kit isn't the largest, but it contains many icons (about 2,000). Svelte doesn’t currently support compiling libraries to publish as pre-built JavaScript, which means these components are recompiled every time.

Large icon libraries are pretty common, so this is one I've investigated in the past. The first thing to note is that there are four different ways to build icon libraries that I've seen:

• icons in CSS (e.g. https://iconify.design/docs/usage/css/tailwind/)
• .svelte generated on demand as in-memory virtual file via vite plugin (e.g. https://github.com/unplugin/unplugin-icons)
• a couple of .svelte files with per-icon data or JS (e.g. https://github.com/RobBrazier/svelte-awesome)
• a .svelte file for each individual icon (will not name the guilty here 😄)

When people run into scaling issues with icons, I've always seen that falling into the last bucket. My first recommendation would be to avoid this structure and go with one of the others. I personally like the CSS approach and avoiding JS altogether

these components are recompiled every time. I’m not sure what can be done about this, but it seems like unnecessary overhead.

If you have a standalone library, it will generally be pre-bundled by Vite on the first server-startup. There are two ways to export files from a package. You can use what's called an umbrella export where they are all exported from the main entry point or you can have an export per-file. What is very important here is that you never mix-and-match. If you have an umbrella export, then prebundling will be a one-time cost and while you will have to wait a bit (~20-30s perhaps), you shouldn't have to pay that cost when subsequently changing the code, restarting the server, etc. With the direct export a prebundling will happen each time you import a new file from the package, but it should be very short and quick. If you do both, then you will repeatedly pay the larger cost for pre-bundling the whole library everytime you import a new file.

For more details about this see: https://github.com/sveltejs/vite-plugin-svelte/blob/main/docs/faq.md#what-is-going-on-with-vite-and-pre-bundling-dependencies

If you must have a .svelte file per icon, I would avoid writing your exports map in package.json in such a way that it's possible to import with both styles so that consumers can't hit this issue.

[benmccann]

I added a page about icons to the docs: https://svelte.dev/docs/kit/icons

[benmccann]

4) SvelteKit adapters - dev vs prod differences

Can you please expand upon what you were trying to accomplish and what exactly was different in dev vs prod?

[paoloricciuti]

Mmm it feels very weird that kit endpoint performed much slower than native endpoints...the bottleneck here should be the fetch call and the overhead of something that the framework might do should be minimal.

[MrWaip]

We also tested the API by simply returning new Date. There was also a difference.

[paoloricciuti]

The difference is there but counter intuitively it get's thinner and thinner the more time you spend in the function itself. Let's say that an empty endpoint take 20ms to process and an empty polka endpoint take 1ms. That's a 20x improvement. But if you wait 100ms to do an api call in both the difference is 120ms to 101 that's a 1.18x improvement. And if your graphql api that returns 11k lines is spending 200ms to do so it's 220ms vs 201ms which is 1.09x improvement.

[MrWaip]

You mean it's insignificant?

We did this about a year ago, maybe with the updates it is not so relevant anymore. It was noticeable in our environment, I will look for comparisons if they remain

[paoloricciuti]

We did this about a year ago, maybe with the updates it is not so relevant anymore. It was noticeable in our environment, I will look for comparisons if they remain

I know you might not be able to but if you can also provide those that would really help trying to understand what's happening. Btw we plan to also explore the current situation to see if there's room for improvement.

[DrDanRyan]

Vercel recently(10/22/24) had a blog post about how they improved build times and developer experience by adopting a microfrontend approach you may find interesting How Vercel adopted microfrontends

[itssumitrai]

Hmm Interesting, I can say this because I do work as part of a very large project. Yahoo Finance is completely written on Sveltekit now, and we have several hundred pages, I haven't seen any of the scale issues mentioned but we don't use sveltekit for our micro services though.

[benmccann]

@itssumitrai thanks so much for sharing! I've used Yahoo Finance tons my whole life so it means a lot to me to see it being used there 😄

[itssumitrai]

Thanks @benmccann And all the Svelte maintainers for making this amazing dev friendly framework 💯

[MrWaip]

Svelte is really cool, i agree

tree src/routes/**/*.svelte

printed for me

0 directories, 528 files

[moimikey]

i'm beyond curious if there was any further updates on this @MrWaip

[MrWaip]

yeah, I have one. we had to lock svelte lsp 108.5.2, and allocate more memory for nodejs because in newer versions it crashes because all free ram is eaten, even if you give it all the memory on the laptop

[benmccann]

Please file an issue in the https://github.com/sveltejs/language-tools repo, so that the folks working on it are aware and can address it.

For reference, here are the release notes for the subsequent release: https://github.com/sveltejs/language-tools/releases/tag/extensions-108.5.3

[MrWaip]

started issue sveltejs/language-tools#2738

[dennypenta]

Also happy to know if svelte 5 did any meaningful change for you @MrWaip

[MrWaip]

Hi. To be honest, we can't move to svelte 5 at the moment, the code base is too big. Also, in this case, we would have to freeze development, which we can't afford. But in our microfrontends, into which we are sawing our monolith, there are no problems with Svelte 5 yet

[MrWaip]

Hi. Since it recently became possible to try Rolldown Vite, I have assembled a primitive project on svelt 5. I think it is possible to experiment with tooling on it.

https://github.com/no-mrwaip/svelte-rolldown

The standard hip size was not enough, had to increase to 8 GB

[MrWaip]

off top: rolldown can't correctly import svelte components from npm package if there is no default specifier in the package.json

not work

{
  "exports": {
    "./components/Bone/Bone.old.svelte": {
      "types": "./dist/components/Bone/Bone.old.svelte.d.ts",
      "svelte": "./dist/components/Bone/Bone.old.svelte",
    }
  }
}

work

{
  "exports": {
    "./components/Bone/Bone.old.svelte": {
      "types": "./dist/components/Bone/Bone.old.svelte.d.ts",
      "svelte": "./dist/components/Bone/Bone.old.svelte",
      "default": "./dist/components/Bone/Bone.old.svelte"
    }
  }
}

[eltigerchino]

You may also want to update vite-plugin-svelte for compatibility with Rolldown https://github.com/sveltejs/vite-plugin-svelte/releases/tag/%40sveltejs%2Fvite-plugin-svelte%406.0.0-next.0

We also have a PR started to integrate with Rolldown here #13747 with a list of blocking issues here #13738

[mateothegreat]

Environment, topology, and practices materially affect outcomes.

After thinking this through I've concluded that, at its core, this isn’t a "Svelte problem" — it’s an architecture problem, and until that’s addressed, the rest are just symptoms.

Right now the app’s dependency graph, build pipeline, and integration points are carrying more load than they were designed for. That's why you see slow LSPs, long builds, dev‑server lag, flaky SSR tests, and even uneven runtime performance. They’re all different faces of the same issue: the system can’t scale cleanly with its current structure.

The leverage point is going to be realized at architecture level and assess a redesign of boundaries and flow:

• Shrink and segment the hot module graph so tooling doesn’t churn on the entire codebase for every change.
• Rework packaging/export strategies so pre-bundling is predictable and bounded.
• Introduce clear server/runtime extension points instead of patching outputs.
• Instrument critical paths so bottlenecks are visible and fixable.

Fix the architecture, and you remove entire classes of problems at once — instead of whack‑a‑moling them forever!

P.S.:

Most of the pain points—IDE lag, build times, testing wrinkles, icon recompilation, and microfrontend hacks—originate in the broader JavaScript/TypeScript ecosystem or community plugins.

Only two areas squarely fall on SvelteKit’s shoulders:

1. Providing a built-in, consistent server-extension API (adapter customization).
2. Further optimizing the SSR endpoint pipeline.

If we try to treat each symptom in isolation — tweak LSP settings here, change bundler flags there — we'll be forever firefighting. Solve the architecture first, and you eliminate whole classes of problems before they manifest. That's how you scale not just SvelteKit, but any modern web stack.

[majoravery]

Perhaps you have a point here but the amount of em dashes here really scream AI generated answer 😭

[TKasperczyk]

Perhaps you have a point here but the amount of em dashes here really scream AI generated answer 😭

I'd say most people use AI to refine and improve their writing rather than generate stuff from scratch. There's nothing wrong with using it to enhance the quality of communication

[majoravery]

I don’t disagree at all because I also occasionally enjoy turning on the chat mode and word vomiting a bunch of disjointed points then go “make it coherent thanks”

It’s just there’s a fine line between editing and writing, especially when we’re on the other side of it we can’t tell which one was fed as the prompt.

[MrWaip]

Okay. Do you have any examples of how you transferred a four-year-old monolith on Svelte Kit to a different architecture and everyone became happy, both devs and the product?

We are cutting our monolith into self-written spa microfrontends or standalone applications (if the design allows). In the process, it is very depressing that there is nothing out of the box. There are problems with routing: if the main page is managed by the svelte kit runtime, then it is not possible to set up high-quality routing inside the svelte spa microfrontends