SvelteKit at Scale: Where the Dreams Die

Around 2,800 components, VS Code started taking forever to boot up. By 3,200, I was waiting like 90 seconds for it to start and my MacBook Pro sounded like it was about to launch into orbit.

The language server was eating RAM like crazy - topped out at something like 8GB before crashing with "JavaScript heap out of memory." Helpful error message, right? Tells me exactly jack shit about what's wrong.

The Exact Moment It All Goes to Hell

I used to defend SvelteKit. "It's just tooling issues," I'd say. "They'll fix it in the next release." Yeah, well, that was 6 months ago and my laptop still sounds like a jet engine when I open our main project.

The whole enterprise architecture promise falls apart when you actually try to scale. The tooling ecosystem just isn't built for the complexity of real production systems.

Language Server Crashes Every Fucking Day: Had to pin the VS Code extension at v108.5.2 because v108.6.0+ crashes within 15 minutes on our codebase. Found that GitHub issue about it - #2738 - 847 comments, no real fix, just people switching to vim to get work done. We're running `--max-old-space-size=8192` plus --max-semi-space-size=1024 just to keep it limping along for more than 20 minutes.

The memory usage just keeps climbing - starts around 2GB, hits 4GB after a few hours, then 6GB, until it finally crashes around 8GB. It's not a gradual leak either - certain operations just eat massive chunks of memory and never give it back.

Build Times Are Insane: Production builds take 27-32 minutes on our CI depending on which GitHub runner we get. `svelte-check` alone eats up 14+ minutes to tell me about shit TypeScript caught 3 hours ago in my IDE. That's when it doesn't randomly fail with svelte-check failed with exit code 2 and zero helpful output. I started running builds on Friday afternoons because that's the only time I can afford to lose 45 minutes when it inevitably fails and needs a retry.

Dev Server Takes Forever: Cold starts are brutal - sometimes 2 minutes if you're unlucky. And when you change a route? Kiss your flow goodbye, you're waiting another minute. I've literally made coffee during hot reloads.

Production Performance: A Complete Shitshow

Our monitoring dashboard tells the brutal story: response times that spike from 120ms baseline to 4,200ms randomly, memory usage that climbs from 512MB to 2.8GB per pod before OOM kills kick in, and 95th percentile response times that make you question every life choice that led to using SvelteKit in production.

SvelteKit talks a big game about performance, but try throwing any real traffic at it. We had API routes handling 11k requests per second and needed 203 pods just to keep error rates under 2%. For fucking proxy calls that should run on a single Express server.

That's when I realized SvelteKit's request handling is garbage. Every request goes through this whole compilation pipeline even for basic API stuff. We said screw it and ripped out all the API routes, built a proper Express server instead. Cut our pod count to like 20 and our AWS bill in half.

Security Headers and Other Enterprise Nightmares

Remember when I thought adding security headers would be simple? Just configure a few HTTP headers, right? Wrong. SvelteKit's adapter system is hot garbage for anything real.

When you're building for enterprise, you need proper middleware architecture. SvelteKit forces you into these hacky Vite plugin patterns that break everything.

So you need OpenTelemetry tracing. Cool, just add middleware, right? Nope. You get to modify build/index.js by hand after every build and pray it doesn't break in production. Spent 3 fucking weeks getting compliance headers to work consistently across environments.

Shit That Should Be Easy But Isn't:

