The article is geared towards front end engineers, clarifying how and when to compress images and which formats to choose. It stresses the importance of the image context more than the technicalities of the image. This context can also lead to the decision to choose other types of image, such as choosing a simplified drawing instead of a photo when the image context is icon-like.

Use svgs*

* when you can

I just went through a project where we deliberately converted all SVGs to PNGs (using an image CDN where we could request different transformed resolutions) and it resulted in MUCH better performance, both in tools like PageSpeed and in perceived performance, for 2 major reasons:

1. The PNGs tended to be MUCH smaller than the SVGs, and I think you'll find this likely whenever you have even a very minorly complicated graphic (the article points this out).

2. There is an issue on Android devices where scrolling was absolutely awful when there were lots of large SVGs on the page. This completely went away when we switched to PNGs.

I think the best recommendation is to store the initial image either as an SVG or very high resolution raster image, but then use an on-the-fly transforming CDN so you can experiment and easily get the right image (size and format) where necessary.

SVG is an incredibly inefficient way to represent a line drawing,with all the coordinates written out as text, and not as deltas from the previous one. Flash's internal representation is much tighter, but not cool any more.

SVG can do relative coordinates fine: "m 10 10" (m dx dy) rather than "M 10 10" (M x y). But yes, they're text until you compress them.

Yes, but unless you round the floating point digits, you're going to use about as much bytes.

The parent is correct. At some point we gained a fear of binary formats, but binary formats are still the only way to transfer data efficiently.

Yes, flash had other problems. No, this doesn't make their point false.

Is that really true with gzipping?

Browsers still need to unzip and parse the SVG, and store the DOM representation of it.

Any examples you mind sharing?

One case where you probably can't is for image uploads. You might think it would be nice to allow a user to upload a svg for their avatar or something.

But SVG can embed javascript which can lead to XSS: https://hackerone.com/reports/148853

That's certainly something to be considered with user uploaded svg images. However it's reasonably straightforward to parse an svg and remove any script elements.

You can safely use XSLT to subset SVG, and (for example) limit complexity. Scripts in SVGs do not load in img tags either.

No wonder scrolling is bad for us! Without line-tracking, scrolling kinda culls our attention span, patience and retention—all in one stroke. ;-)

I found the article very nicely written and do not think there was filler in there.