Optimize bundle size (now 317KB with v4)

[masbaehr]

Hi, this is not an issue but i'd like to know if there is some room to improve the bundle size, or if there is something i can do as a user to reduce the size. currently it is like this:

https://bundlephobia.com/result?p=@material-ui/core@4.11.2

There seem to be some components which are rather big in comparision for example TablePagination SwipeableDrawer TabScrollButton

I was unable to check for the v5 though yet. Will it improve?

[oliviertassinari]

@masbaehr You can track the bundle size of v5 using https://bundlephobia.com/result?p=@material-ui/core@next. We have made significant progress in v5 compared to v4:

• split IE11 into a different bundle -6kB
• migrate to emotion -5kB
• Popper.js v2 upgrade -700B

We still have a few opportunities to improve bundle size with better tree-shaking between components:

• [SelectField][material-next] Introduce new component #21782 should significantly reduce the cost of a standalone TextField component
• Improve treeshaking material-ui-pickers#1670 surface how the architecture of the date pickers might be suboptimal

[oliviertassinari]

⚠️ the total cost is almost useless, nobody should need to import all the components in a single page.

Instead, consider the cost of individual modules but consider that when importing two modules, the bundle size isn't the addition of the two reported sizes, there is a lot of shared modules.

[masbaehr]

In a single page - this is true. But isn't everything still packed into one *.chunk.js file? That is at least the case if you're not using code-splitting. I already do this for heavy stuff like recharts, but material-ui being something which is needed almost everywhere I find it rather hard to do this. Throughout all the pages, I use most of the components somewhere. While 381k 111k gzipped is not much per se, the thing is, it adds up rather quickly.

[eps1lon]

While 381k 111k gzipped is not much per se, the thing is, it adds up rather quickly.

With what does it add up though? Most of the components implement base UI patterns on the web. We don't recommend that you import 3 different Autocomplete implementations in your page. So it shouldn't ever add up in your bundle.

I already do this for heavy stuff like recharts, but material-ui being something which is needed almost everywhere I find it rather hard to do this.

What makes this easier to do with recharts but not Material-UI?

Again, are you importing all of material-ui everywhere?

It would be more helpful to share the bundle you're currently shipping. That helps us finding duplicates we can potentially eliminate. For example, maybe most of our users need a different popper library in which case we should use that instead of @popperjs/core. Or maybe there are other Autocomplete implementations that are preferred over our solution. A blanket "reduce the bundle size" is not actionable for us since we always try to reduce our footprint on the final bundle. It falls under the same category as "make components more accessible" or "make components faster" or "add more components".

[masbaehr]

I have some heavier dependencies like jodit editor (600KB) or the already mentioned recharts (645KB) - which i have now externalized using lazy loading patterns. I never have imported all of material ui in the pages only some parts of it.

So i just noticed material-ui being a large portion of it. But i understand your point i'm not ranting i just wanted to ask if there is some room for improvement. Maybe even improvement i can personally apply for material-ui.

E.g if i never import the yellowish marked components, will they be removed from the bundle?

I know there are some other dependencies which can probably be replaced. This is what i will do next, going trough them one-by-one

[eps1lon]

I never have imported all of material ui in the pages only some parts of it.

From the the bundle screenshot you posted it looks like you do import all of Material-UI.

Other notes: material-ui-phone-number being 100kB big is suspicious. They have a dependency on lodash and are published as commonJS so I do suspect they're bundling all of lodash.

[masbaehr]

This is how i usually do the imports where i need something in material-ui

Curious fact: I never imported SwipeableDrawer , but it is being built into the file. Any reason why this is? (I use Drawer though)

[eps1lon]

Curious fact: I never imported SwipeableDrawer , but it is being built into the file. Any reason why this is? (I use Drawer though)

Something in your app is responsible for importing all of Material-UI it seems.

[masbaehr]

material-table-core/core#45 Maybe it's material-table triggering it