Output which JS chunks are loaded on which pages

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]

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

[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.