I've inherited four different codebases in the last two years, and every single one of them had the same problem hiding in plain sight: icons.
Not a broken build. Not a dependency hell. Icons. Specifically, the way most teams handle them — a pile of inconsistent SVGs dumped into /assets/icons, half of them exported from three different design tools, none of them optimized, some of them still carrying
tags and editor metadata that add zero value and real weight to your bundle.</p>
<p>Nobody thinks about icons as architecture. That's the mistake.</p>
<p>The three failure modes I keep seeing</p>
<ol>
<li>Inline SVG sprawl with no consistency</li>
</ol>
<p>Someone pastes an SVG straight from Figma into a component. Then someone else does the same thing six months later, from a different export, with different viewBox dimensions and a different stroke-width convention. Now your icon set doesn't scale uniformly and nobody notices until a designer files a bug about "icons looking off" that takes an afternoon to actually diagnose.</p>
<ol>
<li>PNG icons because "it was faster"</li>
</ol>
<p>I get it. But raster icons at multiple resolutions for retina support is how you end up shipping 40 versions of a magnifying glass icon. SVGs exist specifically to solve this problem and teams still route around them out of habit.</p>
<ol>
<li>No pipeline for optimization</li>
</ol>
<p>Raw SVG exports carry a lot of junk — comments, unnecessary groups, editor-specific attributes. If you're not running them through an optimizer before they hit production, you're shipping bloat you don't need.</p>
<p>What actually fixed this for me</p>
<p>I stopped treating icons as a copy-paste afterthought and started treating icon sourcing as part of the build process, same as any other dependency decision.</p>
<p>For sourcing, I moved to a library of Free SVG Icons with a genuinely large catalog — categorized properly instead of one giant unsorted dump — so I'm not hunting through inconsistent naming conventions across five different free-icon sites just to find one arrow icon that matches my grid.</p>
<p>For actually editing markup before it goes into a component, their SVG code editor lets you paste raw SVG and clean it up — adjust viewBox, strip cruft, export straight to code — without round-tripping through a design tool just to fix a path.</p>
<p>If you're dealing with legacy assets that only exist as PNGs (we've all inherited that folder), the PNG to SVG converter traces them into actual vector paths instead of just wrapping a raster image in an SVG tag, which some "converters" absolutely do and it's infuriating.</p>
<p>For teams shipping a lot of visual assets, the image compressor is worth running things through before they ever touch your repo — smaller payloads, faster CI, fewer Lighthouse complaints.</p>
<p>And if your team designs in Figma before it ever becomes code, the Figma plugin means your designers are pulling from the same consistent source your codebase does, instead of two people quietly maintaining two different icon sets that drift apart over a year.</p>
<p>The actual point</p>
<p>Icon management isn't glamorous, so it never gets prioritized — until you're the one debugging why the sidebar icons render at three different visual weights on production. Treat it like the small architectural decision it is, not an asset-folder afterthought.</p>
Top comments (0)