โ 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.17s | 1.11s | 1.30s |
| Cold Build | 2.38s | 2.32s | 2.44s |
| Warm Build | 2.35s | 2.26s | 2.45s |
Build output size: 1.29MB
Duplicate Dependencies
1 duplicate dependency
detected across this starter's node_modules.
View 1 duplicate dependency
Runtime Performance
Client Side Rendered Tests
| Framework | First Paint | FCP | INP |
| SvelteKit | 107.4ms | 107.49ms | 10.22ms |
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 wraps the client-side rendered table in a
dynamic import
with ssr: false to prevent build-time prerendering
- TanStack Start, Nuxt, SvelteKit, and SolidStart disable SSR per-route
-
React Router uses route-level
clientLoader functions with HydrateFallback so the client-rendered routes are not server-rendered
- Astro uses client-only React islands for client-side rendered routes
-
Client-side rendered tests use each framework's normal production build
because SPA-only build modes are not supported consistently across the
frameworks being compared
-
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 | 79.4ms | 79.36ms | 16.55ms |
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 | 625 | 1.588ms | 184.7kb | 1.5x |
| SvelteKit | 356 | 2.686ms | 271.38kb | 2.5x |
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 | 1,619.6 | 50 | 19ms | 41ms | 98ms | 48,121 |
| SvelteKit | 492 | 25 | 80ms | 407ms | 2452ms | 15,637 |
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