Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NextJs compiling extremely slow #29559

Closed
stevensturkop opened this issue Oct 2, 2021 · 65 comments
Closed

NextJs compiling extremely slow #29559

stevensturkop opened this issue Oct 2, 2021 · 65 comments
Labels
Performance Anything with regards to Next.js performance. Webpack Related to Webpack with Next.js.

Comments

@stevensturkop
Copy link

stevensturkop commented Oct 2, 2021

What version of Next.js are you using?

11.1.2

What version of Node.js are you using?

14.18.0

What browser are you using?

Chrome

What operating system are you using?

Windows 10

How are you deploying your application?

AWS ECS

Describe the Bug

I've been using NextJs for years and recently it has been very hard to work with because very slow in development.
After npm run dev, I go to localhost:3000. From there the page can take up to 60 seconds to display. Then when the first page finally displays, each code change fast refresh or page transition SSR (compilation) takes between 15-20 seconds, sometimes more than 30 seconds, and sometimes it even doesn't work so I have to refresh the page.

Expected Behavior

Page load + compilation should be faster.

To Reproduce

Unfortunately, I cannot send a reproducible UI because the project I work on is pretty big and the UI is under NDA.

Maybe without a reproducible UI, you guys have thoughts about how to improve/fix the compilation time on windows. Maybe some of you have faced the same problem and fixed it somehow. I'm all ears.

My package.json

{
"name": "myname",
"version": "0.1.0",
"private": true,
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start -p 3002"
},
"dependencies": {
"@react-google-maps/api": "^2.0.2",
"@sentry/browser": "^6.7.2",
"@sentry/react": "^6.7.2",
"@sentry/tracing": "^6.7.2",
"@sentry/webpack-plugin": "^1.15.1",
"@stripe/react-stripe-js": "^1.4.0",
"@stripe/stripe-js": "^1.13.1",
"accept-language-parser": "^1.5.0",
"aws-sdk": "^2.802.0",
"base-64": "^1.0.0",
"cors": "^2.8.5",
"dotenv": "^8.2.0",
"hls.js": "^0.14.16",
"iban": "0.0.14",
"js-sha256": "^0.9.0",
"libphonenumber-js": "^1.9.11",
"localized-countries": "^2.0.0",
"lodash": "^4.17.21",
"moment": "^2.29.1",
"next": "^11.1.2",
"next-compose-plugins": "^2.2.1",
"next-fonts": "^1.5.1",
"next-images": "^1.8.1",
"next-seo": "^4.17.0",
"nookies": "^2.5.0",
"platform": "^1.3.6",
"qrcode": "^1.4.4",
"randomstring": "^1.1.5",
"react": "^17.0.2",
"react-cropper": "^2.1.4",
"react-datepicker": "^3.3.0",
"react-device-detect": "^1.15.0",
"react-dom": "^17.0.2",
"react-dotdotdot": "^1.3.1",
"react-ga": "^3.3.0",
"react-geocode": "^0.2.2",
"react-google-maps": "^9.4.5",
"react-lines-ellipsis": "^0.14.1",
"react-loading-skeleton": "^2.2.0",
"react-query": "^3.13.2",
"react-textarea-autosize": "^8.3.2",
"sass": "^1.29.0",
"stripe": "^8.137.0",
"uuid": "^8.3.1",
"video.js": "^7.11.0",
"videojs-contrib-dash": "^4.0.0"
},
"devDependencies": {
"@svgr/webpack": "^5.5.0"
}
}

@stevensturkop stevensturkop added the bug Issue was opened via the bug report template. label Oct 2, 2021
@Philreact
Copy link

Philreact commented Oct 2, 2021

I've had the same problem for the last 8 months. It seems many people are having the same problem. In my opinion this should be a priority to get fixed. I have tried almost everything: deactivating windows defender, using yarn instead of npm, but nothing has worked.

sometimes it takes 1 min to change pages in development. In production it's super fast.

I can't publish my code as well since it's copyrighted.

