Output which JS chunks are loaded on which pages

[nicholaschiang]

Feature request

Is your feature request related to a problem? Please describe.

A clear and concise description of what you want and what your use case is.

I'm trying to increase the speed of my website by decreasing the initial load JS size.

So, I'm using the @next/bundle-analyzer package, but I don't know which chunks are loaded by which pages.

Right now, the output of next build looks like this:

┌   /_app                                                      4.61 kB         117 kB
├ ● /[locale]                                                  7.59 kB         232 kB
├   └ css/4641472c8e3dea0827b7.css                             5.38 kB
├   └ /en
├ λ /[locale]/[org]                                            4.49 kB         233 kB
├   └ css/ed87a86cf5ab98379191.css                             3.96 kB
├ λ /[locale]/[org]/dashboard                                  2.96 kB         231 kB
├ λ /[locale]/[org]/dashboard/appts                            2.96 kB         231 kB
├ λ /[locale]/[org]/dashboard/people                           2.96 kB         231 kB
├ λ /[locale]/[org]/search/[[...slug]]                         2.52 kB         227 kB
├ λ /[locale]/[org]/signup                                     450 B           215 kB
├ λ /[locale]/dashboard                                        419 B           229 kB
├ ● /[locale]/login                                            2.92 kB         205 kB
├   └ css/39acfc9bc2c049ec4b5a.css                             1.28 kB
├   └ /en/login
├ λ /[locale]/search/[[...slug]]                               2.52 kB         227 kB
├ ● /[locale]/signup                                           414 B           215 kB
├   └ /en/signup
├ ○ /404                                                       2.57 kB         120 kB
├ λ /api/account
├ λ /api/appts
├ λ /api/orgs
├ λ /api/orgs/[id]
├ λ /api/redirect
├ λ /api/users
├ λ /api/users/[id]
└ λ /api/users/[id]/parents
+ First Load JS shared by all                                  117 kB
  ├ static/pages/_app.js                                       4.61 kB
  ├ chunks/commons.4e7daa.js                                   10.7 kB
  ├ chunks/d7be7a619d1110ded721a1f102b66b370b3b13c2.b82183.js  53.9 kB
  ├ chunks/edf3fb46.09128e.js                                  65 B
  ├ chunks/framework.126679.js                                 40.3 kB
  ├ runtime/main.91d6f0.js                                     6.28 kB
  ├ runtime/webpack.803cfb.js                                  1.34 kB
  ├ css/407651ee3d4b67a4780f.css                               128 B
  └ css/c51f0120853a257269f3.css                               20 kB

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)
●  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)

From that, I do know some things:

• I know which chunks are being loaded by all of the pages (that is logged by next build).
• I know the page-unique chunks (because the chunk filenames correspond to the page routes).

But I still don't know about some chunks and where they're being loaded. For example:

Where is chunks/ee76791a057a2d97d7c29a1b0c13f7cc0bf68bb2.js listed in the build output? Nowhere!

Describe the solution you'd like

A clear and concise description of what you want to happen.

The next build command should output all of the chunks that are loaded by the various pages (or, at least, the next build --verbose command that's described in #15281).

Ideally, you might also provide a built-in next build --analyze command or just a next analyze to analyze the bundle sizes.

[jeantil]

I think I read somewhere that the next.js team is working on better performance tooling for next.js.

In the meantime you can use some webpack tools to analyze your bundles dependencies. This requires using a custom webpack configuration in next.config.js

In your custom webpack configuration, define a customBundleAnalyzerPlugin configuration which generates the stats.json file, here is what ours loos like

webpack: function(config, { isServer }) {
  if (!isServer && process.env.ANALYZE === 'true') {
    const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
    config.plugins.push(
      new BundleAnalyzerPlugin({
        analyzerMode: 'static',
        reportFilename: './analyze/client.html',
        generateStatsFile: true
      })
    );
  }
 
  return config;
},

Note that using the BundleAnalyzerPlugin and generating the stats.json file makes the build considerably slower. We only found it to be worth it for browser bundles (hence the !isServer condition) and event so you don't want to have it run all the time: we use an environement variable to enable it (hence the process.env.ANALYZE === 'true' condition).

Once you have configured that, you can run ANALYZE=true next build which will generate and open the .next/analyze/client.html report and .next/stats.json

• client.html is useful to quickly and visually identify the largest bundles
• stats.json can be used at http://webpack.github.io/analyse/ to trace modules dependencies and reverse dependencies.

[nicholaschiang]

Thanks @jeantil! I've already got the FoamTree visualization using the @next/bundle-analyzer plugin (i.e. the ./analyze/client.html file) but that stats file should be useful.

The Next.js team definitely needs to look into better performance tooling (as that's a big part of the appeal of using Next.js in the first place IMO haha).

[nicholaschiang]

Yeah, so I just used that new config, and it definitely speeds up the build times from using the @next/bundle-analyzer plugin (I agree with you @jeantil; I really don't care about the server-side bundle sizes so only running it on the client makes sense).

But I still don't know which chunks are loaded by which pages (i.e. which chunks are adding to each page's "First Load JS" size). That was the main problem I was facing earlier.

[jeantil]

But I still don't know which chunks are loaded by which pages (i.e. which chunks are adding to each page's "First Load JS" size).

Webpack analyse chunk analysis has issues but the module analysis works and I found that more useful than tracking chunks. search your page in the module list click on the green hash and it will list all the imported depednencies which you can then recursively explore

[florian-milky]

But I still don't know which chunks are loaded by which pages (i.e. which chunks are adding to each page's "First Load JS" size). That was the main problem I was facing earlier.

Check .next/build-manifest.json
But I agree with you, it would be nice to have some kind of visual html report that would complement the webpack report

[armandabric]

I was looking to make progress on this when I found out this issue on webpack-bundle-analyzer site: webpack-contrib/webpack-bundle-analyzer#265

It seems that their are also looking to help our case

[jeantil]

in my latest comment on this issue I said:

Webpack analyse chunk analysis has issues but the module analysis works

To clarify I was talking about http://webpack.github.io/analyse/ and I tracked the issue to webpack/analyse#45 which was true at the time

I don't have time for this right now but if the issue in that PR is still present, maybe next could be changed to use numeric ids since analyse doesn't seem to want that change

[valscion]

You might want to try Statoscope to see if that would work for the use case defined here: https://github.com/smelukov/statoscope/blob/master/packages/ui-webpack/README.md