Adding this very fast backend and automatically detects the number of CPU cores on the target machine and adjusts the number of worker threads accordingly (main thread + worker threads === number of cores)

Describe the problem

As far as I know, SvelteKit's backend currently uses Polka and offers options for Node.js and Bun. I recently benchmarked both Node.js and Bun: Node.js reached 2000 req/s, while Bun reached 3000 req/s.

Could there be significant overhead in SvelteKit's server logic? Because when Bun is used to serve plain HTML, JS, and CSS with SSR, it can reach up to 30k req/s.

The second issue I encountered is that SvelteKit doesn't automatically detect the number of CPU cores on the machine and spawn worker threads accordingly. I think this is important because most users aren't familiar with this kind of configuration, and the result is that their app ends up using only one core, even though their deployment environment has many.

It would be really great if SvelteKit could handle this "magically" behind the scenes.

Describe the proposed solution

So, I found this very fast JavaScript library that uses C++ named uwebsocketjs (which I later discovered is also used by Bun as its HTTP library). I created a simple REST server that returns HTML via SSR, and I was really surprised to see it reach 40k req/s.

Then, I modified it to utilize all available CPU resources by detecting the number of cores and spawning worker threads accordingly, so JavaScript execution could automatically run in parallel when more than one core is available. On my 10th gen Intel i5 laptop with 8 cores, I made it automatically create 1 main thread + 7 worker threads (not hardcoded), by detecting the number of CPU cores during initialization.

Right after that, the performance jumped to 200k req/s with a max latency of 20 ms in SSR mode. If the target machine only has one core, then we simply don’t spawn any worker threads, just using the main thread. This can be achieved with a fairly simple if else and loop.

Then, by adding a cache layer, the performance increased again to 259k req/s with max latency down to 15 ms on the same laptop. This cache prevents the server from re rendering SSR content if the content hasn't changed. I have some incomplete ideas for implementing this cache. The idea is to send a flag like "update_cache": true to the server. This value would be controlled by the user. For example, when a user makes a POST request, they can pass update_cache: true to the server, which would then update the cache. There might be other ways to handle cache updates, but I haven’t figured out the best approach yet.

I have a working example in this repo (though the cache update mechanism is not yet implemented):
🔗 https://github.com/fuji-184/usvelte

In that repo, SSR and client side hydration for routing are already supported (though I’m not entirely sure if the SSR and client entry points are set up correctly, so please feel free to correct them).

The note is: Try benchmarking this repo and SvelteKit, the difference is massive, as I’ve already tested it myself. In fact, it even outperformed Go's HTML SSR in my benchmark yesterday. So I think it would be amazing if SvelteKit could offer option for automatic high performance out of the box like the repo.

Also, the new V8 engine now supports //# allFunctionsCalledOnLoad, which is useful to add in "hot path" files, i.e., files where the code gets executed frequently. Although it's specific to V8, the comment has no effect on other JS engines, so it might be worth considering.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

Start by reviewing the linked usvelte example and reproducing its SSR and worker-thread benchmark against SvelteKit. The issue names no SvelteKit files, entry points, or tests and combines worker detection, caching, uWebSockets, and V8 annotations; a complete outcome would require narrowing this to one measurable change with explicit acceptance criteria.