here are my dependencies
{
  "name": "",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "next": "next",
    "dev": "nodemon server/index.js",
    "build": "next build",
    "start": "node server/index.js",
    "analyze": "cross-env ANALYZE=true next build",
    "analyze:server": "cross-env BUNDLE_ANALYZE=server next build",
    "analyze:browser": "cross-env BUNDLE_ANALYZE=browser next build"
  },
  "dependencies": {
    "@date-io/date-fns": "^1.3.13",
    "@dnd-kit/core": "^3.1.1",
    "@dnd-kit/sortable": "^4.0.0",
    "@material-ui/core": "^4.12.3",
    "@material-ui/icons": "^4.9.1",
    "@material-ui/lab": "^4.0.0-alpha.60",
    "@material-ui/pickers": "^3.3.10",
    "@next/bundle-analyzer": "^11.0.1",
    "@sendgrid/mail": "^7.4.0",
    "@stripe/stripe-js": "^1.12.1",
    "@tippyjs/react": "^4.2.5",
    "aws-sdk": "^2.809.0",
    "axios": "^0.21.0",
    "bcryptjs": "^2.4.3",
    "bootstrap": "^4.4.1",
    "chroma-js": "^2.1.1",
    "config": "^3.3.2",
    "cookie": "^0.4.1",
    "cookie-parser": "^1.4.5",
    "cookie-session": "^1.4.0",
    "cors": "^2.8.5",
    "cross-env": "^7.0.3",
    "d3-ease": "^2.0.0",
    "date-fns": "^2.21.1",
    "express": "^4.17.1",
    "express-session": "^1.17.1",
    "express-validator": "^6.6.1",
    "geoip-lite": "^1.4.2",
    "intersection-observer": "^0.12.0",
    "js-cookie": "^2.2.1",
    "jsonwebtoken": "^8.5.1",
    "moment": "^2.29.1",
    "mongoose": "^5.10.11",
    "next": "10.2.3",
    "next-absolute-url": "^1.2.2",
    "node-fetch": "^2.6.1",
    "nprogress": "^0.2.0",
    "passport": "^0.4.1",
    "passport-google-oauth20": "^2.0.0",
    "password-validator": "^5.1.1",
    "pdfjs-dist": "^2.7.570",
    "prismjs": "^1.23.0",
    "quill": "^1.3.7",
    "randomcolor": "^0.6.2",
    "react": "16.14.0",
    "react-beautiful-dnd": "^11.0.5",
    "react-bootstrap": "^1.4.0",
    "react-contenteditable": "^3.3.5",
    "react-dom": "16.14.0",
    "react-dropzone": "^11.2.3",
    "react-quill": "^1.3.5",
    "react-select": "^3.1.1",
    "react-spring": "^8.0.27",
    "react-toastify": "^6.1.0",
    "react-zoom-pan-pinch": "^1.6.1",
    "request-ip": "^2.1.3",
    "roughjs": "^4.3.1",
    "sass": "^1.27.0",
    "socket.io": "^3.1.2",
    "socket.io-client": "^3.1.2",
    "string-strip-html": "^4.3.5",
    "stripe": "^8.137.0",
    "validator": "^13.5.2",
    "web-push": "^3.4.4"
  },
  "devDependencies": {
    "eslint": "^7.16.0",
    "eslint-plugin-react": "^7.21.5"
  }
}

@balazsorban44

This comment has been minimized.

@Philreact

This comment has been minimized.

@balazsorban44

This comment has been minimized.

@stevensturkop

This comment has been minimized.

@stevensturkop

This comment has been minimized.

@timneutkens

This comment has been minimized.

@timneutkens

This comment has been minimized.

@kartikrao
Copy link

kartikrao commented Oct 6, 2021

Our app www.drive.com.au is the largest automotive site in Australia.

Creating a production build with next build takes > 20 minutes on a machine with 6 cores and 32 GB of RAM. Our builds have slowed significantly since updating to Next 11.x

@timneutkens - Happy to provide access to config and code, if its of wider benefit to the community, we are also happy to pitch in if helpful.

Issue template

What version of Next.js are you using?

11.1.2

What version of Node.js are you using?

14.18.0

What browser are you using?

Chrome

What operating system are you using?

Mac OS 11.6 (Big Sur)

How are you deploying your application?

AWS ECS

Describe the Bug

