Nift benchmark evidence
Fast builds.
Small footprint.
A reproducible 10,000-page clean-build comparison of Nift, Hugo, VitePress and Astro, measuring both wall-clock time and peak aggregate process-tree RSS. The same run also measures Nift's incremental development loop.
Clean production build
10,000 pages from clean output.
Median of three measured runs after one warmup. Dependency installation and fixture generation were outside the timed region. Peak RAM is aggregate RSS across the spawned process group, sampled every 10 ms on Linux.
0.1 s1 s10 s100 s+
Nift0.165 s
Hugo0.467 s
VitePress58.49 s
Astro124.79 s
10 MiB100 MiB1 GiB4 GiB
Nift10.0 MiB
Hugo237 MiB
VitePress3,687 MiB
Astro3,218 MiB
| Generator | Median time | Median peak RAM | Time vs Nift | RAM vs Nift |
|---|---|---|---|---|
| Nift | 0.165 s | 10.0 MiB | 1× | 1× |
| Hugo | 0.467 s | 237 MiB | 2.83× slower | 23.8× RAM |
| VitePress | 58.49 s | 3,687 MiB | 354.26× slower | 369.5× RAM |
| Astro | 124.79 s | 3,218 MiB | 755.81× slower | 322.5× RAM |
Scope matters.
The charts use logarithmic scales because the differences span several orders of magnitude. These ratios describe this exact 10,000-page clean-build fixture on this machine; they are not universal claims about every workload or each framework's intended dev-server/HMR experience.
Nift during iteration
The build tool stays small in the edit → verify loop.
These are Nift-only build-updated measurements on the same 10,000-page fixture. They are intentionally separate from the cross-generator clean-build comparison.
00.05 s0.10 s0.20 s
No-op0.100 s
One page changed0.119 s
Shared template changed0.176 s
04 MiB8 MiB12 MiB
No-op9.6 MiB
One page changed9.7 MiB
Shared template changed11.3 MiB
For a human, that means builds return quickly while the editor, browser and local services remain the things consuming the machine. For an agent, it means repeated edit/build/verify cycles can invoke the build system frequently without adding a large latency or memory tax.
Raw samples
The medians are backed by the measured runs.
Nift0.165 s · 10.0 MiB
time: 0.167357 · 0.165107 · 0.164769
RAM: 10.0 · 10.0 · 10.0 MiBHugo0.467 s · 237 MiB
time: 0.466992 · 0.467337 · 0.474619
RAM: 252.1 · 237.2 · 233.1 MiBVitePress58.49 s · 3,687 MiB
time: 58.183215 · 58.490923 · 58.720168
RAM: 3973.3 · 3686.7 · 3666.3 MiBAstro124.79 s · 3,218 MiB
time: 124.696826 · 124.790067 · 127.019350
RAM: 3217.5 · 3187.8 · 3283.4 MiBThe exact schema-4 evidence—including all clean-build and Nift incremental samples—is available as results.json.
Methodology
Equivalent small pages, tool-native fixtures.
Equivalent small pages generated from tool-native source; dependency installation and fixture generation are outside timed runs.
- 10,000 pages per clean-build fixture.
- 1 warmup + 3 measured runs per case.
- Generated output and relevant build caches removed between clean builds.
- Peak aggregate RSS sampled every 10 ms across each spawned process group.
- Nift incremental cases: no change, one independent page changed, and shared template changed.
- The harness refuses partial comparison evidence if a requested tool is missing or fails.
Machine
Environment recorded with the run.
- OS
- Linux 7.0.0-29-generic
- Architecture
- x86_64
- Logical CPUs
- 20
- Python
- 3.14.4
- Node
- v22.22.1
Exact tools
Versions are part of the evidence.
Reproduce it
Run the same harness yourself.
./scripts/setup-tools.sh
python3 -u scripts/benchmark.py \
--nift .benchmark-tools/nift \
--hugo .benchmark-tools/hugo \
--node-project . \
--pages 10000 \
--warmups 1 \
--repetitions 3 \
--output evidence/results.jsonsetup-tools.sh installs the official Nift release from curl -fsSL https://nift.dev/install | sh, the pinned Hugo binary, and the pinned Node dependencies into .benchmark-tools/. Set NIFT_VERSION before setup to pin a specific Nift release.
The run takes several minutes because Astro and VitePress are substantially slower on this fixture. Progress is printed before and after every phase and repetition.
Interpretation
What this does—and does not—show.
Nift was extremely quick and had a very low memory footprint on this 10,000-page clean-build workload, and remained around 10–11 MiB during the measured incremental cases.
That these ratios hold for every project, or that a clean production build is equivalent to the dev-server/HMR workflow of Astro or VitePress.
Low build latency and low memory overhead leave more machine capacity for editors, browsers, local services and repeated human or agent verification loops.