Nuxt.js: Why does the build process take 15sec+?

Created on 21 Dec 2017  路  16Comments  路  Source: nuxt/nuxt.js

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

This question is available on Nuxt.js community (#c2109)

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.

  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

All 16 comments

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

image

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.

  • css processing (10%)
  • webpack compilation (20%)
  • webpack build (20%)
  • babel transpile (20%)

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.

image

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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

uptownhr picture uptownhr  路  3Comments

bimohxh picture bimohxh  路  3Comments

vadimsg picture vadimsg  路  3Comments

vadimsg picture vadimsg  路  3Comments

danieloprado picture danieloprado  路  3Comments