Updating scrollTop is a pretty slow way to scroll on some browsers. Have you tried animating `transform`? That gets you hardware acceleration on webkit at least
Animating transform doesn't affect page scroll, which is a more useful use case (since users need to scroll a page) than being able to use a translate transformation.
Of note, a translate transformation still isn't perfect. It seems to chug and then turn into a smooth animation.
Eh, updating page at end/cancel easy enough. I use this approach to animate a page scroll:
1. Animate #transform using jquery's animate (which doesn't work out of the box unfortunately, you have to use a custom #step fn)
2. Install "capture" event handlers on document.body that will cancel the animation, reset scrollTop to the state of the transform, then reset the #translate to 0 on #scroll or #touch (so we don't "fight" the user scrolling)
3. .. animation runs, calls my "complete" callback which uninstalls the event handlers, sets #translate back to 0, and updates scrollTop. Unfortunately there is a noticeable "glitch" here if the user tries to immediately further interact with the page.
#2 is optional (OP's implementation didn't handle canceling anyways). I'm sure there's a jquery plugin to do this and degrade to scrollTop on non-webkit browsers.
Additionally, jQuery is not known for its performance, especially regarding animations.
For me, on Chrome Canary, the animation "chugs" every 20-30 frames (from 60 fps to a frame that takes 200ms). It's almost entirely in rendering, and it's immediately following a jQuery callback. It only happens when scrolling down. I'd like to see this done with a very simplistic requestAnimationFrame tweener to compare the same type of animation against something that is doing nothing else but computing a new scrollTop and setting it. I have a strong feeling, in Chrome at least, that the problem here is jQuery, not SVG perf.
Additionally, for other browsers, I'd like to see this tested with icon fonts.
I can't believe nobody else mentioned this.