Post

🌠 The best icon pack in the world right now, IMO, is Lucide (lucide.dev). It builds on @colebemis.com’s incredible work with Feather Icons, extending it from ~300 icons to >1500. It has fully-typed bindings for React and many other frameworks. And I just found out: they’re even more optimized! 🧵

Unfortunately, their React package (and others too I imagine) are rendering SVGs via JS(X) which is a very, very bad idea. Runtime perf & memory use take a hit that can be completely avoided with other techniques; far better to use <img> or <use>.

Do you have examples of where this actually causes noticeable perf issues? Because I’m using it on my blog and it’s totally fine. <10kb added to my bundles, even before gzipping. And unlike <img>, it requires no extra network requests to fetch the icons, they’re inlined in the server-generated html.

I suppose <use> could make a noticeable difference if you use the same icon 100+ times on one page, but Lucide’s icons are tiny. Like, I could imagine people using ArrowRight for a bullet, and having lots of bullets. But the code for that icon is: <path d="M5 12h14"/><path d="m12 5 7 7-7 7"/>

I feel like this is the sort of optimization that gets people really animated online, but I’ve been using inline SVGs for years and I’ve never had an issue with it. But maybe there are some popular examples of large projects that did solve a real problem by switching to a different format?

For me it’s a death-by-thousand-cuts type thing, so if there’s low-hanging fruit for keeping the payload small I’ll try to take it from the start. I stole a script from @kentcdodds.com Epic Stack that converts and optimizes them for me so I rarely think about it!

0 reposts7 likes

Precisely, you’re paying 3-4x more to have that SVG rendered by JS(X) compared to other methods. On its own it’s unlikely to cause issues but perf is a zero-sum game. having icons setup well frees time to work on other, more difficult problems.