My favorite real world example of this was adding a bunch of 2-tone graphics to a website that looked like hand-drawn sketches. The designer insisted they have to be SVG because vector graphics scale better.

The SVG was 20MB. The PNG version at huge resolution was 20kB.

PNG is really good when you have a few flat colors. SVG is really bad when you have lots of fine detail.

▲

klysm 5 days ago | parent | next [-]

Fine detail isn’t really the metric to use when thinking of SVG size. 20MB just sounds like a catastrophic degenerate export from shitty software

	▲	immibis 2 days ago \| parent [-]
		They said halftone, so I imagine every pixel became a circle.

▲

pxoe 5 days ago | parent | prev | next [-]

Have to wonder what those 20 MB SVGs were like and whether they could've been optimized as SVG still. Doesn't seem to add up that at "huge" resolution that PNG would be that small either.

▲

jvanderbot 5 days ago | parent | next [-]

PNG keeps a count of sequentially-same color pixels (not really but roughly speaking) instead of keeping pixels themselves. So scaling a monocrome png image means just changing the count entry (very roughly speaking), so it'll be nearly zero cost.

What I mean is, if you have a million pixels of the same color (0xDEADBEEF maybe), then PNG will call that 1,000,000 x OxDEADBEEF. So, it scales very nicely for few-color, sparse or "blocky" images.

▲

Swizec 5 days ago | parent | prev [-]

> Doesn't seem to add up that at "huge" resolution that PNG would be that small either.

Well maybe not huge huge. Like 1000px wide so they look nice on retina screens.

The key is that these images were just 2 contiguous color areas. Black and transparent. PNG is really good for that because the compression algorithm works on the basis of contiguous color areas.

	▲	pxoe 5 days ago \| parent [-]
		Was there any attempt to optimize SVG? If it was just a single object/path, it'd be pretty small (if it was optimized/simplified for curves/node count, it could be even smaller), and then it could be harder matching that size with PNG or it wouldn't be that much of a difference.

▲

kevindamm 5 days ago | parent | prev | next [-]

I wonder how much you could have compressed that SVG if you stored the broad strokes and added the perturbations with javascript, after loading.

	▲	afavour 5 days ago \| parent [-]
		Client side JS will always be slower than letting the browser render the PNG.

▲

illwrks 5 days ago | parent | prev [-]

I’ve worked with various graphic formats for web… for over 20 years at this stage.

It’s incompetence to blame rather than file-size, maybe designers or someone in the briefing process that is uninformed that confuses the requirements for everyone else.

Also… I don’t trust Figmas quality with exported SVG. Just type some text, export it and see how it degrades…

▲

RandallBrown 5 days ago | parent [-]

Unless Figma is embedding a raster image of the text in the SVG, how is that possible?

	▲	illwrks 5 days ago \| parent [-]
		When I was looking at it a few months ago, vector lettering (an outlined name in a logo) when exported the curves were goofy. I brought them into Illustrator and overlaid it on the actual logo and there was a clear difference. Couldn’t find the source of the issue so could only assume the SVG data was being compressed on export. We decided to only use it to share graphic across the team, in any instance we were working with type we used illustrator.