[GeoAtreides]

Seeing that svg is text, enabling gzip compression on server will certainly help with reducing size; especially if using lots of inlined repeating svg elements (like icons, glyphs, etc). I also imagine SPA that compile to one index.js file can massively benefit from inlining svg + server compression (also, very cacheable!)

[vardump]

He wasn't talking about text, but the rendered image.

[GeoAtreides]

Unless I'm missing something, svg is an xml-based vector image format, being sent by the server as text (xml) and rendered by the user's browser.

[vardump]

SVG is rendered (rasterized) by the browser. The browser can then cache the rendered image to avoid wasting CPU cycles.

[berkes]

Svg can, and often will, include (embed) raster images.

But even when not: in practice an SVG will have hundreds or thousands of XML elements (nodes) to draw rather simple-looking shapes even.

[GeoAtreides]

SVG often includes raster images? That's very surprising to me. I can see some use cases here and there, sure, but using a vector format to 'often' include raster images... i dunno.

Thousands of XML elements is the ideal case, compresses extremely well.

[squidbeak]

An example, many of Inkscape's filters depend on raster samples that need to be embedded. Complex gradients are also rasterised.

[vardump]

SVG can be rasterized into a cache and just blitted or composited as necessary.

No point to waste CPU cycles rasterizing same SVG image repeatedly.

[GeoAtreides]

One would assume the browser already renders the svgs once and the caches it. Maybe, who knows, probably depends on the browser.