perf(next-plugin): profile and reuse Turbopack prewarm output

[owjs3901]

Summary

• add opt-in structured Turbopack timings for graph setup, production prewarm, coordinator extraction, snapshots, serialization, and writes
• reuse byte-identical singleCss prewarm output so Turbopack loaders do not repeat WASM extraction
• keep polymorphic React inference exact while preventing redundant native-prop inference and duplicate intrinsic-prop conditionals
• build a lite extraction engine without Boa/vanilla-extract for ordinary Devup source graphs, while retaining the full engine whenever .css.ts or .css.js is present
• defer the Webpack adapter so Turbopack startup loads only the selected WASM engine
• stabilize the existing benchmark.js comparison in the existing Publish workflow: remove Next memory-debug overhead, alternate order, clean Next/Devup output for every sample, and report six-sample medians

No separate benchmark workflow was added.

Memory and startup impact

• full WASM: 4,189,351 bytes
• lite WASM: 1,182,403 bytes (71.8% smaller)
• measured incremental Node RSS across five fresh processes: full about 9.0–11.0 MB, lite about 2.35–2.74 MB
• requiring the built Next plugin entry loads no WASM or Webpack adapter
• executing the Turbopack config for the benchmark fixture loads only pkg/lite/index.js; the full WASM and Webpack adapter are absent from require.cache

The normal package keeps the existing full feature set. The lite engine is selected only when the static graph succeeds and contains no source or resolved external .css.ts/.css.js candidate; graph failure deliberately falls back to full.

Validation

• wasm-pack release builds completed for both full and lite packages; no Windows security-policy bypass was used
• Next plugin tests: 118 passed, 0 failed; every Next plugin source file reports 100% line/function coverage
• extractor tests: 1,377 passed, 0 failed
• WASM tests: 33 passed, 0 failed
• Rust fmt and Clippy passed with default/all features and with no default features
• React TypeScript 6 and TypeScript 7 custom-shorthand/inference checks passed; no public React declaration was changed by the WASM work
• package entry point and tarball validation, lint, the full test suite, both landing Next E2E modes, benchmark, and Codecov patch checks pass in CI
• CI run and benchmark retry: https://github.com/dev-five-git/devup-ui/actions/runs/33203638990

Existing benchmark.js CI result

Two six-sample attempts at 21fd3cc1 used the existing workflow and normal next build:

Attempt	Devup UI singleCss Turbo	Tailwind Turbo	Difference
1	6.87 s	6.90 s	Devup UI 30 ms faster
2	6.60 s	6.57 s	Devup UI 30 ms slower

Raw wall samples:

• attempt 1 Tailwind: 7.14, 7.06, 6.91, 6.88, 6.86, 6.63 s
• attempt 1 Devup: 7.10, 6.99, 6.79, 6.91, 6.82, 6.78 s
• attempt 2 Tailwind: 6.56, 6.49, 6.55, 6.63, 6.61, 6.59 s
• attempt 2 Devup: 6.48, 6.60, 6.53, 6.60, 6.60, 6.61 s

The median of the 12 same-ordinal Devup-minus-Tailwind deltas is -25 ms, but the two attempt medians split exactly ±30 ms. The defensible conclusion is parity within CI runner noise, not a general performance victory. Typical Devup config time fell from about 90–95 ms before the deferred Webpack fix to 71–76 ms in the retry (Tailwind 11–12 ms). Devup compiled in 3.7–3.8 s versus Tailwind 3.9–4.0 s in that retry, while its richer types took about 333–344 ms versus Tailwind 244–255 ms.

The earlier lite-WASM run still loaded the full engine through the top-level Webpack adapter and measured Devup 7.42 s versus Tailwind 7.30 s. Removing that hidden full-engine load is what changed the config-time and memory behavior.

Structured timings put CSS/sheet/class/file serialization below 1 ms, so batching or debouncing it would add complexity without addressing the measured bottleneck. A Rust/WASM -O3 experiment was also rejected: it increased WASM size and package-build time and produced a 7.61 s Devup median versus 6.95 s Tailwind. The compact z/-Oz settings remain.

Benchmark limits

This is fairer than the previous one-shot fixed-order benchmark, but it is not proof that one library is generally faster. The fixtures are not semantically identical: Tailwind uses untyped class strings and emits its framework CSS, while Devup validates responsive and polymorphic props and emits much less CSS (327 versus 6,197 bytes in the measured fixtures). Next and Devup output caches are removed between samples, and both competitors receive the same treatment, but tsconfig.tsbuildinfo is not removed; these samples are therefore build-output cold, not TypeScript-incremental-state cold. Disabling type checking or weakening inference would reverse the goal and was deliberately not done.

bun.lock remains unrelated and is excluded from every commit. The add-bench PR was not touched.

[github-actions]

Changepacks

@devup-ui/wasm@1.0.78 - bindings/devup-ui-wasm/package.json

Maybe you forgot to write the following files to the latest version

@devup-ui/next-plugin@1.0.83 - packages/next-plugin/package.json

Maybe you forgot to write the following files to the latest version

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
bindings/devup-ui-wasm/src/lib.rs	100.00% <100.00%> (ø)
libs/extractor/src/lib.rs	100.00% <100.00%> (ø)
packages/next-plugin/src/coordinator.ts	100.00% <100.00%> (ø)
packages/next-plugin/src/css-loader.ts	100.00% <100.00%> (ø)
packages/next-plugin/src/loader.ts	100.00% <100.00%> (ø)
packages/next-plugin/src/plugin.ts	100.00% <100.00%> (ø)
packages/next-plugin/src/profile.ts	100.00% <100.00%> (ø)
packages/next-plugin/src/wasm.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.