perf(image): reduce svgo precision for tracedSVGs

[axe312ger]

While comparing initial html rendering results with different techniques, I found out traced SVG sizes can be reduced by the factor of ~2,2. It even increases the compression rate.

I tried several additional svgo settings but the only one with an higher reduction as 0.01% was to reduce the precision from 1 to 0

Example

My example data is based on gatsbygram which contains 12 traced svg previews.

Method	Real Size	Gzip Size	Compression Ratio	Size increase gz
original	36.7 kB (36787B)	10.1kB (10197B)	360,7%	100%
traced svg	313.0kB (313018B)	110.0kB (110078B)	284,3%	1079,5% 😱
traced svg pr	150.8kB (150898B)	49.6kB (49639B)	303,9%	486,80% 💪

Download index.html files of all tests

Compare to other initial rendering image preview techniques

Original - 313.0kB

Optimized - 150.8kB

[KyleAMathews]

Looks almost identical! Really nice catch!

@fk look good?

[gatsbybot]

Deploy preview for gatsbygram ready!

Built with commit a320132

https://deploy-preview-4270--gatsbygram.netlify.com

[fk]

Lookin' veeeerrrrrry good!
Thank you @axe312ger! 🙏

/cc @EmilTholin I think you might be interested in that change to floatPrecision too—AFAIR I shamelessly copied the SVGO settings from your loader last year…ah yes: https://github.com/EmilTholin/image-trace-loader/blob/9ee9e5cb6caab17e5ff68a0be5291438b9e5e9dc/lib/index.js#L24

[fk]

👍 🎉

[EmilTholin]

Holy smokes. That's a very nice find! Thank you @axe312ger, and thanks for the ping @fk!

Before: 12657B, 6046B, 15526B, 22795B

After: 5502B, 2993B, 6532B, 8171B

This might also be a great PR to sqip, which you used in your other PR @axe312ger, if I'm not mistaken?

[axe312ger]

Wow cool! Great previews :)

Regarding the sqip svgo tweak:

The effect is way less since it does not use paths and, with a quick test via svgo website, it actually has visible impact on the colors (🤷‍♂️ ) and slightly the positions of shapes. But I could imagine the sqip mode is impacting this a lot.

[axe312ger]

Chrome audit results

This was kind of single run, don't take the numbers to serious. Pages were served locally via https://github.com/zeit/serve which I assume is optimized to imitate a production environment.

I wonder why gatsby-image seems to be unable to render all images at once. Is there any concurrency included?

old gatsbygram with <img src srcSet sizes/> tags

new gatsbygram with gatsby-image and tracedSVG

[axe312ger]

It actually looks like gatsby-image prevents the images from being loaded in paralell. The fonts and even the js is loaded before the images even start to load.

old gatsbygram with <img src srcSet sizes/> tags

new gatsbygram with gatsby-image and tracedSVG

[axe312ger]

Performance tab with slow 3g shows similar. While traved svg version offers way better first appearance, it takes twice as much time to load the actual images 😱

[KyleAMathews]

gatsby-image lazy loads images so images won't load until JS is in which does slow down the initial load of images. We actually should add a prop that lets you disable lazy loading of certain images during SSR (but would lazy load still in the client) for exactly this reason — if an image loading is the critical path for a page, you could simply specify that image as not-lazy.

One thing I worry about with gatsby-image is people sometimes think it's a drop-in replacement for the regular img tag. While it often is, it does make tradeoffs you might not want e.g. here.

[KyleAMathews]

Thanks for finding this and PRing it in!