Every tool so far fixes problems after they ship. BundlePhobia stops them before they start: paste a package name and see exactly what it'll cost your bundle — its size, its download time on a real network, whether it tree-shakes, and what lighter alternatives exist. The cheapest performance fix is the dependency you never install.
Shift left
Weigh it before you install
Once a dependency is woven into a shipped feature — used by other devs, baked into tests — ripping it out is technical debt that's hard to pay down. The time to ask “is this package worth its weight?” is beforenpm install, not after users complain the app is slow. That five-second check is the highest-leverage habit in this whole series.
See it
Look up a package
Pick a package and read its cost — then click a suggested alternative to compare. Notice how a “small” choice like dayjs sits next to a heavyweight like moment or echarts:
InteractiveBundlePhobia — the cost of a dependency
Search a package:
Minified
290 KB
Minified + Gzipped
72.1 KB
Download time
Slow 3G
1.4 s
Emerging 4G
82 ms
heavynot tree-shakable1 dependencyShips all locales; not tree-shakable.
Lighter alternatives — click to compare:
Minified vs gzipped size, real download times, tree-shakability, dependency count, and lighter alternatives. moment is 72 KB gzipped; dayjs does the same job in ~3 KB.
The signals
What to read
Gzipped size — the real download cost. The headline number.
Download time — that size translated to seconds on slow 3G / 4G. A 328 KB chart lib is ~7 s on slow 3G — brutal for some users.
Tree-shakable? — if not, you pay for the whole thing even for one function.
Dependencies — a small package that drags in three others isn't small. Also a place vulnerabilities hide.
Version history — sizes drift between versions; sometimes an older one is leaner.
Alternatives — the suggestions are the gold: same job, a fraction of the weight.
Smaller isn't automatically better
An alternative that's 80% smaller might lack a feature you need. The tool gives you the candidate; you still verify it does the job. But often — moment → dayjs, a whole UI kit → one component — it's a free win.
Existing projects
Auditing what you already have
BundlePhobia isn't only for new installs. You can hand it your whole package.json and it ranks every dependency by size, surfacing the heaviest ones first. That's your refactor hit-list: swapping one rarely-used heavyweight for a lighter equivalent is often an easy, low-risk performance win on a legacy app.
Q1Multiple choice
BundlePhobia suggests replacing your date library with one 85% smaller. Before swapping, what must you check?
Q2Multiple choice
A package reports a small 'self' size on BundlePhobia, but installing it balloons your bundle. What did the headline number hide?
Q3Multiple choice
Library A is 100 KB but fully tree-shakable; Library B is 30 KB but not tree-shakable. You'll use ONE small function. Which likely ships fewer bytes?
Q4Sort each scenario
Free win, or verify-first? Smaller is only better if it still does the job.
moment → dayjs (same API, ~3 KB)
A full UI kit → the single component you actually use
A rich date lib → an 85%-smaller one that lacks the timezone support you need
A charting lib → a lighter one missing the chart type your dashboard requires
A heavy uuid generator → a tiny standards-based one with identical output
Key takeaways
→BundlePhobia is a pre-install tool: know a dependency's cost before you commit to it.
→Read gzipped size + download time, and whether it's tree-shakable.
→Watch hidden dependencies — a small package pulling in others isn't small.
→Its alternatives are the payoff: moment → dayjs, heavy chart lib → lighter one.
→Feed it a whole package.json to find easy wins in an existing app.