Bundle Size, Honestly: A 771-Byte Button and the CSS Trade-Off

Measured with `size-limit`, minified and brotlied, React excluded: a lone `Button` is 771 B. `Modal` including focus trap, scroll lock and portal is 2.9 kB. A complete landing page from `Hero`, `FeatureGrid`, `Pricing`, `FAQ`, `CTA` and `Footer` is 2.7 kB. All six charts together are 8.3 kB. Every component imported at once is 47.6 kB.

Those are real measurements from the build, not estimates. The reason a lone `Button` is meaningfully smaller than the whole library is per-file ESM plus `sideEffects: false`, which lets a bundler drop everything you did not import.

`styles.css` is 192 kB raw and 27 kB gzipped, and it is a single stylesheet. An application using five components downloads all of it. There is no tree-shaking for the CSS because there is no build step that could do it — which is the direct, unavoidable cost of 'one import, no build configuration'.

If your priority is the absolute smallest CSS payload, a Tailwind setup that purges unused classes will beat this and it is not close. That is a legitimate reason to choose something else, and pretending otherwise would be dishonest.

CSS caches. The 27 kB is downloaded once and then served from cache on every subsequent page view, so on a multi-page site the amortised cost is small. It is also non-blocking to parse in the way JavaScript is — 27 kB of CSS and 27 kB of JavaScript do not cost the same, because the JavaScript has to be parsed, compiled and executed.

And the alternative has a cost that does not show up in a bundle report: every developer on the project spends time on build configuration, and every new project pays it again. That time is real even though no tool measures it.

A single-page micro-site using three components. There, 27 kB of CSS to render three components is proportionally poor and the caching argument does not apply because there is no second page view.

Also an app where CSS is already tightly optimised and measured. If you have a 12 kB purged stylesheet today, adding 27 kB is a regression you would have to justify. Know which situation you are in before choosing, rather than after.

Every library's published figures are measured under conditions that flatter them, mine included. The only number that matters is what your application ships, so measure before and after with your own bundler on your own code.

Watch total transferred bytes, not just the JavaScript bundle, and check what actually executes on the main thread. A library with a larger stylesheet and no runtime can easily beat a smaller one that ships a styling engine, and a bundle-size comparison alone will not show that.

Runtime cost matters more than transfer size for interaction latency. A static stylesheet does no work at runtime; a CSS-in-JS engine computes styles during render, every render. That cost lands on the main thread while the user is waiting.

So the honest framing is: this library trades a larger, cacheable, non-executing CSS payload for a smaller, non-executing JavaScript payload. Whether that is a good trade depends on your app, and you should verify it rather than take my word for it.