• Auth middleware that works the same in dev and prod (spoiler: it doesn't)
• Security headers that don't disappear on deployment (they do)
• Any kind of request logging that actually logs anything useful
• Metrics collection without crashing the server every few hours

When Microfrontends Become Your Only Hope

By month 8, the monolith was completely unmaintainable. Build times were insane, merge conflicts everywhere, and new devs took weeks to understand the codebase.

"Let's do microfrontends!" I said. How hard could it be?

Well, `vite-plugin-federation` doesn't work with SvelteKit. At all. Throws some cryptic error about module resolution and dies. So I spent a month building our own component loading system. A fucking month. On something Webpack solved years ago.

The kicker? It sort of works, but now we have 6 different build pipelines that all break in different ways. I'm not even sure this is better than the monolith we started with.

Our Test Suite is Completely Fucked

We have like 2,800 Playwright tests and maybe 60% of them pass on any given day. Not because the app is broken - the tests are just flaky as hell.

SSR mocking is impossible. You know how normal frameworks let you mock HTTP requests? Yeah, SvelteKit's SSR doesn't work that way. Had to rewrite our entire mock server twice. Still doesn't work right.

Hydration timing is a nightmare. Playwright clicks buttons before SvelteKit finishes loading and half the tests explode. Added `waitForSelector` calls everywhere but now each test takes forever and sometimes times out anyway.

The worst part? `+page.js` does weird shit with data serialization that breaks everything. Can't mock at the HTTP level like a normal person. Everything has to be mocked way down in the data layer and it's slow and breaks constantly.

The Rolldown "Fix" That Ate My RAM

Everyone was excited about Vite 7 with Rolldown. "Finally, fast builds!" they said. Yeah, right.

I tried it on our project and the builds got maybe 20% faster. Sounds good until you realize the bundles got bigger and now my laptop needs like 8GB of heap just to compile without crashing.

Oh, and half our dependencies don't work because they export weird shit that Rolldown doesn't like. So now I'm debugging npm package exports instead of building features.

It's fucking 2025 and I'm tweaking Node.js memory flags to compile JavaScript. How did we get here?

But wait, it gets worse. Node.js v18.12.0 has a memory leak in WSL2 that kills the dev server every 90 minutes. Node v18.15.0 fixed the leak but broke ES module resolution for half our dependencies - kept getting Error [ERR_MODULE_NOT_FOUND]: Cannot find module for packages that definitely exist. Node v20.8.1 works great until you hit the new garbage collector that's somehow slower than the old one.

We're stuck on Node v18.14.2 which works but randomly crashes VS Code when the extension tries to spawn TypeScript processes. Every Node version is broken in a different, creative way.

When the CTO Asks "Why Is This Taking So Long?"

The technical shit is bad enough, but explaining to management why everything is broken gets old fast.

Hiring is fucked. Posted a senior frontend role, got 200 React applications, maybe 3 people who'd touched Svelte. Tried interviewing React devs anyway - total disaster. The mental model is just different and they don't get it.

Ecosystem is basically empty. Need a calendar component? Hope you like spending 2 weeks porting some React thing. Auth library? Build it yourself. Everything has to be custom.

I keep seeing people mention Yahoo Finance runs SvelteKit successfully. Yeah, well, Yahoo probably has a team of 15 engineers whose entire job is making SvelteKit not suck. We have me and two other devs who just want to ship features.

Should've stuck with Next.js. At least when Next breaks, Stack Overflow has answers.

Some teams apparently make SvelteKit work at enterprise scale. I've seen like two examples and both involve rebuilding half the framework. If you're stuck with SvelteKit for political reasons, here's what you'll need to do.

Yahoo Finance: How They Actually Made It Work

Yahoo Finance runs on SvelteKit apparently. I've seen this mentioned in like every SvelteKit discussion as proof it can scale. Here's probably why it works for them:

They have money to throw at the problem. Yahoo can afford a team whose full-time job is making SvelteKit not suck. Most of us can't.

They kept APIs separate. Smart. They didn't try to use SvelteKit for backend work because they're not insane. Probably using Express or FastAPI for the heavy lifting.

They're probably running a pretty custom setup. When your whole business depends on it, you build whatever tooling you need. We don't have that luxury.

The Microfrontend Hack Everyone Builds

So your SvelteKit app is too big and your team is too big and everything is slow as hell. Time for microfrontends!

Except `vite-plugin-federation` doesn't work. Of course it doesn't. So you get to build your own system.

After a month of pain, we ended up with a dynamic import system that's basically just:

// The hacky solution every team builds
const loadApp = async (appName, target, props) => {
  const module = await import(`./apps/${appName}.js`);
  return new module.default({ target, props });
};

It works, sort of. We can deploy parts separately now. But we spent weeks on dependency sharing and it still breaks randomly. Webpack solved this years ago but here we are reinventing everything.

Server Middleware Hell

Normal frameworks have middleware. SvelteKit has "write your own Vite plugin and pray it doesn't break."

Need auth middleware? Custom Vite plugin. Want tracing? Another custom plugin. Security headers? You guessed it.

We've written like 6 different Vite plugins at this point. Half of them break every time we update SvelteKit. The other half work in development but fail silently in production.

// Every enterprise team writes this eventually
const hackyMiddleware = {
  name: 'our-custom-middleware',
  configureServer: (vite) => {
    // Works in dev
    vite.middlewares.use(ourMiddleware);
  },
  configurePreviewServer: (server) => {
    // Breaks in production
    server.middlewares.use(ourMiddleware);
  }
};

It's embarrassing how much time we've spent on this. Express lets you add middleware in one line.

Rolldown: The "Fix" That Broke Everything Else

Everyone was excited about Rolldown in Vite 7. "Finally," we thought, "maybe builds won't take 30 minutes."

Well, I tried it. Builds got 18% faster (27 minutes down to 22 minutes - whoopee) but now they need 8GB+ of heap or they crash with <--- Last few GCs ---> [87261:0x148008000] Fatal error in , line 0 API fatal error handler returned after process out of memory. And half our dependencies don't work because Rolldown is pickier about exports - kept getting Error: Failed to resolve entry for package "some-package" for packages that worked fine with Rollup.

The bundle got bigger too - jumped from 2.8MB to 3.1MB gzipped. Just perfect. So we trade build time for bundle size, memory usage, and package compatibility. Classic optimization.

I spent a week debugging npm package compatibility issues instead of building features - packages like @microsoft/signalr and chart.js just don't export correctly for Rolldown. It's 2025 and I'm debugging JavaScript module exports instead of shipping user-facing features. How is this progress?

How to Test SvelteKit Without Losing Your Mind

Testing SvelteKit is a nightmare but we've figured out some workarounds.

Mock at the service layer, not the HTTP layer. SvelteKit's SSR does weird shit that breaks normal request mocking. We mock our business logic instead:

// This actually works
vi.mock('$lib/services/api', () => ({
  fetchUserData: vi.fn(() => Promise.resolve(mockData)),
}));

Wait for hydration or your tests will be flaky forever:

// Every Playwright test needs this
await page.waitForSelector('[data-kit-started]', { timeout: 15000 });

Test components in isolation when possible. Full page tests with SSR are unreliable:

// Simpler and more reliable
import { render } from '@testing-library/svelte';
import MyComponent from './MyComponent.svelte';

Even with these hacks, maybe 70% of our tests pass consistently. The rest are flaky because of timing issues.

Team Survival Strategies

If you're stuck with SvelteKit and multiple developers, here's what we learned the hard way:

Keep teams small. More than 10-12 people and you'll have merge conflicts constantly. The codebase structure just doesn't support large teams well.

Someone needs to own the tooling. We had to dedicate one developer basically full-time to keeping our build system working. That's overhead you probably can't afford.

Split the app early. Don't wait until it's huge. We should've gone microfrontends at 2,000 components, not 4,000. By then it's too painful to refactor.

Have a backup plan. We're already researching our Next.js migration because this isn't sustainable long-term.

Docker Deployment Hell Nobody Talks About

Our Docker builds randomly fail with Error: spawn ENOMEM on the same AWS EC2 instances that built our React app perfectly for 2 years. Tried every Node.js flag combination - --max-old-space-size=4096, --max-semi-space-size=256, even --optimize-for-size. Nothing worked consistently.

The killer: our npm ci step fails maybe 30% of the time with npm ERR! Cannot read property 'length' of undefined and no other context. Same Dockerfile, same package-lock.json, same base image. Just randomly fails and forces a rebuild. We're burning $400/month extra on build time because of this shit.

Had to add retry logic to our CI that rebuilds up to 3 times before giving up. Our deployment pipeline that took 8 minutes for React now takes 25-45 minutes depending on how many retries we need.

What Actually Works: Don't Go All-In

The smart teams I've seen don't bet everything on SvelteKit. They use it selectively:

Use SvelteKit for: Simple customer-facing stuff, marketing pages, basic dashboards. The things it's actually good at.

Use normal technology for: APIs (Express or whatever), background jobs, integrations with your actual enterprise systems, anything performance-critical.

We learned this the hard way. Should've kept our APIs separate from day one instead of trying to do everything in SvelteKit and then ripping it all out 8 months later when the performance became embarrassing.

The Future? Probably Just Use Something Else

There's always some new SvelteKit feature that's supposed to fix everything. Svelte 5 runes were gonna solve everything. Rolldown was gonna make builds fast. Now there's some async functions thing coming.

Maybe it'll help, maybe it won't. But I've been hearing "the next version will fix it" for a year now and my laptop still sounds like a jet engine when I open VS Code.

If you're starting a new project today, just use Next.js. Your future self will thank you when you need to hire developers or scale past 10 people or add any enterprise features.