Recommended Free Tools
Choose static export when a route’s content can be generated at build time and static hosting is sufficient. Choose Incremental Static Regeneration (ISR) when a pre-rendered page can be served from cache but needs timed or on-demand updates. Choose server-side rendering (SSR) when the response must be calculated for each request. In Next.js, you can make that choice route by route rather than forcing one rendering strategy on an entire site.
Static export vs. ISR vs. SSR at a glance
| Strategy | When output is produced | How it gets fresh | Deployment requirement | Main trade-off |
|---|---|---|---|---|
| Static export | At build time | Rebuild and redeploy changed output | A static web server that serves HTML, CSS, and JavaScript | Minimal runtime needs, but no live Next.js server features such as ISR |
| ISR | At build time, then during regeneration | Time-based revalidation or on-demand invalidation | A supported Next.js runtime or platform | Serves cached pages with a freshness window; self-hosted cache coordination may require care |
| SSR | For each request in the Pages Router’s getServerSideProps model |
Renders again on each request | A server runtime | Can use request-time data, at the cost of server work for each request |
These descriptions follow the current Next.js documentation: static exports, ISR, and the Pages Router’s server-side data-fetching API. Router and deployment details vary, so check the documentation for the router and Next.js version your project uses.
As an Amazon Associate I earn from qualifying purchases.
When should you use static export?
Use static export when you can produce every required route and its data during the build, and your deployment only needs to serve the resulting files. With output: 'export' configured, next build generates static HTML and assets in an out directory under the documented configuration. Those files can be hosted on a static web server.
Free tools Windows power users keep installed
One-click scans. No signup required.
This is a strong candidate for content that changes only when you publish a new build. Next.js identifies marketing pages, blogs, portfolios, product listings, help centers, and documentation as examples of content that can often be statically generated. Its SEO guide recommends asking: “Can I pre-render this page ahead of a user’s request?” The Next.js Static Site Generation guide says prebuilt pages can be served by a CDN, avoiding a server render on every request.
#1 Best Overall
Check whether the static-export limits fit
A static export has no live Next.js server to handle requests. The Next.js static export guide lists server-dependent features that are unavailable in this mode, including ISR, request-dependent route handling, cookies, headers, rewrites, redirects, Proxy, Server Actions, and default image optimization. Dynamic routes must also be known and generated at build time.
If a route needs one of those server features, you can redesign that route or deploy the application with a runtime. Export remains suitable for other routes that do not need them.
Rank #2
When should you use ISR?
Use ISR when a page can be cached and pre-rendered, but should update after deployment without rebuilding the whole site. You can set a revalidation interval or invalidate cached content on demand after an event such as a content update. That makes ISR useful for large content collections where generating every page anew at build time is unwieldy, or for pages where updates should appear without a full rebuild.
ISR is not available with static export: it needs a running Next.js environment. The App Router ISR guide documents Node.js runtime and Docker deployment support, and notes that static export is unsupported. Platform adapters may affect deployment options.
Pick revalidation based on the content workflow
A time interval defines how long cached output may remain before it is eligible for refresh; it is not a promise that every visitor will receive a newly rendered page at an exact interval. If an update event is known and freshness should follow that event, on-demand invalidation gives you more direct control. The Next.js guide uses a one-hour interval rather than one second as a general example, not as a universal freshness target. Set the interval to match how quickly the content must change and how much regeneration your application can support.
Plan cache behavior for self-hosting
For a self-hosted deployment, Next.js stores ISR output in its server cache, which is local to each server by default. A persistent single instance works automatically. If you run multiple instances or ephemeral compute, arrange shared cache persistence or coordination so instances do not operate on inconsistent cached pages. Review CDN or reverse-proxy configuration as well: a CDN does not itself perform Next.js on-demand invalidation. The Next.js self-hosting guide covers cache coordination considerations.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When should you use SSR?
Use SSR when the response needs information available only at request time—for example, when it depends on the current request—or when the page must reflect frequently updated data on each request. In the Pages Router, getServerSideProps runs for every request. The API documentation describes that behavior.
Rendering each time gives the server a chance to build a response from current request conditions, but also creates per-request server work. Next.js explains that serving a prebuilt page from a CDN is faster than having a server render it on every request in its static-generation guide. Do not choose SSR merely because a page needs to be visible to search engines: static generation and SSR both provide pre-rendered HTML on initial load. Choose SSR when the request-time requirement justifies it.
How to choose for a route
- Ask whether you can pre-render the page. If its content and route are known at build time, start with static generation or export. If the answer is no because the response depends on the request, consider SSR.
- Decide how fresh cached content must be. If updates can wait for a rebuild, static export may fit. If a cached page should refresh after a defined interval or content event, use ISR with a server-capable deployment.
- Check runtime and feature requirements. Confirm that the hosting environment supports the server features the route needs. If static export is required, redesign or separate routes that need server-only behavior.
- Account for build size and cache operations. For a very large page set, ISR can avoid generating everything anew on each build. For self-hosted ISR across instances, plan cache persistence and coordination.
Can a Next.js site mix rendering strategies?
Yes. Next.js rendering methods can be applied per page or route. A site might export stable marketing pages, use ISR for editorial content that needs scheduled or event-triggered updates, and use SSR for pages whose output depends on the request. This lets each route use the least complex strategy that still meets its freshness and functionality requirements, rather than making every page pay the operational cost of SSR.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
