Why does the build process take so long? I have a i7 6xxx processor with a 1TB M.2 SSD and 16GB RAM. How can we increase the speed of the build process?
It's annoying to wait ~15sec for a build; even on 'npm run dev'.
DONE Compiled successfully in 13812ms
How "big" is your app?
I have the same problem. The build is slow even for for small app (just 3 pages).
It takes 14+ seconds on Xeon with 16 cores and 64GB of RAM.
nuxt:build Building... +0ms
nuxt:build App root: /opt/nodeapps/app-spa/app-client +0ms
nuxt:build Generating /opt/nodeapps/app-spa/app-client/.nuxt files... +0ms
nuxt:build Generating files... +13ms
nuxt:build Generating routes... +6ms
nuxt:build Building files... +38ms
Build completed in 12.468s
Hash: bc4b54c12b59362d9d01
Version: webpack 3.5.5
Time: 12473ms
Asset Size Chunks Chunk Names
pages/blog-page-keywords-name.0f861fa6e614f3e59b28.js 13.5 kB 0 [emitted] pages/blog-page-keywords-name
layouts/default.059bfad48863fcf28cc1.js 10.4 kB 1 [emitted] layouts/default
pages/blog-post-lessonId-page-keywords-topic.af0491d1caf4ddd0f4e1.js 10 kB 2 [emitted] pages/blog-post-lessonId-page-keywords-topic
pages/index.0693c1062109c71ed8e5.js 392 bytes 3 [emitted] pages/index
common.7b45f84d0622cc0ddcc8.js 253 kB 4 [emitted] common
app.04bea05d2f4513765eb1.js 31.2 kB 5 [emitted] app
manifest.bc4b54c12b59362d9d01.js 1.74 kB 6 [emitted] manifest
LICENSES 1.08 kB [emitted]
+ 10 hidden assets
Hash: ee8bb82c05d915ebbc3a
Version: webpack 3.5.5
Time: 1278ms
Asset Size Chunks Chunk Names
server-bundle.json 509 kB [emitted]
nuxt:build Building done +14s
about 19 pages.it takes 2min+
> nuxt build
nuxt:build Building... +0ms
nuxt:build App root: D:\hyku-projects\pages\src +0ms
nuxt:build Generating D:\hyku-projects\pages\.nuxt files... +2ms
nuxt:build Generating files... +6ms
nuxt:build Generating routes... +14ms
nuxt:build Building files... +48ms
Build completed in 60.593s
Hash: e2cce90c090f0974c474
Version: webpack 3.8.1
Time: 60591ms
=================================================================
modules
=================================================================
Hash: 5fa69f2abc67e8beab39
Version: webpack 3.8.1
Time: 42053ms
Asset Size Chunks Chunk Names
server-bundle.json 8.06 MB [emitted]
nuxt:build Building done +2m
my system info
Same issue here for a really small app with ~ 3 pages
same issue ,build so slow
same issue for me, build become really slow (between 10s to 40s)
6-7 really little plugins, 1 bigger : vuetify
Same issue, I have a serious lead, I have only one page (index.vue), the rendering takes 30s every time I change a single character. if I remove all the CSS classes, it takes only 4s. I think Nuxt can't handle too many attributes inside a HTML tag.
I've profiled this problem with 0x command.
These are processes that take a long time.
Also I confirmed that this PR improves webpack compilation time significantly.
https://github.com/webpack/webpack-sources/pull/23
The current build time for a fresh project (latest nuxt-edge
) is ~5-7 seconds
Should be fine as you "only" build when deploying (and you could prebuild the app and move it to the server then) and when developing, but then HMR is on.
This bug-report has been fixed by @manniL.
Build time looks good in latest
nuxt-edge
release
@manniL I also wonder if one could optimize this by not always have to run all build steps. It seems to me that some of the files are static, at least within a project and a nuxt version right? i.e. they do not change between rebuilds (like .nuxt/server.js
). If that is the case would it be possible to have a --template/--no-template
flag? Then one could split off the command into two steps and cache the templates that do not change and only rebuild them e.g. on a new nuxt version, or a nuxt config change and otherwise just build the webpack and dynamic part (like .nuxt/router.js
). Is that something that would be possible? We are looking at how we can reduce build times as much as possible, not just for better CI performance, but also we have started to get used to being able to occasionally do live development against a k8s cluster in the cloud in other parts of the stack and there being able to shave off any second counts.
CI should always do a clean full build in case there's a mistake in caching/optimization.
The build can be further optimized, but the main target is dev hot module reload time, not full builds.
I disagree with that statement, we are using bazel: https://bazel.build/ and one for the main functionality at its heart are to cache everything aggressively and have nearly the same iterative builds for production as for development. But it is also your project and if your main target is dev rebuilds and not production builds that is totally fair :)
Another possible option would be if one could use nuxt programatically in a more fine-grained way and getting access to the different build steps in the Builder and being able to customize fully what to run when and how. To be fair that is actually what I expected, but again also fair enough if that is not on your roadmap.
It's not my project, don't worry. I can see the advantages of such an approach, but it goes against the principle of build being a pure function from code to artifact. People don't trust their cache applications/implementations very much nowadays.
if one could use nuxt programatically in a more fine-grained way and getting access to the different build steps in the Builder
This would definitely slow down iteration on the project since this will become a public API, but I can see why that should be a goal in the long run. I do always suggest breaking the project up into smaller modules that isolate individual achievements of this project, wired up in userspace and a template using them to get one started, or a module that takes them as peer dependencies and allows ejecting when needed.
does this help in any way?
https://www.npmjs.com/package/only-if-changed-webpack-plugin
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
I have the same problem. The build is slow even for for small app (just 3 pages).
It takes 14+ seconds on Xeon with 16 cores and 64GB of RAM.