On SVGs & performance: is there a perf reason to inline an SVG image (so the XML code is visible in your HTML source) rather than pulling in an external resource e.g. <img src="zonk.svg">? It feels a bit like inlining images with base64, which doesn't therefore take advantage of the browser cache.
@brucelawson I try to avoid inlining SVG until I actually need it for styling. Unfortunately, “inlining to HTML” sometimes means bloating your JS bundle if the markup is client-side generated. But you can have both: external SVG sprite with all icons and inline <use> that’s stylable. See https://pepelsbey.dev/articles/svg-sprites/#external-svg
@pepelsbey@brucelawson awesome post! I also still use a SVG symbol sprite for my icons, works great. One issue I have with it is that you can't host the SVG sprite on a different domain though (i.e. on a CDN).
@mxbck@brucelawson Thank you! There’s another downside: I couldn’t find any solution to make icons with gradients work cross-browser. Sprites mess up with the SVG referencing system, and there are bugs in current browser implementations.
@pepelsbey@brucelawson Good to know! I'm aware that it isn't ideal for more complex graphics but honestly in the last 10 years or so I've never had a usecase other than "single-color icons, styleable with CSS".
@nhoizey I don’t have a strong opinion about that. I’ve probably seen browsers treating <img> more seriously regarding rendering performance. These icons seem to me like decorative, not content images. But I remember using <img> for similar tasks as well.
@brucelawson Lots of responses here. My considerations:
• is the SVG smaller than the HTTP request to call it?
• will I re-use it enough times to warrant making it a sprite, expandng the file size / HTTP request size consideration?
• does its absence from a dropped connection affect the meaning of the thing?
• do I need to style parts of it to match page colors / themes?
• do I manipulate it with script?
SVG files can be pretty small and the per-request overhead of even a HTTP/2 or 3 request can be bigger than the file itself. In an HTTP1 request the header size can easily be many times bigger than a small SVG file. You can also get around this issue by using SVG sprites with symbol elements
Add to that the additional benefit of inlining SVG (inheritance and animation) and inlining becomes a compelling option for icon-sized SVG
@brucelawson Inlining with Base64 OTOH introduces its own overhead which offsets the gains from avoiding a request header. If you're working with HTTP2 or HTTP3, the benefit of Base64 inlining isn't likely to be meaningful.
@brucelawson I think you're right. For me, the main benefits of in-lining SVG is it becomes part of your DOM: you can then interact with it in JS, style it or animate it in CSS and makes the content of the image more accessible.
@brucelawson You can style the SVG contents with external CSS if it is inline. You can not if it's loaded as an asset. This is why I recently posted... https://mstdn.social/deck/@mattwilcox/111742704257472762 and someone went and built a solution! (scroll down, I had a better idea than the first toot, and the solution is a simple web component wrapper. It likely needs more testing)
Add comment