CSS gradients are faster than SVG backgrounds

Which is really sad, because SVG is awesome. It lets you do what CSS gradients do and much more, in quite a small filesize, as it’s just text too. However, the browser needs to generate a DOM for every SVG graphic, which results in sluggishness.

Here’s my test case

Mouse over the 2 divs. They both use a spotlight effect that’s dynamically updated according to the position of the mouse cursor. One of them does it with an SVG (through a data URI), the other one through a CSS radial gradient.

The test only works in Chrome, Firefox nightlies and perhaps IE10 (haven’t tested in Windows). Why? Because Opera doesn’t support radial gradients yet (however you can see how slow SVG is in it too), and Firefox before the nightlies used to have a bug with gradients in SVG through data URIs. Also, jsFiddle seems not to work in Webkit nightlies for some reason, but I’m too lazy right now to make a self-hosted test case.

Thanks a lot to Christian Krebs (lead developer of Opera Dragonfly) who inspired these tests after a discussion we had today regarding CSS gradient performance.

Edit: According to some commenters, they’re the same speed on Windows and Linux, so it could be an OSX issue. The only way to know for sure is to post more results, so go ahead and post yours!

Also, some commenters say that this is not a fair comparison, because it generates a new SVG every time. I have several arguments to reply to this:

  1. We also generate a new gradient every time, so it is fair.
  2. You can’t manipulate an SVG used for a background, so it’s not an option for backgrounds. JS doesn’t run in it and you don’t have access to its DOM. The only way to do that would be to use an inline SVG embedded in HTML and the element() CSS3 function. However, that’s only supported by Firefox, so not really a pragmatic option.
  • Anonymous

    They both seem equally fast with Chrome 13 on Windows

    • Thanks for the info, nice to hear that!

    • On a MacBook Pro i7 w/ Chrome 13 the CSS wins. Interesting…. 

      • I have a MBA 11″ (i7) running lion and a Windows i7 laptop (1st gen i7) – both have Intel 3000 graphics, and it seems to run perfectly on Chrome 13 and 15 (canary) for all of them. However, on Firefox 6 and Aurora 7 for Lion/Win7, CSS wins – SVG redraws madly.

    • Rafaehlers

      except that every couple of seconds the SVG one blink and the CSS one don’t, it appears that CSS is faster

  • So you replace svg image with new one every time when mouse moved? It’s extremely inefficiently. Svg can handle mouse move in single image.

    • Not in backgrounds. JS doesn’t run in SVGs when they’re used as background images.

  • Michael Butler

    Running Ubuntu 10.10 Athlon II X2 quad core with a gaming video card, Chrome 13. I’m having a very hard time distinguishing between then two sides.  In fact, the left side (SVG) seems better in two ways. 1.) the color blending is completely seamless, whereas I see “bands” with the CSS gradient. 2) it seems faster but might be an optical illusion

    • Interesting. So Chrome’s SVG parsing is apparently much slower on OSX (or CSS gradients are faster there).

  • I had a look at Windows Chrome Dev Tool’s timeline and did a measurement: The gradients require a recalculation of style, which takes 0 ms + a repaint which takes 6 ms. Whereas the chosen SVG-setup mostly (but not always) consists of: Send Request (data uri): 1-3 ms, recalculation of style 0 ms and interestingly TWO repaints ~ 3 ms each. Should you manage to also just move the background-position inside the SVG then I suppose SVG would win. BTW: I can see the banding here, too. I think they are part of a strategy for gaining drawing performance. They are even harsher if not unbearable on mobile WebKits!

  • /edit removed double post (usability failure of my brain)

  • Christoph Zillgens

    Can’t spot any difference here. I’m on  Chrome 13, Mac.

  • Jesper Ek

    I can confirm that they both seem equally fast (chrome 13, windows). Interesting that it would be slower on osx.

    I updated your example to use inline svg instead of data-uri, this should tell if it’s the svg parsing or rendering causing the slowdown: http://jsfiddle.net/8hQEy/7/embedded/result%2Ccss%2Cjs/

    • With the inline SVG, it’s very smooth, just as much as the CSS gradient (and looks better). However, inline SVGs can’t be used for backgrounds (at least until the element() function gets wider support). 🙁

    • Sulfide Smolder

      I also find them equally fast on windows(chrome), i will try on my MBP later when i have some time

  • nice one helped me a bit.

  • Pingback: CSS gradients are faster than SVG backgrounds | Lea Verou | rockledge()

  • I know data URI’s with images aren’t synchronous and still take an tiny bit to load (triggering load events and things), so I would assume this is the case here (which is probably why I sporadically see a flash of grey when the image data isn’t fully processed). I remade your test (validated the SVG, removed extraneous whitespace, then re-encoded) and got the same result.

  • Strange, but will give it a shot and try it out…

  • In Firefox 6 the left one seems to “flash” when mouse moves fast, the right one seems fine.

  • lossendae

    I’m on windows 7 with a relatively slow PC (AMD X2 4400) and i concur, CSS gradients are much faster than SVG.

  • Anthony

    On a MBP mid2009 (core 2 duo) with 4g ram and Chrome 13 there’s absolutely no difference between SGV and CSS3. On Firefox 6, though, CSS3 runs smooth, while SVG flashes madly between redraws.

  • FF6 on Debian: CSS3 wins clearly.

    Of course, creating a DOM for SVG is a huge performance hindrance. But (without wanting to blame anyone) SVG is a long-term step-child in browsers. If someone wants to improve performance in a browser, they look first at the CSS implementation.

    My hope is, that this situation will enhance a bit more to SVG’s favor, when finally web developers realize, that SVG has arrived in today’s browsers. You can see at current Javascript engines, where no-one had expected these speed enhancements 6 or 7 years ago, what can be possible, if enough momentum is gained.

    • Pax

      they should just ditch svg as a standalone spec, and add all its features to css, then define the svg elements line/rect/path/circle etc.. in css..
      the same goes for all the varius html & form tags,  if just all of it was defined in css, the specs themself would just be a css file ex: svg.css, html5.css, etc… K.I.S.S.

  • Chrome 14 on Windows 7: CSS3 clearly wins.  I can see tracing lines in the SVG version…

  • jchadel

    Works with Safari (5) also.

  • Gonçalo Morais

    The SVG implementation flashes a little in GChrome 15 dev, contrary to the smoothness of the CSS implementation.

  • Pingback: CSS gradients are faster than SVG backgrounds | THE ENGINE™()

  • Vel

    I agree…. !

  • Pingback: Performance Calendar » Beyond Bandwidth: UI Performance()

  • Pingback: Beyond Bandwidth: UI Performance | 13fqcs()

  • I know this is an old discussion, but it related to something I’m working on. For what it’s worth, SVG and CSS are now indiscernible on Chrome 25 beta on OSX Mountain Lion.

  • I have made your test more efficient and not dependent on the JS but solely on the CSS now.

    The SVG which must be re-drawn will be slower on some browsers but in chrome it does seem fine.

    Interestingly enough, the SVG exhibits the same behavior on all browsers, but the radial gradient displays differently on various browsers, safari and chrome for example.

    I believe for standards reasons SVG is better as you only need one line of code for all browsers IE9+ to have identical display. Even with the CSS implementation browsers render/display differently.


  • designerJordan

    So I’m a little late in commenting on this, but I was looking into CSS and SVG performance in mobile browsers tonight, and thought I’d chime in that the SVG actually seems a bit faster than the CSS on an iPad 2 running iOS 7.0.4 (AppleWebKit/537.51.1).

    Obviously, you can’t mouseover, but the gradients will both update on tap. The SVG will occasionally experience a slight delay (~200ms maybe) and very occasional flicker before updating, but will redraw almost instantly every time. The CSS seems to have roughly the same slight delay more often, and seems to hiccup ever so slightly in its drawing (just enough that you notice that it is drawing) about every third time or so.

    Anyway, thank you for another grand article and example. Informative, and inspiring me to go experiment some more as always.

  • Pingback: A Compendium of SVG Information | Lunarium Design()

  • Pingback: A Compendium of SVG Information | Vips()

  • Pingback: Making Gradients Easier with LESS Mixins « site design()

  • Pingback: Making Gradients Easier with LESS Mixins - Innovative Studio()

  • Pingback: Making Gradients Easier with LESS Mixins | MotionBump Reader()

  • Pingback: Making Gradients Easier with LESS Mixins | The Web Geek()

  • Pingback: Making Gradients Easier with LESS Mixins | Web Technologies()

  • Pingback: Making Gradients Easier with LESS Mixins | TECH-NEWS()

  • Pingback: Making Gradients Easier with LESS Mixins | Alpesh Kumar()

  • Pingback: m88 thailan()

  • Pingback: Daftar Agen Bola Terpercaya()

  • Pingback: Term Life Insurance()

  • Pingback: ankara escort()

  • Pingback: Scottsdale AZ transportation service()

  • Pingback: uk steroid supply()