PNG animates in 5 ms, while an SVG takes 200 ms?

TG2 · June 21, 2019, 1:40am

Hello! I’m having an unusual problem. On my site, as you hover over menu items, the background changes (a simple show/hide interaction).

Text A: 550 KB SVG image
Text B: 138 KB JPG image
Text C: 254 KB PNG image

When you hover between B & C (JPG ↔ PNG), the background changes within 5 milliseconds, if not faster:

When you hover between image A &B (SVG ↔ JPG), the background doesn’t change for 200 milliseconds.

Looking at the GPU usage, it seems just “showing/hiding” an SVG consumes 40% GPU usage vs “showing/hiding” a PNG/JPG at 10% GPU usage. Is there another interaction I can try to reduce the SVG paint time?

I would’ve assumed, if a background has already been loaded once, how can it be taking so long to draw again? The browser’s already rendered the SVG once…why is it re-computing it every hover event?

EDIT: I’ve tried switching to opacity (0% vs 100%) on the interactions, but the same issue: ~over 200 ms on the SVG vs instant on the PNG

EDIT 2: I thought maybe 0% opacity was removing the SVG (thus requiring a re-draw), so I thought a 1% to 100% opacity would work better. Nope: still is a 200 ms operation!

EDIT 3: Adding easing/transition time does not help. Because the SVG hasn’t even rendered, the transition (I tried 200ms and 500ms) don’t do much. The GPU is still drawing, so the background just pops out, instead of smoothly transitioning.

From my research, it turns out Webflow Interactions are wholly JavaScript-based, which seems to be a big no-no for animating larger SVGs. The recommendations are for CSS transitions, which are much lighter, but Webflow doesn’t make CSS transitions easy! Anyone know how to use CSS transitions to make a parent element be the trigger for a child element (it won’t work in the current layout since the text is arranged as list, which can’t nest anything anyways)…

Here is my site Read-Only: LINK
(Here is my live site)

webdev · June 21, 2019, 8:01pm

FYI: Here is the waterfall for just the SVG asset loaded by itself directly. Each dot is a separate path. It is not a browser friendly asset.

TG2 · June 22, 2019, 3:11am

Yes, exactly! Since it’s not ideal, allowing its first render to be cached for all other hover events is just the thing I’m looking for.

Have you any ideas there? Why is the render being thrown away, even when it’s left at 1% opacity?

The bandwidth savings are substantial: SVG on this one single images allows for a nearly ~40% smaller total website size on mobile and ~10% smaller on desktop.

For what it’s worth, I reduced the SVG file size from 474 KB (51 KB gzipped) down to 391 KB (59 KB gzipped)–but, since the path count is almost identical, it’s not done much for rendering performance.

It seems like the only way forward is to prevent the render from being thrown away…

webdev · June 22, 2019, 3:44am

You might want to post that over to the chromium browser team. They have bigger fish to fry right now. Sorry, but I just don’t have the time for debugging svg rendering issues across platforms and OS’s. Should be a good project for a CS student.

Chasing percentages can be a waste of time when the load is so small. You are under 1mb on desktop. Lighthouse is throwing a 100 performance score on desktop. As you slog more stuff at the browser it all does matter but Webflow hosting is blazing fast so there are practical considerations to take into account (dev time). You normally get a much bigger bang optimizing user experience via good UI.

Concerned? Test real rendering with png versus svg, throttled and not. Look the visual difference between. Then make a decision on what will be best for users. Good luck with your project.

TG2 · June 22, 2019, 4:05am

No worries, mate. Thank you for giving it a go. I didn’t mean to put undue expectations on your grateful efforts!

There are many quicker alternatives we have (i.e., PNG for desktop w/ hover & SVG for mobile w/o hover), but I’m new to Webflow, so I wanted to make sure I’d not missed anything obvious (like CSS transitions).

//

About Chromium: I hadn’t realized, but the transition is lightning quick on Firefox, Edge classic, and IE even. Alas, we’re all under Google’s thumb sometimes.

Thank you. We appreciate the luck! And, yes: the UI deserves more time, likely, than this!

//

Still, for others optimizing their SVGs, here are the top resources we’ve found (brings down an 800 KB SVG with thousands of paths down to about 391 KB!)

SVGito will search your SVG for repeated paths (i.e., same color, size, etc.) and replace them with <use> elements.
Vecta.io’s Nano is some powerful SVG compression (though it doesn’t always help with gzipped sizes).
Of course, SVGOMG: a brilliantly easy GUI for a powerful library.
And some great tests on SVG “resolution” (read: artboard) vs precision optimization, this read on CSS-Tricks was excellent.

TG2 · June 25, 2019, 6:45pm

We discovered the problem after some SVG sleuths on Stackoverflow took a gander.

Adobe Illustrator was coloring the circles with SVG patterns instead of SVG fills—even though each circle was a single color! Replacing SVG <pattern> with SVG <fill> has given a 5x to 20x increase in rendering performance (depending on the CPU):

It’s instantaneous and we’ll end our SVG optimization journey for good now.

See the longer SO post here:

webdev · June 25, 2019, 11:27pm

That is good to know. Thanks for posting the update and sharing your resolution.