How to optimize your local development environment
Learn how to optimize your local development environment with Next.js.
Next.js is designed to provide a great developer experience. As your application grows, you might notice slower compilation times during local development. This guide will help you identify and fix common compile-time performance issues.
Local dev vs. production
The development process with next dev is different than next build and next start.
next dev compiles routes in your application as you open or navigate to them. This enables you to start the dev server without waiting for every route in your application to compile, which is both faster and uses less memory. Running a production build applies other optimizations, like minifying files and creating content hashes, which are not needed for local development.
System configuration
1. Check your computer's antivirus
Antivirus software can slow down file access. While this is more common on Windows machines, this can be an issue for any system with an antivirus tool installed.
On Windows, you can add your project to the Microsoft Defender Antivirus exclusion list.
- Open the "Windows Security" application and then select "Virus & threat protection" → "Manage settings" → "Add or remove exclusions".
- Add a "Folder" exclusion. Select your project folder.
Alternatively, you can enable and use a Dev Drive, which uses Microsoft Defender's "performance mode".
On macOS, you can disable Gatekeeper inside of your terminal.
- Run
sudo spctl developer-mode enable-terminalin your terminal. - Open the "System Settings" app and then select "Privacy & Security" → "Developer Tools".
- Ensure your terminal is listed and enabled. If you're using a third-party terminal like iTerm or Ghostty, add that to the list.
- Restart your terminal.


If you or your employer have configured any other Antivirus solutions on your system, you should inspect the relevant settings for those products.
2. Avoid common Docker pitfalls
If you're using Docker for development on Mac or Windows, you may experience significantly slower performance compared to running Next.js without Docker.
This generally isn't an issue in production or when Docker runs natively on Linux, because project files don't cross Docker Desktop's host-to-VM file-sharing layer.
When project files are stored on the macOS or Windows host and mounted into a container through Docker Desktop or similar tools, the host-to-VM file-sharing layer can delay or fail to propagate filesystem events. This can cause Fast Refresh to take seconds or even minutes, while the same application shows updates quickly when developed on the host without Docker.
For the best development experience:
- Run Next.js without Docker (
npm run devorpnpm dev) during development. - Reserve Docker for production deployments and testing production builds.
- If you must use Docker for development, consider running Docker natively on a Linux machine or a manually configured virtual machine. If using a manually configured virtual machine, move the source code into the VM and do not share it from the host.
- If you're using Docker Desktop, evaluate using synchronized file shares. Synchronized file shares still add latency compared to running Next.js directly on the host, but can improve file-watching reliability without resorting to polling.
- Avoid using
watchOptions.pollIntervalMsinnext.config.jsto work around Fast Refresh issues. Only use it as a last resort. Polling adds significant latency and can drastically increase CPU and I/O usage.
Learn more about Docker deployment for production use.
3. (Windows) Use Dev Drive or WSL 2
Windows 11's Dev Drive feature uses an alternative filesystem to improve performance for common development workflows. Microsoft has a guide explaining how to configure it.
Alternatively, Windows provides an easy way to set up a Linux virtual machine using Windows Subsystem for Linux. You may see better performance by using WSL 2.
When using WSL 2, store your project directory inside the virtual machine's filesystem (e.g. /home/$USER/project) and not on a Windows drive (e.g. C:\ or /mnt/c). If you do not do this, you will experience worse performance and file updates may not be reflected properly in development.
Improving application development performance
1. Update Next.js and use Turbopack
Make sure you're using the latest version of Next.js. Each new version often includes performance improvements.
Turbopack is now the default bundler for Next.js development and provides significant performance improvements over webpack.
If you need to use Webpack instead of Turbopack, you can opt-in:
Learn more about Turbopack. See our upgrade guides and codemods for more information.
2. Check your imports
The way you import code can greatly affect compilation and bundling time. Learn more about optimizing package bundling and explore tools like Dependency Cruiser or Madge.
Icon libraries
Libraries like @material-ui/icons, @phosphor-icons/react, or react-icons can import thousands of icons, even if you only use a few. Try to import only the icons you need:
You can often find what import pattern to use in the documentation for the icon library you're using. This example follows @phosphor-icons/react recommendation.
Libraries like react-icons includes many different icon sets. Choose one set and stick with that set.
For example, if your application uses react-icons and imports all of these:
pi(Phosphor Icons)md(Material Design Icons)tb(tabler-icons)cg(cssgg)
Combined they will be tens of thousands of modules that the compiler has to handle, even if you only use a single import from each.
Barrel files
"Barrel files" are files that export many items from other files. They can slow down builds because the compiler has to parse them to find if there are side-effects in the module scope by using the import.
Try to import directly from specific files when possible. Learn more about barrel files and the built-in optimizations in Next.js.
Optimize package imports
Next.js can automatically optimize imports for certain packages. If you are using packages that utilize barrel files, add them to your next.config.js:
Turbopack automatically analyzes imports and optimizes them. It does not require this configuration.
3. Check your Tailwind CSS setup
If you're using Tailwind CSS, make sure it's set up correctly.
A common mistake is configuring your content array in a way which includes node_modules or other large directories of files that should not be scanned.
Tailwind CSS version 3.4.8 or newer will warn you about settings that might slow down your build.
-
In your
tailwind.config.js, be specific about which files to scan: -
Avoid scanning unnecessary files:
4. Check custom webpack settings
If you've added custom webpack settings, they might be slowing down compilation.
Consider if you really need them for local development. You can optionally only include certain tools for production builds, or explore using the default Turbopack bundler and configuring loaders instead.
5. Optimize memory usage
If your app is very large, it might need more memory.
Learn more about optimizing memory usage.
6. Server Components and data fetching
Changes to Server Components cause the entire page to re-render locally in order to show the new changes, which includes fetching new data for the component.
The experimental serverComponentsHmrCache option allows you to cache fetch responses in Server Components across Hot Module Replacement (HMR) refreshes in local development. This results in faster responses and reduced costs for billed API calls.
Learn more about the experimental option.
Tools for finding problems
Detailed fetch logging
Use the logging.fetches option in your next.config.js file, to see more detailed information about what's happening during development:
Learn more about fetch logging.
Turbopack tracing
Turbopack tracing is a tool that helps you understand the performance of your application during local development. It provides detailed information about the time taken for each module to compile and how they are related.
-
Make sure you have the latest version of Next.js installed.
-
Generate a Turbopack trace file:
-
Navigate around your application or make edits to files to reproduce the problem.
-
Stop the Next.js development server.
-
A file called
trace-turbopack.binwill be available in the.next-profilesfolder. -
You can interpret the file using
npx next internal trace [path-to-file]:On versions where
traceis not available, the command was namedturbo-trace-server: -
Once the trace server is running you can view the trace at https://trace.nextjs.org/.
-
By default the trace viewer will aggregate timings, in order to see each individual time you can switch from "Aggregated in order" to "Spans in order" at the top right of the viewer.
Good to know: The trace file is placed in the .next-profiles directory at the project root.
Still having problems?
Share the trace file generated in the Turbopack Tracing section and share it on GitHub Discussions or Discord.

