Maybe utilize shadow DOM for repetitive icons?

[vintprox]

Repetitive inline SVGs scattered all over the page can seriously affect the performance. Let's say, the example behind that can be list with >100 entries, and each has kind of 3 icons. Every time we add more entries, page is being repainted: now imagine directly injecting each icon, especially complex one, into DOM.

Inlined elements of SVG icons that were not intended to be changed individually will use GPU exceedingly.

Solution for that is to inject such repetitive icons once and reference them in immutable SVG elements (hence utilizing shadow DOM).

Keep in mind, that it's proposed just as one of options - icons should still be inserted as they were if no such option is used on component icon. We basically need custom prop (let's call this reuse, repetitive, or immutable) that will show SVG referencing to hid icon in body that was injected once instead of individually inlined SVG.

Also...

I think that because of introducing injecting logic this project will evolve from bare components set to Vue plugin.

Injecting reusable icons should be implemented both as Vue plugin and as part of server-side rendering logic (vue-ssr).

In perspective

Later, once-injected icon elements may vary by name (which may be specified as value to reuse prop, for example), like to have similar icon but with changes that apply to SVGs referencing it.

Fine reads

Reply from Andrew about performance boost. Statement about "bloated HTML cache" as downside of individual inlining same SVGs (related to SSR).

[vintprox]

Hopefully, now when I thought of that twice, I actually can already include each icon once, add it to root template, and reference to this icon with SVG via <use> tag. Hence my proposal has no use, if there is simple solution already 😁

[therufa]

Actually, @vintprox thanks for the idea. The thing is that optimizing crossed my mind a few times already, but you gave me an idea.

Also why referencing a single import didn't happen yet is because of the immense size of the icon set, which I believe is somewhere in the neighborhood of 1.5 MB compressed. Tree shaking is also something that is not working reliably (at least it wasn't last time I checked).

Anyhow. That with including each icon once and referencing it is a brilliant idea, what could be done is some sort of provider which stores any icon which was introduced, and the icon components only reference the content as you proposed. This could work somehow like when a component is created, it registers the path to the provider and so on.

Thank you honestly for your ideas @vintprox!

[vintprox]

No problem, @therufa, and I won't really mind if it's the issue of low priority, because workaround is THAT simple, tho it took me another writing to figure it out 😂