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.
| 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 |
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.
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.
time: 0.167357 · 0.165107 · 0.164769
RAM: 10.0 · 10.0 · 10.0 MiBtime: 0.466992 · 0.467337 · 0.474619
RAM: 252.1 · 237.2 · 233.1 MiBtime: 58.183215 · 58.490923 · 58.720168
RAM: 3973.3 · 3686.7 · 3666.3 MiBtime: 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.
Nift v4.0.7hugo v0.164.0-ce2470e7012b5ab5fc4e10ebe4027e9f8d9e00dc linux/amd64 BuildDate=2026-07-06T16:39:30Z VendorInfo=gohugoioAstro 7.2.4VitePress 1.6.4Reproduce it
Run the same harness yourself.
./scripts/setup-tools.sh
python3 -u scripts/benchmark.py \
--nift /path/to/nift \
--hugo .benchmark-tools/hugo \
--node-project . \
--pages 10000 \
--warmups 1 \
--repetitions 3 \
--output evidence/results.json
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.