granular chunking for webpack

[simllll]

What problem does this feature solve?

next.js was playing around with it and saw some great improvements
https://github.com/zeit/next.js/blob/3aa6edb6180d4dab331b01ee4a56c01c5d43032b/packages/next/build/webpack-config.ts
row 307.

It reduces package sizes and especially the amount of transferred data after page navigation. This feature could be easily adopted to nuxt and would reduces automatically the transmitted bytes needed for a nuxt app ;).

What does the proposed changes look like?

See also: https://www.youtube.com/watch?v=QDljY2I1Pfw&feature=youtu.be&t=833

[danielroe]

This write-up is interesting.

https://web.dev/granular-chunking-nextjs/

[pi0]

Thanks for links @simllll @danielroe.

Actually we also did bunch of benchmarks during webpack 4 migration to find out the best chunking strategy. Nuxt.js has a commons cache group, similar to Next.js react/frameworks group. We also tried splitting by page usage inspired by Next.js which reverted back by d32419e because of negative performance impacts. Rest is by SplitChunksPlugin defaults which also ensures maximum parallel requests will not reach (if reaches, we end-up with waterfall request groups)

While investigating for generic enough performance improvements should be an umbrella activity, should consider Nuxt/Next (and generally Vue/React) framework design and project setup has major differences. For Nuxt, usually many vendors are added by global plugins so page count is not a good measurement.

To move it forward, I would suggest start by creating a Nuxt module to apply granular chunking (cacheGroup) strategy and provide as an option to users.

[danielroe]

@pi0 Do you have any recommended performance tests or target metrics for Nuxt bundles?

(I'm also following the progress of this core-js strategy with interest, and have wondered a similar approach might be relevant for Nuxt.)

[pi0]

Do you have any recommended performance tests or target metrics for Nuxt bundles?

We can try on some public demos like this and fixtures that heavily use plugins or big libraries like bootstrap CSS

I'm also following the progress of this core-js strategy with interest, and have wondered a similar approach might be relevant for Nuxt

Indeed but already have modern mode to target modern browsers with fewer polyfills. Also, Nuxt Modules possibility to experiment with this improvement without being bound to core release lifecycle ;)

Currently, for the first-page load we request:

• app.js
• commons.app.js (core-js polyfills are here)
• runtime.js (small but frequently changes)
• pages/[current].js
• [any other async chunk used by page or plugins]

[danielroe]

This can be implemented without needing a change in Nuxt core, so for now I'm closing this issue.