NextJs compiling extremely slow #29559
Comments
|
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"
}
} |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Our app www.drive.com.au is the largest automotive site in Australia. Creating a production build with @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 templateWhat 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 BugWe use We've tried:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
I admire you helping one to one, but shouldn't the potential solutions be posted here to help everyone that has this issue? |
|
so much pain in development.. still hunting for solutions |
Experiencing this issue?To provide a trace which only includes metadata of the application:
Reply to earlier messages
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:
|
|
I have issues installing next@canary until I ran |
@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. |
|
@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 👍 |
|
I had a similar issue and it was also due to 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. |
Thanks Tim sent you a gist on twitter |
|
@stevensturkop checking in, what's the status here? Were you able to reach out to Tim? Is this issue resolved? |
timneutkens
added
area: Application Code
Webpack
|
In case it helps somebody, in our case the line causing the extremely slow compilation was 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 |
|
For reference, in our case the slow dev experience was caused by the app getting compiled twice, which is a known issue in |
|
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. |
|
Is there a way to Currently I am using
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 |
|
@Vallo not without changing it, I also had to do the same for a library I was using. |
fixed it for me, thanks! |
|
@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 If you have other tips I take 👍 |
I've added the 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: Here's some screenshots when I tried adding dependencies one by one in a new project with next After adding After adding So the After adding 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.
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. |
|
You can visualize the trace yourself using canary/scripts/trace-to-tree.mjs if you're curious.
Prefetching is disabled in development for
See above.
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 |
|
@timneutkens Appreciate the response. You're right, NextJS has tooling to debug compiled modules with https://gist.github.com/pimmee/9b448450782a63e93a131a9f8c54afb7 Really looking forward to turbo pack adding support for app dir and more 🚀 |
|
@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 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. |
|
Good news! I approximately reduced my TLDR: explode your imports! For the long story: I tried at first 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 If Babel/Next.js optimizations worked for you even with Speaking of 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! |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
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. |
Hi. but, how you found workaround to not include paths from one of packages if you really need this? |
|
Hello, For me after making a next analyze 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 |
|
for me i get more speed after i unselect the Format On Save |
|
Thats is nothing to do with nextjs mate.
Change your IDE and test.
…On Fri, 26 May 2023 at 23:16, bofaissal alanizi ***@***.***> wrote:
for me i get more speed after i unselect the Format On Save
—
Reply to this email directly, view it on GitHub
<#29559 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABVFM6N2QDF6JHDCOXGCNDXIDJOHANCNFSM5FGHOMJA>
.
You are receiving this because you were mentioned.Message ID: <vercel/next
.***@***.***>
|
So in our case we were forced to split tailwind instead of having it in a single branch of the monorepo |
Just going to mention that |
|
"dev": "next dev --turbo", |
|
@kcritesh turbopack is in beta, not production ready, and produces a lot of errors in some projects. |
|
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) |
|
In case you're using a monorepo with Tailwind CSS, have a look at this: https://twitter.com/timneutkens/status/1783851267237781574 |
and others
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 tolocalhost: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.Compiling too slow on next 9.4 #12797 (comment)
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"
}
}
The text was updated successfully, but these errors were encountered: