Bundle analysis shows one dependency accounts for roughly 40 percent of your main bundle. How do you decide between replacing it, deferring it, or accepting the cost?

## Why the percentage alone decides nothing Share of bundle is a ratio, and ratios move when either term moves. A dependency at 40 percent of a small, well-tended bundle may be a smaller absolute cost than one at 15 percent of a bloated one. The number tells you where to look; it does not tell you what to do, and treating it as a target is how teams end up doing expensive work with no measurable outcome. The first questions are about placement and usage, not about the library itself. ## Question one: who pays, and when? A dependency needed by every visitor before the first screen renders is in a completely different category from one used by a single admin screen or opened behind a button. If analysis shows the second, the whole conversation usually ends there — move it off the critical path and the cost becomes something a small minority of sessions pay at a moment when they are already waiting for something. This is why per-chunk attribution matters before any decision: the same package can be a serious problem or a non-issue depending on which chunk it landed in. ## Question two: how much of it do you use? There is a meaningful difference between a library you use across dozens of call sites and one you pulled in for two functions. Check the actual call sites. If the used surface is small, the options are good: a narrow, well-scoped replacement, or an implementation of the two functions you need. If the used surface is broad and the library is doing genuinely hard work — internationalisation, timezone handling, rich text, charting, cryptography — the size is often the price of correctness, and hand-rolling it is how you acquire a decade of subtle bugs the library already fixed. A useful sanity check: whatever the replacement is, would you be willing to own its edge cases? For date and timezone handling, text segmentation, or locale-aware formatting the honest answer is usually no. ## Question three: what does the alternative really cost? Every swap is a migration. Price it out loud: - How many call sites change, and are they covered by tests? - Does the replacement match behaviour at the edges — rounding, locales, empty and error inputs? - What is the review and QA burden, and who carries the regression risk? - Is the replacement maintained, and are you trading a known heavy dependency for an unknown light one? A lighter alternative that is unmaintained, or that quietly drops the locale support you rely on, is not a saving. Neither is a saving that arrives with a bug in production. ## Question four: what does it buy? Tie the change to a number someone already watches. A reduction in bytes that does not move a loading or responsiveness metric for real users is bookkeeping. Conversely, if the dependency sits on the path that blocks the first render for the majority of sessions, its cost is likely visible in the field data, and the case makes itself. This is also where you check whether the bottleneck is even the bytes. A large library that is downloaded but barely executed costs transfer and parse time; one that runs heavy initialisation on startup costs main-thread time as well, and that second cost usually dominates. Two dependencies of identical size can deserve opposite decisions. ## The order the options usually fall in In practice the cheapest interventions come first, and each one may end the discussion: 1. **Move it off the first-screen path** if it is not needed for the first screen. Low risk, often large effect. 2. **Import less of it** if the library supports narrower entry points and you only use part of it. 3. **Replace it** when the used surface is genuinely small and a maintained lighter option matches behaviour. 4. **Accept it** and record why — with the size noted so the decision is revisited if the library grows or usage shifts. The fourth option is not a failure. A team that can say "this library is 40 percent of our main bundle, it is load-bearing, we checked, and here is what we do instead" is in a much better position than one that swapped it out and cannot say whether anything improved. ## The organisational half The deeper problem is usually not this one library but how it arrived. A dependency that large rarely lands deliberately; it arrives as a transitive dependency, or through a convenience import nobody weighed. The durable outcome of an investigation like this is not just the decision — it is that the next heavy addition is visible when it is proposed, rather than discovered a year later in a bundle report.