We use getServerSideProps for > 90% of pages.

We've tried:

  • Enabling and disabling build caching (.next folder)
  • Changing NodeJS version (14.16)
  • Upgrading/Downgrading dependencies - babel, postcss, tailwind etc.

@timneutkens

This comment has been minimized.

@kartikrao

This comment has been minimized.

@timneutkens

This comment has been minimized.

@billymcintosh
Copy link

I admire you helping one to one, but shouldn't the potential solutions be posted here to help everyone that has this issue?

@f16z
Copy link

f16z commented Oct 7, 2021

so much pain in development.. still hunting for solutions

@timneutkens
Copy link
Member

timneutkens commented Oct 8, 2021

Experiencing this issue?

To provide a trace which only includes metadata of the application:

  • npm install next@canary (or yarn add next@canary)
  • Run development like normal and reproduce the issue you're experiencing
  • Stop Next.js (generally ctrl + c)
  • Send the file .next/trace file here or send it to https://twitter.com/timneutkens if you don't want to share it publicly. You can use https://gist.github.com to create a private url for the file.
    - If you have a custom .babelrc please provide it
    - If you have a custom next.config.js please provide it
    - if you are using TailwindCSS please provide tailwind.config.js

⚠️ The metadata in .next/trace includes full file paths to all JS/CSS. It does not include the file contents.
⚠️ The main thing we need to help investigate your application is .next/trace, package.json and such are not helpful in investigating the issue.

Reply to earlier messages

but shouldn't the potential solutions be posted here to help everyone that has this issue?

So far all I've done is help investigate the slowdowns for the people that reached out. There's no specific solution as it highly depends on the app and I'm going to share the findings. . I've been working on a way that we can investigate these slowdowns without needing the application code itself but it requires a bunch of steps that up till a few days ago were quite involved.

Here's a list of what I've found so far:

  • @stevensturkop hasn't provided a trace yet
  • @PhillipLangMartinez
    • Fast Refresh is behaving as expected, no particular slowdown, will benefit from the work we're doing for SWC and webpack optimizations though
    • The main problem they're experiencing is about on-demand-entries. Next.js compiles the JS/CSS/etc for pages on-demand when you request them, so if you request http://localhost:3000/about Next.js will at that point start compiling the JS/CSS for pages/about.js, this is intentional to ensure that you can have thousands of pages in a Next.js app and it would not slow down your app, otherwise you'd pay this compilation penalty at bootup
      • This will also benefit from the work we're doing integrating SWC with full backwards compat. I've had Phillip try the new flag and it's resulted in at least 50% faster initial compilation and ~60% faster compiling of pages. Note that this highly depends on if you have a lot of node_modules or a lot of application code, the application code will be compiled faster but node_modules are not passed through babel currently so they are not affected by the work we're doing to add SWC at this point in time.
    • In order to investigate this one further I'm adding timings for filesystem reads to find if that's what is causing issues with a large amount of JS as they have a bunch of large node_modules like react-bootstrap included
  • @kartikrao
    • 90% of the time spent compiling is related to TailwindCSS, it's slowing down each CSS file by spending about 2 minutes and 30 seconds, it seems that the application is not using TailwindCSS JIT, so I'd recommend enabling that for all users that are using TailwindCSS: https://tailwindcss.com/docs/just-in-time-mode
  • @f16z
    • Machine fs.readFile seems to be slow, it takes over 100ms per file, we expanded the tracing to include timing for individual files
    • Initial compile + compiling pages/index.js reads and compiles about 6867 files. What I've found is that 5557 of those are coming from @material-ui/icons/esm, assuming that the app is not using 5.5K icons I'd recommend changing how they are imported so that not all files have to be compiled. Based on debugging this trace we're adding a separate chart that will allow us to visualize the dependency graph based on a trace file
  • @billymcintosh can you provide a trace based on the above instructions

@f16z
Copy link

f16z commented Oct 8, 2021

I have issues installing next@canary until I ran npm config set legacy-peer-deps true

@AdamDiament
Copy link

AdamDiament commented Oct 14, 2021

