Dev Time Run Time e18e.dev Blog
← All frameworks

SvelteKit

Version 2.49.4 · Measured 6/27/2026

Dev Time Performance

Prod Deps Dev Deps Dup. Deps node_modules node_modules (prod) Dep Install Size Graph
0 7 1 61.81MB 0.02MB 65.36MB View
Metric Avg Min Max
Install 1.23s 1.18s 1.29s
Cold Build 2.41s 2.28s 2.80s
Warm Build 2.34s 2.26s 2.39s

Build output size: 1.29MB

Duplicate Dependencies

1 duplicate dependency detected across this starter's node_modules.

View 1 duplicate dependency
  • is-reference 
    [duplicate dependency] is-reference has 2 installed versions:
1.2.1 via the following 1 package(s) @rollup/plugin-commonjs@28.0.9
3.0.3 via the following 1 package(s) svelte@5.46.3
💡 Suggestions
- Consider upgrading consuming packages as this may resolve this duplicate version.

Runtime Performance

Client Side Rendered Tests

Framework First Paint FCP INP
SvelteKit 115.6ms 115.69ms 14.48ms

Methodology

  • Each framework renders a table of 1000 rows with two UUID columns
  • Measured using Lighthouse flow with Chromium via Puppeteer for accurate browser metrics
  • First Paint and First Contentful Paint are measured on initial navigation
  • Interaction to Next Paint is measured by clicking the first row's detail link
  • Benchmarks run 5 times and results are averaged
  • Next.js, TanStack Start, and React Router default to SSR with no per-route opt-out. Next.js wraps the client-side rendered table in a dynamic import with ssr: false to prevent build-time prerendering. TanStack Start uses its built-in spa mode. React Router disables SSR entirely via ssr: false in its config. All other frameworks (Nuxt, SvelteKit, SolidStart, Astro) disable SSR per-route without a separate build.
  • Astro uses React for its client-side rendered test: the benchmark table and detail components are React islands rendered with client:only="react", which prevents Astro from server-rendering those components and lets them render only in the browser. Astro's ClientRouter is not used for this CSR test because it enables client-side transitions and soft navigation behavior rather than client-only rendering.

Server Side Rendered Tests

Framework First Paint FCP INP
SvelteKit 68.2ms 68.06ms 0.53ms

Methodology

  • Each framework renders a table of 1000 rows with two UUID columns
  • Measured using Lighthouse flow with Chromium via Puppeteer for accurate browser metrics
  • First Paint and First Contentful Paint are measured on initial navigation
  • Interaction to Next Paint is measured by clicking the first row's detail link
  • Benchmarks run 5 times and results are averaged
  • The measured route is /server-side-rendered, and detail navigation uses /server-side-rendered/:id.

Server Side Throughput Tests

Framework Ops/sec Median Latency Body Size Duplication
Baseline HTML 846 1.202ms 96.81kb 1x
SvelteKit 434 2.244ms 183.55kb 2x

Methodology

  • Each framework renders a table of 1000 rows with two UUID columns
  • Mock HTTP requests bypass TCP overhead for accurate rendering measurement
  • Data is loaded asynchronously to simulate real-world data fetching
  • Duplication factor indicates how many times each UUID appears in the response (1x = optimal, 2x = includes hydration payload)
  • Benchmarks run for 10 seconds using tinybench
  • Astro, Nuxt, and SvelteKit handle Node.js HTTP requests natively. React Router, SolidStart, and TanStack Start use Web APIs internally, so benchmarks include the cost of their Node.js adapter layers (@react-router/node, h3, and srvx respectively)
  • Next.js defaults to React Server Components (RSC), a different rendering model than traditional server-rendered React. To keep the comparison fair, Next.js uses "use client" to opt out of RSC and use traditional server rendering + hydration like most of the other frameworks
  • Inspired by eknkc/ssr-benchmark

Server Side Load Test

Framework Peak req/s Peak Connections P99 @ 25 P99 @ 50 P99 @ 100 Total Req.
Baseline HTML 5,909.2 100 6ms 10ms 22ms 147,464
SvelteKit 543.6 10 75ms 343ms 2396ms 16,943

Methodology

  • Each framework serves the server-rendered table route over a real local HTTP server
  • The measured route is /server-side-rendered, using the same 1000-row UUID table as the SSR request throughput and browser rendering tests
  • Load is applied in staged connection counts, from 1 through 200 concurrent connections, with each stage running for approximately 5 seconds
  • Peak requests/sec is the highest successful stage throughput observed during the staged run
  • P90 and P99 latency are compared at the 25-, 50-, and 100-connection stages for every framework, so latency is measured under the same concurrency pressure
  • Total requests cover the full staged load run, not only the peak stage