mirror of
https://github.com/cloudflare/vinext.git
synced 2026-05-09 08:25:34 +02:00
[GH-ISSUE #9] Static pre-rendering at build time #1
Labels
No labels
enhancement
enhancement
good first issue
help wanted
nextjs-tracking
nextjs-tracking
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vinext#1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @southpolesteve on GitHub (Feb 24, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/9
Summary
Next.js pre-renders static pages to HTML at build time. Pages without dynamic data fetching get rendered once during
next build, and the resulting HTML is served directly without any server-side work at request time.vinext currently does not do this. All pages are server-rendered on the first request, then cached via ISR. This works well for most apps, but purely static sites don't get the benefit of zero-compute serving from the start.
Why it matters
generateStaticParams()is a commonly used Next.js API. Supporting it expands the set of apps that can migrate to vinext without changes.Current workaround
vinext supports ISR out of the box. After the first request to any page, it's cached and revalidated in the background. For most production apps with any amount of traffic, the practical difference is minimal: one cold render per page after deploy.
For sites that are 100% static content with no dynamic routes, a static-first framework like Astro may be a better fit today.
What pre-rendering would look like
vinext build, identify pages that are fully static (nocookies(),headers(), dynamic data fetching, etc.)generateStaticParams(), enumerate the params and pre-render each variantTraffic-aware Pre-Rendering (TPR)
We're also experimenting with an alternative approach: instead of pre-rendering every page at build time, query Cloudflare's zone analytics to identify which pages actually receive traffic and only pre-render those. See the blog post for details.
This is available today behind
vinext deploy --experimental-tpr.Status
This is on the roadmap. Contributions welcome.
@noxify commented on GitHub (Feb 24, 2026):
did the rsc ssg part with
generateStaticParamssupport some months ago as experiment.Maybe it helps the AI to get some inspiration ;)
@riderx commented on GitHub (Feb 24, 2026):
There is a big use case of pre render build time you missing in Nextjs.
Mobile apps!
My biggest SEO article is https://capgo.app/blog/building-a-native-mobile-app-with-nextjs-and-capacitor/
It drives me the most traffic, basically they publish they endpoint as API and use the buildJS in web and mobile.
This make one codebase run it all and it's quite convenient!
I'm waiting for this feature to be release and then I do the same article for vinext
@stavros-k commented on GitHub (Feb 26, 2026):
Please when implementing this, consider not erroring out whe
generateStaticParamsreturn an empty array. Just don't render anything on that route!https://github.com/vercel/next.js/issues/61213
@Meldiron commented on GitHub (Feb 27, 2026):
When implementing this, please consider scenario of static build while paths have dynamic sections
/articles/[slug], andpage.tsxdoes not havegenerateStaticParams.This is common SPA scenario with client-side data fetching which Next.js currently does not support and community has been asking and following this topic for years. There was even moment when Next.js promised it in minor version, and 2 major versions later, we still dont have it.
One huge (out of many) related discussions: https://github.com/vercel/next.js/discussions/55393
@jon-hotaisle commented on GitHub (Mar 8, 2026):
I don't know if this is helpful or not, but I managed to convince AI to render our website as static. I don't even know if it is correct, I didn't bother to read the code, but the output seems fine...
https://github.com/hotaisle/hotaisle-website/blob/main/scripts/build_static.ts
@james-elicx commented on GitHub (Mar 16, 2026):
Opt-in pre-rendering functionality has been merged in for build-time and deploy-time, however, that does not represent a complete feature as there are several other things required for it to be fully usable by deployed applications, and it should be considered somewhat experimental at the moment. Therefore, I'm leaving this issue open with several sub-issues attached.
@JamesbbBriz commented on GitHub (Mar 28, 2026):
I'd like to pick up #563 (configurable concurrency + RSC dedup) and #564 (E2E test fixture for static exports) — planning to bundle them into a single PR.
I've been running vinext on Cloudflare Workers in production (Prisma + Hyperdrive) and have hands-on experience with the pre-render pipeline. Will start with the E2E fixture and layer in the concurrency flag on top.
Let me know if there's anything to be aware of before I start!
@james-elicx commented on GitHub (Mar 28, 2026):
Hi @JamesbbBriz, thanks for the interest! E2Es for the static export fixture were just merged in as another contributor submitted a PR to add some, but more are always welcome!
Feel free to raise PRs as you go :)