I was debugging a slow first paint on a client's dashboard last month, and after
ruling out the usual suspects — unoptimized images, render-blocking scripts, a
bloated font stack — the profiler pointed at something I didn't expect: icons.
Not one giant icon file. Dozens of small ones, imported inconsistently across
the codebase. Some as inline SVGs, some as a full icon-font stylesheet loaded
for four glyphs, some as base64 strings sitting directly in JSX. Nobody had
done this on purpose. It just accumulated, PR by PR, over a year of different
devs solving the same "I need an icon" problem in different ways.
The actual cost of icon sprawl
A few things compound here:
- Icon fonts load the entire glyph set even if you use six icons out of six hundred
- Base64-encoded SVGs inline in JS bypass caching entirely — every reload, every byte
- Mixed sourcing means mixed viewBoxes and stroke widths, so icons render at slightly different visual weights even at the "same" size
- No tree-shaking possible when icons are pulled from five different npm packages with different export patterns
None of this shows up in a quick glance at the UI. It shows up in Lighthouse
scores and in that specific kind of visual inconsistency where nothing's
wrong, exactly, but nothing lines up either.
What actually fixes it
The fix isn't "optimize your SVGs" — it's sourcing discipline. Pull icons from
one consistent set instead of wherever's fastest in the moment.
I've been using a free SVG icon library for exactly
this — the icons are lightweight, consistently structured, and since they're
plain SVG (not a font, not base64 blobs), they play nicely with tree-shaking
and don't drag in glyphs you're not using.
A couple of things worth doing if you're auditing your own icon setup:
Standardize on one stroke width and grid. Mixed sourcing is the #1 cause
of icons that look "almost right" next to each other. Filtering by style
before you start pulling icons saves you from this later.
Use an SVG editor instead of hunting for a replacement icon. If an icon's
90% right, don't add a whole new dependency for the other 10% — edit it directly
and keep your bundle from growing.
Browse by category, not by search term. Search-driven icon picking is how
you end up with five visually different "settings" icons across a codebase.
Category collections keep you inside
one consistent set.
TL;DR
Icon sprawl is a real, measurable performance and consistency cost — and it's
almost always a sourcing problem, not an optimization problem. Fix it at the
source, not with another compression step.
Top comments (0)