Nuxt.js: WARNING in ... size limit: The following ... exceed the recommended size limit

[sgmheyhey]

Version

v2.6.2

Reproduction link

https://github.com/nuxt/nuxt.js/issues/3879

Steps to reproduce

$ nuxt build --analyze

...

                  vendors.app.js   1.11 MiB      10  [emitted]  [big]  vendors.app
 + 2 hidden assets
Entrypoint app [big] = runtime.js commons.app.js vendors.app.js app.js

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
This can impact web performance.
Assets: 
  vendors.app.js (1.11 MiB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (1000 KiB). This can impact web performance.
Entrypoints:
  app (1.33 MiB)
      runtime.js
      commons.app.js
      vendors.app.js
      app.js

https://github.com/nuxt/nuxt.js/issues/3879
https://github.com/nuxt/nuxt.js/issues/2201#issuecomment-417215167

What is expected ?

Not to see 'WARNING'

What is actually happening?

WARNING in ... size limit: The following ...

_{This bug report is available on Nuxt community (#c9059)}

[manniL]

This is not a bug at all, but a warning regarding your application size limited. You can apply code splitting and dynamic imports.

However, not a bug in Nuxt.

[sgmheyhey]

webpack is doing splitChunk automatically, but not in nuxt? then isn't it a bug, duh, or not working in webpack?

[manniL]

@sgmheyhey No, it does code splitting by route. If you include libraries globally, don't lazy load external libs or components, use a customn router.js or use an older Nuxt version, it can affect your page perf.

[clarkdo]

@sgmheyhey Nuxt is using exactly wepack splitChunk and also the default configuration if you don't specify anything in nuxt.config: build.optimization.splitChunks.

From your webpack state report, I think your concern is size of vendors.app.js.

For webpack splitChunk policy, the default cache group vendors will be splitted if it's bigger than 30KB, but this is not absolute, there're still other factors like maxAsyncRequests, maxInitialRequests will prevent the splitting.

webpack has an option maxSize(not enabled by default) which makes webpack try to split chunks bigger than maxSize into smaller parts.

In your case, you can set maxSize to the maximum vendor chunk size of your expectation.

[P4sca1]

Would it be more performant to split the vendors? Because every page needs it anyways. Is it faster to load multiple chunks of vendors than loading it all at once?

[clarkdo]

@P4sca1
It has both pros and cons.

Multiple chunks will increase requests amount and extra overheads, but if can also enhance the performance if your project has good cache solution like leveraging CDN, using preload properly and using HTTP2

As webpack doc mentioned, is intended to be used with HTTP/2 and long term caching. It increase the request count for better caching. It could also be used to decrease the file size for faster rebuilding.

I suggest that before considering splitting chunks, it would be better to think about the reason why vendors includes many big libs, maybe importing 3rd party component on-demand(like vuetify A La Carte, import specific function instead whole lodash), exclude unnecessary resources( like locales in moment.js) can help a lot.

[tangyingcai]

https://webpack.js.org/plugins/split-chunks-plugin/
module.exports = {
//...
optimization: {
splitChunks: {
cacheGroups: {
commons: {
test: /[\/]node_modules[\/]/,
// cacheGroupKey here is commons as the key of the cacheGroup
name(module, chunks, cacheGroupKey) {
const moduleFileName = module.identifier().split('/').reduceRight(item => item);
const allChunksNames = chunks.map((item) => item.name).join('~');
return ${cacheGroupKey}-${allChunksNames}-${moduleFileName};
},
chunks: 'all'
}
}
}
}
};
the optimal configuration scheme has been given~