@timneutkens Thanks for looking into this. I am about to send you my files privately on twitter. I love working with next but this is a major pain point, so I really appreciate that you are prioritising it. During the time the project was on I first navigated between a few different pages. Each page load took between 5 and 15 seconds by my estimates, which is my major issue day to day. I then did a fast refresh. This was nice and quick, better than usual. To get things ready for submitting this test I upgraded to webpack 5 from 4, which might explain the improvement. Thanks again!

... I am having trouble sending you the files on twitter as they are an unsupported file type, including zip. Is there another way I can share the trace with you as I don't want to post my config files here.

@timneutkens
Copy link
Member

@AdamDiament I've replied to your message on twitter and also updated the instructions here. https://gist.github.com is how you can share individual files 👍

@ValentinH
Copy link
Contributor

I had a similar issue and it was also due to @material-ui/icons and loading all of them. If you import them directly from your application code, the tree-shaking works properly. However, in our case, we were importing them from an internal package installed in the node_modules of our application which resulted in all icons being imported (only in the server bundle).

We solved it by following this documentation and adding a babel plugin to automatically rename our named imports to default imports when building and publishing our internal package.

@AdamDiament
Copy link

@AdamDiament I've replied to your message on twitter and also updated the instructions here. https://gist.github.com is how you can share individual files 👍

Thanks Tim sent you a gist on twitter

@balazsorban44
Copy link
Member

@stevensturkop checking in, what's the status here? Were you able to reach out to Tim? Is this issue resolved?

@timneutkens timneutkens added area: Application Code Webpack Related to Webpack with Next.js. Performance Anything with regards to Next.js performance. and removed bug Issue was opened via the bug report template. labels Dec 13, 2021
@lveillard
Copy link

In case it helps somebody, in our case the line causing the extremely slow compilation was this one:

//tailwind.config.js
/** @type {import('tailwindcss').Config} */
module.exports = {
  // eslint-disable-next-line global-require, import/no-extraneous-dependencies
  presets: [require('tailwind-preset')],
  content: [
    './src/app/**/*.{js,ts,jsx,tsx}',
    './src/pages/**/*.{js,ts,jsx,tsx}',
    './src/components/**/*.{js,ts,jsx,tsx}',
    './src/layout/**/*.{js,ts,jsx,tsx}',
    '../../packages/ui/**/*.{js,ts,jsx,tsx}', // THIS ONE!
  ],
};

In our case we are using turborepo and when adding the package/ui the compilation time goes from 2-5 seconds to >500 seconds

@agyarmati
Copy link

For reference, in our case the slow dev experience was caused by the app getting compiled twice, which is a known issue in 12.2.5: #39901
Updating to 12.3.1 fixed the issue completely.

@anthonyalayo
Copy link

To add to what @ValentinH said and @Carduelis said, the issue is not with Next.js, it is with @mui and webpack. I ended up filing an RFC on @mui here which covers a lot of the details.

While the link above has details explaining the issue, I can reiterate here. Webpack must traverse all imports when running in either dev or prod, as it does not know how to / can't optimize at the code level. It is only when terser (a webpack default plugin) minifies bundles that you end up with the "tree shaken" version.

With any barrel file, your development server will have all modules (and their imports... and their imports...) loaded into memory while it's running. This also happens when building, but it is more hidden since you aren't running an HMR server at the same time.

The best solution, which I also recommended @mui to do internally, is to configure either a babel or swc plugin to transform your imports. @mui ironically has docs on that here. This will allow you to keep the DX you want while significantly speeding up your webpack builds.

I think we should consider this issue closed.

@Vallo
Copy link

Vallo commented Jan 18, 2023

Is there a way to modularizeImports or somehow optimise the bundling when an external package is importing @mui/icons-material incorrectly?

Currently I am using @solana/wallet-adapter-material-ui
which uses @mui/icons-material like this:

import { FileCopy as CopyIcon, LinkOff as DisconnectIcon, SwapHoriz as SwitchIcon } from '@mui/icons-material';

When compiling with this library, it results in 14162 modules. If I remove it, I get just 3332 modules.

Is there a way to optimise it? Thanks

@anthonyalayo
Copy link

@Vallo not without changing it, I also had to do the same for a library I was using.

