|
| 1 | +--- |
| 2 | +title: Local Development |
| 3 | +description: Learn how to optimize your local development environment with Next.js. |
| 4 | +--- |
| 5 | + |
| 6 | +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. |
| 7 | + |
| 8 | +## Local dev vs. production |
| 9 | + |
| 10 | +The development process with `next dev` is different than `next build` and `next start`. |
| 11 | + |
| 12 | +`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. |
| 13 | + |
| 14 | +## Improving local dev performance |
| 15 | + |
| 16 | +### 1. Check your computer's antivirus |
| 17 | + |
| 18 | +Antivirus software can slow down file access. |
| 19 | + |
| 20 | +Try adding your project folder to the antivirus exclusion list. While this is more common on Windows machines, we recommend this for any system with an antivirus tool installed. |
| 21 | + |
| 22 | +### 2. Update Next.js and enable Turbopack |
| 23 | + |
| 24 | +Make sure you're using the latest version of Next.js. Each new version often includes performance improvements. |
| 25 | + |
| 26 | +Turbopack is a new bundler integrated into Next.js that can improve local performance. |
| 27 | + |
| 28 | +```bash |
| 29 | +npm install next@latest |
| 30 | +npm run dev --turbopack |
| 31 | +``` |
| 32 | + |
| 33 | +[Learn more about Turbopack](/blog/turbopack-for-development-stable). See our [upgrade guides](/docs/app/building-your-application/upgrading) and codemods for more information. |
| 34 | + |
| 35 | +### 3. Check your imports |
| 36 | + |
| 37 | +The way you import code can greatly affect compilation and bundling time. Learn more about [optimizing package bundling](/docs/app/building-your-application/optimizing/package-bundling) and explore tools like [Dependency Cruiser](https://github.com/sverweij/dependency-cruiser) or [Madge](https://github.com/pahen/madge). |
| 38 | + |
| 39 | +### Icon libraries |
| 40 | + |
| 41 | +Libraries like `@material-ui/icons` or `react-icons` can import thousands of icons, even if you only use a few. Try to import only the icons you need: |
| 42 | + |
| 43 | +```jsx |
| 44 | +// Instead of this: |
| 45 | +import { Icon1, Icon2 } from 'react-icons/md' |
| 46 | + |
| 47 | +// Do this: |
| 48 | +import Icon1 from 'react-icons/md/Icon1' |
| 49 | +import Icon2 from 'react-icons/md/Icon2' |
| 50 | +``` |
| 51 | + |
| 52 | +Libraries like `react-icons` includes many different icon sets. Choose one set and stick with that set. |
| 53 | + |
| 54 | +For example, if your application uses `react-icons` and imports all of these: |
| 55 | + |
| 56 | +- `pi` (Phosphor Icons) |
| 57 | +- `md` (Material Design Icons) |
| 58 | +- `tb` (tabler-icons) |
| 59 | +- `cg` (cssgg) |
| 60 | + |
| 61 | +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. |
| 62 | + |
| 63 | +### Barrel files |
| 64 | + |
| 65 | +"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. |
| 66 | + |
| 67 | +Try to import directly from specific files when possible. [Learn more about barrel files](https://vercel.com/blog/how-we-optimized-package-imports-in-next-js) and the built-in optimizations in Next.js. |
| 68 | + |
| 69 | +### Optimize package imports |
| 70 | + |
| 71 | +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`: |
| 72 | + |
| 73 | +```jsx |
| 74 | +module.exports = { |
| 75 | + experimental: { |
| 76 | + optimizePackageImports: ['package-name'], |
| 77 | + }, |
| 78 | +} |
| 79 | +``` |
| 80 | + |
| 81 | +### 4. Check your Tailwind CSS setup |
| 82 | + |
| 83 | +If you're using Tailwind CSS, make sure it's set up correctly. |
| 84 | + |
| 85 | +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. |
| 86 | + |
| 87 | +Tailwind CSS version 3.4.8 or newer will warn you about settings that might slow down your build. |
| 88 | + |
| 89 | +1. In your `tailwind.config.js`, be specific about which files to scan: |
| 90 | + |
| 91 | + ```jsx |
| 92 | + module.exports = { |
| 93 | + content: [ |
| 94 | + './src/**/*.{js,ts,jsx,tsx}', // Good |
| 95 | + // This might be too broad |
| 96 | + // It will match `packages/**/node_modules` too |
| 97 | + // '../../packages/**/*.{js,ts,jsx,tsx}', |
| 98 | + ], |
| 99 | + } |
| 100 | + ``` |
| 101 | + |
| 102 | +2. Avoid scanning unnecessary files: |
| 103 | + |
| 104 | + ```jsx |
| 105 | + module.exports = { |
| 106 | + content: [ |
| 107 | + // Better - only scans the 'src' folder |
| 108 | + '../../packages/ui/src/**/*.{js,ts,jsx,tsx}', |
| 109 | + ], |
| 110 | + } |
| 111 | + ``` |
| 112 | + |
| 113 | +### 5. Check custom webpack settings |
| 114 | + |
| 115 | +If you've added custom webpack settings, they might be slowing down compilation. |
| 116 | + |
| 117 | +Consider if you really need them for local development. You can optionally only include certain tools for production builds, or explore moving to Turbopack and using [loaders](/docs/app/api-reference/config/next-config-js/turbo#supported-loaders). |
| 118 | + |
| 119 | +### 6. Optimize memory usage |
| 120 | + |
| 121 | +If your app is very large, it might need more memory. |
| 122 | + |
| 123 | +[Learn more about optimizing memory usage](/docs/app/building-your-application/optimizing/memory-usage). |
| 124 | + |
| 125 | +### 7. Server Components and data fetching |
| 126 | + |
| 127 | +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. |
| 128 | + |
| 129 | +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. |
| 130 | + |
| 131 | +[Learn more about the experimental option](/docs/app/api-reference/config/next-config-js/serverComponentsHmrCache). |
| 132 | + |
| 133 | +## Tools for finding problems |
| 134 | + |
| 135 | +### Detailed fetch logging |
| 136 | + |
| 137 | +Use this command to see more detailed information about what's happening during development: |
| 138 | + |
| 139 | +```bash |
| 140 | +next dev --verbose |
| 141 | +``` |
| 142 | + |
| 143 | +## Still having problems? |
| 144 | + |
| 145 | +If you've tried everything and still have issues: |
| 146 | + |
| 147 | +1. Create a simple version of your app that shows the problem. |
| 148 | +2. Generate a special file that shows what's happening: |
| 149 | + |
| 150 | + ```bash |
| 151 | + NEXT_CPU_PROF=1 npm run dev |
| 152 | + ``` |
| 153 | + |
| 154 | +3. Share this file (found in your project's main folder) and the `.next/trace` file on GitHub as a new issue. |
0 commit comments