fix(build): cut Cloudflare build time

[dcrawbuck]

Summary

Goal: get the Cloudflare build under 5–7 minutes. Local benchmarks dropped from 109s to ~85s (~23% faster), with bigger gains on warm builds once the new MDX cache is populated.

• Combine post-build scripts into scripts/generate-static-assets.ts — the old pipeline cold-started two separate Vite SSR servers and re-evaluated the same fumadocs MDX collection in each. One server, both jobs in parallel, saves ~16s.
• async: true for the docs MDX collection in production — page MDX is dynamically imported instead of inlined into the SSR bundle. Pages still fully prerender to static HTML, so no end-user behavior change. Bonus: client main bundle 18 MB → 1.9 MB (10× smaller), SSR bundle 30 MB → 256 KB.
• Enable fumadocs-mdx experimentalBuildCache at node_modules/.cache/fumadocs-mdx — Cloudflare Pages persists node_modules between deploys with build caching on, so unchanged MDX files skip Shiki + remark on warm builds.
• Prerender concurrency = os.cpus().length instead of hardcoded 3.
• Add bun run measure:build — phase-by-phase timing for future tuning, results land in .context/build-timings/.

Test plan

• CI green (bun test, bun run build:cf)
• Cloudflare staging deploy succeeds and the build is faster than main
• Spot-check a few pages render correctly (incl. one with code blocks and one with mermaid)
• Client-side nav still works (the static __sfn_cache/*.json files load on prefetch)
• Search dialog returns results (search-index.json loads)

---

Note

^{Cursor Bugbot is generating a summary for commit 01ac397. Configure here.}

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	superwall-docs-staging	960d598	Apr 29 2026, 02:33 AM

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 01ac397. Configure here.}

[cursor]

os.cpus().length may be zero or excessive in containers

Medium Severity

os.cpus() can return an empty array in certain containerized environments (documented Node.js behavior when /proc CPU info is unavailable), making os.cpus().length equal to 0. A concurrency of 0 would likely cause the prerender step to hang or error. Even when it doesn't return empty, in containers like Cloudflare's builders it often reports the host machine's CPU count rather than the container's allocation, which could trigger the OOM the previous hardcoded 3 was guarding against. Using os.availableParallelism() (available in both Node.js 19+ and Bun) is safer — it always returns ≥ 1 and better respects cgroup limits.

 

^{Reviewed by Cursor Bugbot for commit 01ac397. Configure here.}