[docs-infra] Document bundle size of each component

[oliviertassinari]

Summary

Bundle size matters. I think it's important we document it in the docs. Documenting:

• Forces us to measure it
• Means developers know we know what it is
• Means developers easily know if it's good enough for their use cases

For example, see propeldata/ui-kit#157 who are looking for a select component, there is a reputation for bloat to debunk (Base UI) and solve (Material UI).

Examples

I tried two iterations:

• [docs-infra] POC Bundle size docs material-ui#40592
• [docs] Document bundle size material-ui#40549

but never had time to work on this to finish it (It's why I was eager to fill: https://www.notion.so/mui-org/React-Engineer-Docs-infra-02023ab7104241888ca2ab3bcb32e19d). I was more trying to fix a regression in the DX.

Motivation

It's related to #201.

Closing this I think involves two steps:

• Implementing it for Base UI
• Supporting it for docs-infra so Material UI can also show components' size (assuming we fix their size)

Search keywords: -

[atomiks]

Displaying bundle size accurately is a difficult problem. If you only use one single component from the library, then it’s fully accurate. However once you start using multiple components, the numbers become inaccurate as the sizes don’t add up simply/cumulatively as displayed due to shared dependencies/logic/compression, etc.

I propose we take a non-naive approach to this. https://bundlejs.com allows you to export the specific components you're actually using, treeshaking enabled, to see a true picture. We could have a UI for this on the website where they select all the components they're using/will decide to use to get a true picture of the bundle size.

[oliviertassinari]

Oh, I forgot I had opened mui/material-ui#40591. The best I could figure out in the past was pastelsky/bundlephobia#389.

[Link2Twenty]

Something Radix did well was allowing you to install just the parts you needed, if you want the select component you run npm install @radix-ui/react-select and that's all you get (with it's dependencies of course). This also means I can look at the npm page and see that the component is going to cost 328 kB. I will say they could do some work to make each npm page feel like it's real when it's too bare it feels like somewhere you've ended up by mistake.

By comparison if I want to use the base-ui select (@base-ui-components/react/select) I have to get the whole of @base-ui-components/react which I know rationally will treeshake on build but at a glance looking at the npm page I see 3.48 MB which feels like a 10× increase.

By splitting up each component you get people to see they can cherry pick the bits they want and you get the added bonus of seeing the sizes on npm for "free".

[atomiks]

By splitting up each component you get people to see they can cherry pick the bits they want and you get the added bonus of seeing the sizes on npm for "free".

In practice, cherry-picking the components you need works much better with monopackage tree-shaking: splitting up components into separate packages causes difficult bugs with version mismatches (dot point 3): #1700 (comment)

Radix's docs have the issue outlined in #602 (comment). Each component page having a size cost is misleading if you were to add them together cumulatively, as in real apps you're likely using multiple ones that are highly interdependent.

For instance Menu and Select share many dependencies that individually have a large upfront cost but when you actually use them together, the cumulative cost is much less than adding their individual costs.

This is why exporting what you need and seeing the resulting production bundle is best. Here's an example of Base UI latest canary with a Vite project:

# Baseline: 
dist/assets/index-55j1Zgeo.js   143.62 kB │ gzip: 46.09 kB

# All Menu features:
dist/assets/index-BbpivL1E.js   256.11 kB │ gzip: 84.61 kB

# All Select features:
dist/assets/index-JemfAkez.js   255.15 kB │ gzip: 84.40 kB

# All Select and Menu combined:
dist/assets/index-D6lmjh9y.js   282.85 kB │ gzip: 92.58 kB

I wouldn't consider the npm package install size a relevant metric though unless it's so huge that it affects install times - it only represents the cost to your disk space, which is a lot less important than the cost of end users downloading your JS bundle

[Link2Twenty]

I do agree, my only thought here was this issue seemed to be more about optics and getting rid of the "bloated" reputation. People like to see small numbers even if those numbers don't mean much in practice 🤷.