@rtroncoso
Copy link

In case it helps somebody, in our case the line causing the extremely slow compilation was this one:

//tailwind.config.js
/** @type {import('tailwindcss').Config} */
module.exports = {
  // eslint-disable-next-line global-require, import/no-extraneous-dependencies
  presets: [require('tailwind-preset')],
  content: [
    './src/app/**/*.{js,ts,jsx,tsx}',
    './src/pages/**/*.{js,ts,jsx,tsx}',
    './src/components/**/*.{js,ts,jsx,tsx}',
    './src/layout/**/*.{js,ts,jsx,tsx}',
    '../../packages/ui/**/*.{js,ts,jsx,tsx}', // THIS ONE!
  ],
};

In our case we are using turborepo and when adding the package/ui the compilation time goes from 2-5 seconds to >500 seconds

fixed it for me, thanks!

@sneko
Copy link

sneko commented Feb 7, 2023

@anthonyalayo to be honest I tried what you pointed https://mui.com/material-ui/guides/minimizing-bundle-size/#option-two-use-a-babel-plugin and it did not do much about speed :(

It's a total disaster ^^... 30 seconds to launch my next dev, and for each page is about 10s, welcome to 2023 :D

If you have other tips I take 👍

@pimmee
Copy link

pimmee commented Feb 15, 2023

I think we should consider this issue closed.
@anthonyalayo

I've added the modularizeImports MUI transforms and tried 10 other things mentioned in other places, but still the DX with NextJS is very bad for many people due to extremely slow page loads. The DX in other tools in the ecosystem (e.g. vite, even create-react-app) don't suffer from this, so I don't think this issue should be closed.

The development experience with NextJS is advertised greatly by Vercel, so it is frustrating when it does not live up to its promises.

This is how the compiling look like during a page navigation in my fairly large project:
image

Here's some screenshots when I tried adding dependencies one by one in a new project with next 13.1.6:
image

After adding date-fns:
image

After adding modularizeImport on date-fns:
image

So the modularizeImports definitely works, but only a small number of libraries organizes their imports in a way that is compatible.

After adding @mui/x-data-grid (@mui/material, @mui/icons-material, date-fns, @mui/x-data-grid in total)
image

With ~1400 modules compiled and taking 1.7 seconds for page load in an empty project just by adding a few dependencies, it's easy to see how it gets out of hand in a large project.

I wonder if a lot of the slow page loading is due to prefetching of pages? In the following screenshot I hovered my mouse over a few links in my sidebar before navigating which seems to create a waterfall effect and cause delay.

image

If NextJS cannot improve the page load performance due to Webpack, I still think it can help with tooling to improve the DX. For example:

Happy to share private repo with NextJS developers if it helps solving this issue.

@timneutkens
Copy link
Member

You can visualize the trace yourself using canary/scripts/trace-to-tree.mjs if you're curious.

node scripts/trace-to-tree.mjs /path/to/trace

Option to disable prefetching globally in development

Prefetching is disabled in development for pages. For app it's enabled but only on hover. If you want to completely disable prefetching you can pass prefetch={false}.

Debug option to log which modules was compiled

See above.

Automatically detect libraries compatible with modularizeImport and do it automatically

This is potentially breaking which is why we don't have a default config.


Overall the issues with large amounts of modules was one the reasons we started building Turbopack: https://turbo.build/pack. Which is currently in alpha. It's a completely new architecture to allow processing many more modules quickly, including for next build.

@pimmee
Copy link

pimmee commented Feb 16, 2023

@timneutkens Appreciate the response.

You're right, NextJS has tooling to debug compiled modules with trace-to-tree.mjs. I've used it before but still struggling to find obvious root causes of slow compile times. It seems to me that it's the accumulation of dependencies (e.g. axios 2.2s, @casl/ability 2.1s, etc.) that's causing most of it. Perhaps I'm missing something obvious that would make a big difference?

https://gist.github.com/pimmee/9b448450782a63e93a131a9f8c54afb7

Really looking forward to turbo pack adding support for app dir and more 🚀

@sneko
Copy link

sneko commented Feb 16, 2023

