--- title: How do I reduce my build time with Next.js on Vercel? description: Reduce Next.js build times on Vercel by pre-rendering fewer pages at build time, deferring generation with ISR and image optimization, and using faster build machines. url: /kb/guide/how-do-i-reduce-my-build-time-with-next-js-on-vercel canonical_url: "https://vercel.com/kb/guide/how-do-i-reduce-my-build-time-with-next-js-on-vercel" last_updated: 2026-08-03 authors: Lee Robinson, Anthony Shew, Ismael Rumzan related: - /docs/builds - /docs/incremental-static-regeneration - /docs/cdn - /docs/incremental-static-regeneration/quickstart - /docs/image-optimization - /docs/speed-insights - /docs/builds/managing-builds - /docs/monorepos - /docs/functions/runtimes/node-js - /docs/frameworks/full-stack/nextjs - /kb/guide/troubleshooting-build-error-build-step-did-not-complete-within-45-minutes install_vercel_plugin: npx plugins add vercel/vercel-plugin --- A Next.js project that pre-renders thousands of static pages can hit Vercel's maximum build time of [45 minutes per deployment](https://vercel.com/docs/builds). When a build gets slow, it's usually because too much work happens at build time when pages, images, and data are all generated up front. You reduce build time by moving that work to free up more compute for the build. This guide covers how to improve build time, starting with page-specific changes that help most projects and ending with the infrastructure settings that can improve speed. ## Why do Next.js build times increase on Vercel? Before changing anything, it helps to know what runs during a build. When you deploy, Vercel compiles and bundles your app. Then, Next.js pre-renders every static page you've asked it to generate. The more pages, images, and data-fetching each build has to process, the longer it takes. Two factors drive most long builds: - **Page count:** Pre-rendering static pages at build time scales with the number of pages. A site with thousands of pages spends most of its build generating HTML. - **Per-page work:** Data fetching, image generation, and heavy computation repeat for every page, so slow upstream calls multiply across the build. The build timeout is 45 minutes, and there's no upper limit on the number of output files a build can create. Very large sites (100,000 files or more) are where builds slow down most. The fix is to stop doing all of that work on every build. ## Reduce build time by generating static pages on demand The most effective change for a large site is to stop pre-rendering every page at build time. Next.js lets you pre-render a small set of pages during the build and generate the rest on demand when a visitor first requests them. In the App Router, `generateStaticParams` defines which paths are built ahead of time, and `dynamicParams` controls what happens for paths you didn't list. Return an empty array to skip pre-rendering entirely, and Vercel generates each page on first request instead. Add the following to a dynamic route to skip pre-rendering during preview builds while keeping full generation in production: `export const dynamicParams = true; // generate unlisted paths on demand export async function generateStaticParams() { // In preview builds, skip pre-rendering for faster iteration. if (process.env.SKIP_BUILD_STATIC_GENERATION) { return []; } const res = await fetch(''); const posts = await res.json(); return posts.map((post) => ({ id: post.id })); }` This keeps iteration fast for previews and reserves full pre-rendering for production, where the initial load benefits most. If you use the Pages Router, the equivalent is [`getStaticPaths`](https://nextjs.org/docs/pages/api-reference/functions/get-static-paths) with `fallback: 'blocking'` and the same `SKIP_BUILD_STATIC_GENERATION` check. Generating on demand keeps the build short, and the next section keeps those on-demand pages fast. ## How to use ISR to keep Next.js build times low Generating pages on demand requires considering how those pages stay fast and current without a rebuild. [Incremental Static Regeneration (ISR)](https://vercel.com/docs/incremental-static-regeneration) helps by caching each generated page and refreshing it in the background, so you create or update content without redeploying. ISR helps your build time in three ways: - **Deferred generation:** Pages generate on request or through an API call instead of during the build, so build time stays flat as your content grows. - **Durable caching:** Vercel stores generated pages in durable storage next to your function region and serves them from the [CDN](https://vercel.com/docs/cdn). A page generates once and stays cached for up to 31 days or until you revalidate it. - **Selective pre-rendering:** You can pre-render popular pages at build time and let the rest generate on demand, which shortens the build without hurting your most-visited routes. In the App Router, enable time-based ISR by exporting a `revalidate` value from a route segment: `export const revalidate = 3600; // regenerate at most once per hour` For updates that can't wait for an interval, call [`revalidatePath`](https://vercel.com/docs/incremental-static-regeneration/quickstart#on-demand-revalidation) or `revalidateTag` from a route handler to refresh specific pages on demand. Either way, generation moves off the build to keep deployments under the 45-minute limit. ## How on-demand image optimization keeps your builds fast Images are the other common source of build-time work. If your build generates and optimizes every image up front, it adds time that scales with your image count. Vercel avoids this by optimizing images on demand instead. When you deploy Next.js to Vercel, the `next/image` component and [Image Optimization](https://vercel.com/docs/image-optimization) transform images the first time they're requested, then cache the result on the CDN for up to 31 days. Nothing is generated during the build, so adding images doesn't lengthen your deployments. Visitors still get correctly sized, modern formats that improve your [Core Web Vitals](https://vercel.com/docs/speed-insights). Deferring image work keeps the build focused on code, and the last lever addresses the build machine itself. ## How to speed up builds with larger machines and caching Once you've moved page and image generation off the build, you can make the remaining build run faster with infrastructure settings. These help every project, including ones that can't defer much work. Consider these options in the [build settings](https://vercel.com/docs/builds/managing-builds): - **Larger build machines:** Pro and Enterprise teams can run builds on Enhanced (8 vCPUs) or Turbo (30 vCPUs) machines instead of Standard (4 vCPUs). CPU-bound builds, such as heavy bundling or type checking, finish sooner on more vCPUs. - **Elastic build machines:** Elastic is the default for new paid teams and auto-scales the machine size (4 to 30 vCPUs) to each project's workload, so builds that need more compute get it without manual tuning. - **Build cache:** Vercel caches dependencies between builds, up to 1 GB retained for one month, so subsequent deployments skip repeated install work. - **Skip unaffected projects:** In a [monorepo](https://vercel.com/docs/monorepos), Vercel detects which projects changed and skips building the ones that didn't, which avoids unnecessary build minutes. - **Update your Node.js version:** Building on a current [Node.js version](https://vercel.com/docs/functions/runtimes/node-js) picks up runtime performance improvements. You set the build machine type in the **Build and Deployment** section of your team or project settings. Combining a right-sized machine with deferred generation is what keeps large Next.js builds well within the timeout. ## Next steps With generation deferred and the right build machine selected, apply these settings to an existing project, start fresh with a [new Vercel project](https://vercel.com/new), or pick from [the Next.js templates](https://vercel.com/templates/next.js). ## Related resources - [Builds on Vercel](https://vercel.com/docs/builds) - [Managing builds and larger build machines](https://vercel.com/docs/builds/managing-builds) - [Incremental Static Regeneration (ISR)](https://vercel.com/docs/incremental-static-regeneration) - [Image Optimization](https://vercel.com/docs/image-optimization) - [Next.js on Vercel](https://vercel.com/docs/frameworks/full-stack/nextjs) - [Troubleshooting the 45-minute build error](https://vercel.com/kb/guide/troubleshooting-build-error-build-step-did-not-complete-within-45-minutes) ## Frequently asked questions ### What is the maximum build time for a Vercel deployment? Vercel terminates any build that runs longer than 45 minutes, and the deployment fails. This limit applies to every plan. If your builds approach it, move page and image generation off the build with on-demand generation and ISR, or run the build on a larger machine. ### Why does my Next.js build take so long on Vercel? Long Next.js builds usually come from pre-rendering too many static pages at build time. Each page runs its data fetching and rendering during the build, so a site with thousands of pages spends most of its build generating HTML. Deferring that generation is the most effective fix. ### How can I reduce Next.js build times without changing my code? You can shorten builds through settings alone. Switch to an Enhanced, Turbo, or Elastic build machine for more vCPUs, rely on Vercel's build cache for dependencies, and in a monorepo, let Vercel skip projects that didn't change. These reduce build time without touching application code. ### Does Incremental Static Regeneration reduce build times? Yes. ISR defers page generation from build time to request time, then caches each page and refreshes it in the background. Because pages generate on demand rather than all at once during the build, your build time stays roughly constant even as your page count grows.