Browser Support When dealing with SVGs, there's sort of two tiers of browser support you have to worry about. Firstly, there's whether or not a browser supports a feature at all. IE11, for instance, doesn't support CSS transforms of SVG elements (that is, elements inside an

<svg>

). They just don't do anything. Secondly, there's variation in how well different browsers handle different techniques. All the browsers have strengths and weaknesses when it comes to SVG, so a lot of my knowledge is in knowing the subset of things that aren't just fast, but are uniformly fast across browsers. For instance — Safari is generally slow-ish, but very consistently so. Chrome is super fast if you do what it likes, but if you stray off the happy path it's super slow, and it eats battery. Chrome also tends to have poorer visual fidelity. Firefox has (had?) issues with nasty color banding in gradients, and also eats battery. Edge has (had?) issues with certain properties failing to animate in certain circumstances, requiring targeted workarounds. Transforms In most browsers, transforming things inside of an SVG causes painting, which is slower than just pure GPU compositing. This will vary a bit depending on how you do the transform. You can use CSS transforms, which don't generally cause painting, but they don't work in IE11 and might not work 100% in Edge. So everything I do is with the

transform

attribute, which causes painting but works everywhere. I have a hunch that it'd be way faster to blow apart a big

<svg>

element into many smaller

<svg>

elements, and animate the

<svg>

itself using CSS transforms rather than animating the contents of the SVG. That should have fantastic browser support, and stay entirely on the GPU. Haven't tried this yet. Animation You generally can't use CSS animations, or the new Animations API, or SMIL, due to terrible browser support. JS-based animation is pretty much the only game in town, currently. Painting Since SVG transforms seem to cause a lot more painting than CSS transforms, it's worth knowing what things are slow to paint. Gradients are fairly slow. Transparencies are terribly slow. The size of the gradient / transparent element affects your cost, so a screen-filling transparent gradient is a worst case. SVG filters are bananas slow, and should be avoided entirely IMHO. Caching There's a perf hit every time you touch any DOM properties, and in a non-trivial animation (or in an animation framework) it's not always easy to know for sure that you won't be touching things redundantly. A simple but effective fix is just to take advantage of JS being a dynamic language, and stick extra properties on your DOM objects that store the values of any DOM properties you're animating, and only update the real properties if they're different than what you've stored. It's also faster to remove nodes from the DOM instead of making things invisible using display or opacity. Etc I've been doing SVG animation tooling for about 5 years now, so in some ways my knowledge is about 5 years out of date, since that's when I did most of my hard learning. Things might have changed. If you have specific questions, feel free to let me know. When I look at something like Enso, I see what looks to me like the classic "rewrite it in X" performance win story, where you could have had just as much of a win rewriting it in the original technology given what you've learned about the problem domain. It's a shame (since I'm sure that WebGL rewrite had a hefty cost) but they have their priorities, and I expect excellent interop with 2d art tools isn't one of them (and that's the reason I'm so big on SVG). I keep thinking of more tips to add, but I think I'll leave this as-is. Like anything, the best thing to do to get good front end perf is learn about the way the underlying tech works, run experiments, and measure measure measure!