@timneutkens if you have in mind a Next.js project working smoothly with MUI in development I'm curious to see it!

In addition to what I mentionned (long duration just to launch next dev or browse a new page), when reloading a page in my browser without changing any code it seems to recompile thousands of modules... taking like 10 seconds to do so.

If I have to choose between MUI or Next.js... hard to choose once a project is launched :D ...

About Turbopack I'm not sure it's a solution before years... for little projects it may be fine but since there will be no compatibility with current webpack plugins... the migration will be hard for quite some time before the community catch up on plugins.

@sneko
Copy link

sneko commented Feb 19, 2023

Good news! I approximately reduced my next dev from 6500 to 2500 modules for the first page I load!

TLDR: explode your imports!

For the long story:

I tried at first babel-plugin-import (inclusion-numerique/mediature@a5dc625) to allow using merged imports for MUI... but it didn't reduce the modules built.

Then I tried the way of Next.js with:

    modularizeImports: {
      '@mui/material': {
        transform: '@mui/material/{{member}}',
      },
      '@mui/icons-material/?(((\\w*)?/?)*)': {
        transform: '@mui/icons-material/{{ matches.[1] }}/{{member}}',
      },
    },

But nothing changed too.

Weeks after I was just upset by this painful slow compilation of module just to load basic pages (sometimes 40 seconds).


I decided to go the hard way, I replaced for example all my:

import { Grid, Typography } from '@mui/material';

by:

import Grid from '@mui/material/Grid';
import Typography from '@mui/material/Typography';

I also replaced for example:

import { LocalizationProvider } from '@mui/x-date-pickers';
import { frFR as coreFrFR } from '@mui/material/locale';
// import { DataGrid, frFR as dataGridFrFR } from '@mui/x-data-grid';
import { frFR as datePickerFrFR } from '@mui/x-date-pickers';

by:

import { LocalizationProvider } from '@mui/x-date-pickers/LocalizationProvider';
import { frFR as coreFrFR } from '@mui/material/locale';
// import { frFR as dataGridFrFR } from '@mui/x-data-grid/locales/frFR';
import { frFR as datePickerFrFR } from '@mui/x-date-pickers/locales/frFR';

import { fr as frDateLocale } from 'date-fns/locale';
import { format as formatDate, formatDistance, formatRelative, isDate } from 'date-fns';

by:

import frDateLocale from 'date-fns/locale/fr';
import formatDate from 'date-fns/format';
import formatDistance from 'date-fns/formatDistance';
import formatRelative from 'date-fns/formatRelative';
import isDate from 'date-fns/isDate';

(for my examples it was spread across files but I tried to give you an overview of the steps (inclusion-numerique/mediature@f1c4850), just think about big librairies and try to see if there is way to do the "tree-shaking" manually).

Note that I don't get why using Babel or Next.js optimization didn't help on MUI. From what I read Webpack tree-shaking is only enabled when NODE_ENV=production, is it the reason? For me tree-shaking is also important in development to not bring everything to the table of compilation.

If Babel/Next.js optimizations worked for you even with next dev, I'm fine to admit I did something wrong, but no clue what it is. Is it possible it's due to pnpm? (just asking, I saw a lot of weird issues with it due to symlinks)

