TL;DR. Prerendering generates a page's full HTML once, ahead of time, either at build time or on a schedule, and serves that cached snapshot repeatedly instead of rebuilding it on every request. Next.js's Static Site Generation and Incremental Static Regeneration are the most widely used implementations, and the core distinction from server-side rendering is timing: SSR rebuilds fresh per request, prerendering builds once and reuses the result.
What is prerendering?
Prerendering produces a static HTML file for a given URL before anyone actually requests it, then serves that same file, typically from a cache or CDN, to every visitor and crawler until it's regenerated. Because the work happens once regardless of how many times the page is viewed afterward, prerendering is cheaper at scale than server-side rendering for content that doesn't change on every request.
Key highlights
- Next.js's getStaticProps and getStaticPaths generate pages at build time, the standard modern implementation of prerendering in a widely used framework.
- Incremental Static Regeneration extends prerendering to pages that update periodically, rebuilding a page's static snapshot in the background on a schedule without requiring a full site rebuild for every content change.
- Prerendering can also refer to a bot-specific workaround, generating a static snapshot specifically to serve crawlers, a technique closely related to dynamic rendering though the two terms overlap depending on the source.
When prerendering fits better than SSR
Content that changes rarely, marketing pages, documentation, most blog posts, gains nothing from being rebuilt fresh on every single request; prerendering does the work once and reuses the result, which is faster to serve and cheaper to run at scale. Content that genuinely changes per request, a personalized dashboard, live pricing, real-time inventory, needs SSR or client-side data fetching instead, since a stale cached snapshot would show wrong information.
Choosing between build-time and scheduled regeneration
- Build-time generation fits content that rarely changes and can tolerate a full rebuild whenever it does, most marketing and documentation pages.
- Incremental regeneration fits content that updates periodically at a predictable interval, product pages with changing stock or pricing, without needing a full site rebuild for every change.
Frequently asked questions
How is prerendering different from server-side rendering?
Timing. SSR rebuilds HTML fresh for every request; prerendering builds it once ahead of time and reuses that same cached output across many requests.
Can prerendered content go stale?
Yes, that's the core tradeoff. Without a regeneration mechanism like ISR, a prerendered page keeps serving its original snapshot until manually rebuilt, even after the underlying data changes.
Is prerendering better for SEO than SSR?
Not inherently better, since both give crawlers complete HTML immediately. The choice between them is mostly about cost and freshness requirements rather than a difference in crawlability.