A big downside of using SVG is this bug in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=935056. The minimum font size is also applied to text inside SVG (even if it is finally scaled up by a transformation).
I have found the mergePaths feature of svgo somewhat unreliable: it may chop off arrow heads.
On iOS using Safari’s “Reader View”, only the Inkscape non-optimized SVG shows up. The other two don’t for whatever reason. Outside of reader view it all works fine though. Any idea why this could be?
The graph at the top of the post shows displays correctly in reader mode if that helps at all.
Same on macOS. Inspect element on the reader view shows the first <svg> tag inside the <center> tag like in the normal page source, but the two subsequent examples have empty <center> tags. So it doesn’t appear to be a rendering problem, the ` tags are actually missing in the reader view.
For small diagram-like SVGs there is also the final trick of inlining the resulting SVG directly into the page, removing the opportunity for any network delay to creep in at all, and allowing all those small files to share a compression dictionary.
I found the most effective approach was in the form of a url-encoded (not base64) data: URL, as it meant toggling inlining only involved changing <img src=> attributes, which could be done centrally from a Django template tag, with no other changes in page structure. By using the less efficient URL encoding rather than base64, redundant substrings within each SVG are byte aligned so gzip over the whole page is much more effective, even though the decompressed page is usually much larger
HTTP/2 push is great, but it requires the alignment of many things stretching across many layers, something like:
a separate file or webapp headers to emit hints to the web server
a web server to understand the hints
all proxies and load balancers to accept and forward them
a proxy to own the client and also persist a list of files that have already been pushed to it
clients to receive and act on them correctly
for example with Firefox talking to Apache2, the browser acts completely differently on page refresh than it does for a new cold connection. No reason to avoid it, but some inline strings on a page are vastly easier to avoid messing up
Milliseconds on a frictionless sphere perhaps, but on typical 3G or transcontinental connections the removal of every DNS lookup, SSL connection setup or even a single roundtrip before the browser knows to fetch a file quickly adds up to multiple seconds. Offering a snappy experience isn’t a nice-to-have
If you don’t want to run SVGO client side there is a webapp called SVGOMG on github that’ll do it for you! C-v to paste and then in the bottom right, click “copy as text”.
A big downside of using SVG is this bug in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=935056. The minimum font size is also applied to text inside SVG (even if it is finally scaled up by a transformation).
I have found the
mergePathsfeature of svgo somewhat unreliable: it may chop off arrow heads.You can convert text to paths on save. It’s not as space-efficient and you lose all the hinting magic, but avoids many font-related issues
On iOS using Safari’s “Reader View”, only the Inkscape non-optimized SVG shows up. The other two don’t for whatever reason. Outside of reader view it all works fine though. Any idea why this could be?
The graph at the top of the post shows displays correctly in reader mode if that helps at all.
Same on macOS. Inspect element on the reader view shows the first
<svg>tag inside the<center>tag like in the normal page source, but the two subsequent examples have empty<center>tags. So it doesn’t appear to be a rendering problem, the ` tags are actually missing in the reader view.For small diagram-like SVGs there is also the final trick of inlining the resulting SVG directly into the page, removing the opportunity for any network delay to creep in at all, and allowing all those small files to share a compression dictionary.
I found the most effective approach was in the form of a url-encoded (not base64) data: URL, as it meant toggling inlining only involved changing
<img src=>attributes, which could be done centrally from a Django template tag, with no other changes in page structure. By using the less efficient URL encoding rather than base64, redundant substrings within each SVG are byte aligned so gzip over the whole page is much more effective, even though the decompressed page is usually much largerHttp2 server push and multiplexing help with latency even when it’s a separate request
HTTP/2 push is great, but it requires the alignment of many things stretching across many layers, something like:
for example with Firefox talking to Apache2, the browser acts completely differently on page refresh than it does for a new cold connection. No reason to avoid it, but some inline strings on a page are vastly easier to avoid messing up
crazy the things we do to get our page loading just a couple hundred milliseconds faster
Milliseconds on a frictionless sphere perhaps, but on typical 3G or transcontinental connections the removal of every DNS lookup, SSL connection setup or even a single roundtrip before the browser knows to fetch a file quickly adds up to multiple seconds. Offering a snappy experience isn’t a nice-to-have
If you don’t want to run SVGO client side there is a webapp called SVGOMG on github that’ll do it for you! C-v to paste and then in the bottom right, click “copy as text”.
There’s a fantastic svgcleaner project: https://github.com/RazrFalcon/svgcleaner
It’s orders of magnitude faster than svgo, and it’s much more careful not to break any files.
last time I checked none of the svg optimizer tools produced really good results. I ended up using svgcleaner + svgo to get the best outcome.
This is all fine and dandy on the circle example, but with my “real-world” SVG’s that contain with several shapes I only get a reduction of 2 - 6.5%.