โ All frameworks 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.20s | 1.18s | 1.21s |
| Cold Build | 2.36s | 2.25s | 2.70s |
| Warm Build | 2.29s | 2.25s | 2.33s |
Build output size: 1.29MB
Duplicate Dependencies
1 duplicate dependency
detected across this starter's node_modules.
View 1 duplicate dependency
Runtime Performance
SSR Load Tests
| Framework | Peak req/s | Peak Connections | P99 @ 25 | P99 @ 50 | P99 @ 100 | Total Req. |
| Baseline HTML | 5,950.8 | 200 | 7ms | 11ms | 25ms | 146,571 |
| SvelteKit | 525 | 25 | 74ms | 328ms | 2381ms | 16,789 |
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
SSR Request Throughput
| Framework | Ops/sec | Median Latency | Body Size | Duplication |
| Baseline HTML | 823 | 1.205ms | 96.81kb | 1x |
| SvelteKit | 441 | 2.201ms | 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
Client Side Rendered Performance
| Framework | First Paint | FCP | INP |
| SvelteKit | 104.8ms | 104.85ms | 13.71ms |
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.
Server Side Rendered Performance
| Framework | First Paint | FCP | INP |
| SvelteKit | 70.8ms | 70.85ms | 0.59ms |
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.