Speaking of pnpm, I also find a way to save some modules compilation (due to duplication of packages). I use a monorepo and some of my packages are using MUI. Since they were not align on some rules of pnpm a dependency with the exact same version in 2 packages would not be merged into one (it's deduplicated). It's more specific to pnpm so if you want this, I tried to explain a bit how to debug/fix this: pnpm/pnpm#6055 (reply in thread)

Now my first load of a page is 2500 modules in about 12 seconds, which is way better even if still not perfect.

Hope this helps!

@yanetou

This comment was marked as off-topic.

@macutko
Copy link

macutko commented Apr 3, 2023

#29559 (comment)

THIS!!! Thank you sir, this solved a huge headache for me. I copied my settings from some example config provided by turbo I believe and this was a nightmare.

@7iomka
Copy link
Contributor

7iomka commented Apr 16, 2023

In case it helps somebody, in our case the line causing the extremely slow compilation was this one:

//tailwind.config.js
/** @type {import('tailwindcss').Config} */
module.exports = {
  // eslint-disable-next-line global-require, import/no-extraneous-dependencies
  presets: [require('tailwind-preset')],
  content: [
    './src/app/**/*.{js,ts,jsx,tsx}',
    './src/pages/**/*.{js,ts,jsx,tsx}',
    './src/components/**/*.{js,ts,jsx,tsx}',
    './src/layout/**/*.{js,ts,jsx,tsx}',
    '../../packages/ui/**/*.{js,ts,jsx,tsx}', // THIS ONE!
  ],
};

In our case we are using turborepo and when adding the package/ui the compilation time goes from 2-5 seconds to >500 seconds

fixed it for me, thanks!

Hi. but, how you found workaround to not include paths from one of packages if you really need this?

@DylanP97
Copy link

DylanP97 commented Apr 28, 2023

Hello,

For me after making a next analyze
It was the use of "react-icons", "date-fns" and "world-countries" that were calling taking ridiculously too much kilobytes

also dynamic and splited import help to enhance the speed

but run a next analyze you will see what's taking a lot of space

@turkialanizi78
Copy link

for me i get more speed after i unselect the Format On Save

@billymcintosh
Copy link

billymcintosh commented May 26, 2023 via email

@lveillard
Copy link

In case it helps somebody, in our case the line causing the extremely slow compilation was this one:

//tailwind.config.js
/** @type {import('tailwindcss').Config} */
module.exports = {
  // eslint-disable-next-line global-require, import/no-extraneous-dependencies
  presets: [require('tailwind-preset')],
  content: [
    './src/app/**/*.{js,ts,jsx,tsx}',
    './src/pages/**/*.{js,ts,jsx,tsx}',
    './src/components/**/*.{js,ts,jsx,tsx}',
    './src/layout/**/*.{js,ts,jsx,tsx}',
    '../../packages/ui/**/*.{js,ts,jsx,tsx}', // THIS ONE!
  ],
};

In our case we are using turborepo and when adding the package/ui the compilation time goes from 2-5 seconds to >500 seconds

fixed it for me, thanks!

Hi. but, how you found workaround to not include paths from one of packages if you really need this?

So in our case we were forced to split tailwind instead of having it in a single branch of the monorepo

@sannajammeh
Copy link
Contributor

In case it helps somebody, in our case the line causing the extremely slow compilation was this one:

//tailwind.config.js
/** @type {import('tailwindcss').Config} */
module.exports = {
  // eslint-disable-next-line global-require, import/no-extraneous-dependencies
  presets: [require('tailwind-preset')],
  content: [
    './src/app/**/*.{js,ts,jsx,tsx}',
    './src/pages/**/*.{js,ts,jsx,tsx}',
    './src/components/**/*.{js,ts,jsx,tsx}',
    './src/layout/**/*.{js,ts,jsx,tsx}',
    '../../packages/ui/**/*.{js,ts,jsx,tsx}', // THIS ONE!
  ],
};

In our case we are using turborepo and when adding the package/ui the compilation time goes from 2-5 seconds to >500 seconds

Just going to mention that ui most likely had a node_modules in it. I switched from /ui/**/*.tsx to /ui/src/**/*.tsx and it become quite a bit faster.

@kcritesh
Copy link

kcritesh commented Jun 6, 2023

"dev": "next dev --turbo",
using turbopack worked for me
https://nextjs.org/docs/architecture/turbopack

@Vallo
Copy link

Vallo commented Jun 6, 2023

@kcritesh turbopack is in beta, not production ready, and produces a lot of errors in some projects.

@timneutkens
Copy link
Member

I'm going to consolidate all of these issues into one issue given that they're all roughly the same.

Closing in favor of #48748. Please see this comment: #48748 (comment)

@vercel vercel locked and limited conversation to collaborators Jun 6, 2023
@timneutkens
Copy link
Member

In case you're using a monorepo with Tailwind CSS, have a look at this: https://twitter.com/timneutkens/status/1783851267237781574

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Performance Anything with regards to Next.js performance. Webpack Related to Webpack with Next.js.
Projects
None yet
Development

No branches or pull requests