Component size calculation

[itaymendel]

Bundle size impacts the overall performance of Web (browser-based) applications. To help understand the potential impact of adding a component to your application you can find the Component Size documented at the top of the overview tab.
Bit's approach is to surface the component size as early as possible so any possible consumer will understand the potential cost of adopting a component as soon as possible. The calculated size does not aim to give you deep analysis about how adding a particular component to your application affects the overall size of your application.

Solving for more concrete bundle size issues we recommend using additional tools to be a part of your stack. From IDE plugins, CLI tools and bundle analyzers that are more contextual and truly understand the impact of each dependency, all the way to techniques like lazy loading and code splitting that help mitigate a large bundle and still keep app's performance.

How component size is calculated in Bit

Size calculation starts by Bit bundling the component, starting from it's main entry point (by default - the index.ts file). The bundle will contain all required files and dependencies. Bundling is done with Webpack, where minification is managed by Terser plugin with ESBuild. The size also includes all relevant CSS and assets.

How can component size affect your code

Given that the Component Size data is calculated for each component in isolation, it does not mean this is the actual size you will see for this component. There are several reasons for this:

Tree shaking

Most apps take leverage of their bundler's tree shaking capabilities to drop unused modules. It means that the final size of your app's bundle is affected by what you actually import. This may be smaller than the size of the whole component.

Common dependencies

Common dependencies between components (CompA and CompB use CompC), will be counted for each component. Moreover, if your application already uses CompC, the component-size for either CompA or CompB can't take this into account. It means that there will be deduping of common dependencies done by your package manager, which will result in a smaller impact on the result bundle size of your app.

Optimize your component size

If you are looking to reduce component-size consider the following:

• Use bundle analysis on component - this helps you figure out what can be removed or changed in the component's implementation to reduce its size. For example, large dependencies.
• Build concrete components with thin API layer - Having a single component with a lot of responsibilities and a wide API will add more code and dependencies, even if only used in unique cases. Breaking down a complex component to 2-3 smaller components (with shared code between them) can help your consumers fetch only the component they need.
• ESM - as Bit uses tree shaking as part of the size calculation, using ESM as a compilation target for your components means better results for tree shaking.

I see a difference in component size in my IDE plugin / Bundle analyzer / etc...

There are various tools that calculate size for dependencies. Some of them use different internal mechanisms and others can take into account more application-specific and contextual data to how you use a component in your application. This may result in you seeing different bundle-size impacts of a component reported by these tools.

For example, an IDE Plugin may know what you actually import from the component, and can tree shake other parts, or a bundle analyzer can see that there are shared dependencies with your app, so it will not count for them when figuring out the component's size.

The component-size item is aimed to be a north start for developers looking to be more performance oriented when deciding on how they want to build their components.