Next.js: `granularChunks` increase page size

[petvas]

Bug report

Describe the bug

Next version: 9.1.7
I enabled granularChunks in next.config.js

experimental: {
  granularChunks: true,
},

The pages sizes are went up drastically:

Before:

Page                    Size
┌ λ /                   1.04 kB
├   /_app               21 kB
├ λ /category/[id]      9.66 kB
├ λ /product/[id]       2.41 kB
└ λ /search             8.66 kB
+ shared by all         194 kB
  ├ chunks/commons.js   189 kB
  ├ runtime/main.js     4.85 kB
  └ runtime/webpack.js  746 B

After:

Page                     Size
┌ λ /                    121 kB
├   /_app                137 kB
├ λ /category/[id]       135 kB
├ λ /product/[id]        126 kB
└ λ /search              133 kB
+ shared by all          69.3 kB
  ├ chunks/commons.js    22.5 kB
  ├ chunks/framework.js  40.8 kB
  ├ runtime/main.js      5.23 kB
  └ runtime/webpack.js   746 B

System information

• OS: Windows 10
• Version of Next.js: 9.1.7

[Timer]

The page sizes have not increased — do note that the "shared by all" chunk is now much smaller. These sizes do not reflect individual size, but all of the dependencies which may be shared by some others.

[petvas]

Edit: After I checked the generated files the file size is not matching at all I think it is a different issue.

Maybe I do not understand correctly but after the user visits al the pages he needs to download all the chunks:

1.04 kB
21 kB
9.66 kB
2.41 kB
8.66 kB
194 kB
189 kB
4.85 kB
746 B
======
419.73600 kb



121 kB
137 kB
135 kB
126 kB
133 kB
69.3 kB
22.5 kB
40.8 kB
5.23 kB
746 B
======
659.34600 kb

The 2nd scenario is 30% bigger.

---

And just visiting only 1 page (main page example:

1.04 kB + 21 kb + 189 kb + 4.89 kb + 746 b = 216.67600 kb
vs
121 kb + 137 kb + 22.5 kb + 40.8kb + 5.32 kb + 746 b = 327.36600 kb

[Timer]

That's not how the math works! We're going to rework this output. Please see the total emitted size of your .next/static/ folder between two clean builds across these versions and you should see it's less.

[petvas]

Ok thank you, the output was confusing, I see the folder size is smaller. Meanwhile, there is more request sent to the server at the 1st-page load.

[Timer]

This has been changed in the newest Next.js canary. Can you please retry?

[petvas]

Tested on 9.1.8-canary.8:

Page                                                    Size     First Load
┌ λ /                                                   818 B        219 kB
├   /_app                                               22.5 kB      205 kB
├ λ /category/[id]                                      3.6 kB       234 kB
├ λ /product/[id]                                       3.04 kB      225 kB
└ λ /search                                             1.12 kB      231 kB
+ shared by all                                         205 kB
  ├ static/_buildManifest.js                            305 B
  ├ chunks/122263ca4811193d0a92081d2427d6b42500484c.js  114 kB
  ├ chunks/commons.js                                   22.4 kB
  ├ chunks/framework.js                                 40.8 kB
  ├ runtime/main.js                                     4.55 kB
  ├ runtime/webpack.js                                  746 B
  └ static\<buildId>\pages\_app.js                      22.5 kB

Thanks for the update much easier to understand now!

[sheerun]

If they are shared by all then why can't they be made one?

[Timer]

@sheerun for persistent caching reasons — that way one update doesn't invalidate all of your shared javascript. Also, more files are faster to download than a single on H2.

Bigger files are only better for H1.1.

[ycscholes]

@Timer is it possible to merge runtime/main.js and runtime/webpack.js? it seems runtime/webpack.js is very small all the time.