[thehappypm]

Hard to imagine that pure-HTML SVG is really slower than Canvas which relies on JS..

[Lockal]

It is, it is! SVG is DOM, with event handling on every node, with attempts to apply CSS rules. Canvas for non-interactive charts is just "draw once and forget". It is a sequence of moveTo + lineTo, then you have a bitmap and nothing else. Extremely basic graphics, modern JS engines will handle it in the blink of an eye.

I don't even mention the fact that article suggests to return each SVG sparkline in a separate request.

[thehappypm]

Guess it depends on your definition of performance.

[fuzzy2]

Ah, but Canvas does not rely on JS. You would update it using JS, yes. When you don’t update it, it’s just another image. Browsers are quite good at images.

In the end, I think it’s down to the complexity of the graph and the dimensions (in pixels, because images need memory, too).

[thehappypm]

How do you draw an image on a canvas without JS?

[fuzzy2]

You don’t. My point is: After drawing, the canvas is “inert”. Rendering to the canvas once is probably more or less as expensive as rendering the SVG once. However, the SVG will probably be rendered a lot more than once. The page developer cannot control it either, the browser decides what’s best.

[klysm]

Canvas is faster _because_ it relies on JS. It’s a much dumber and stateful API - the browser has to do much less work.

[TeMPOraL]

Especially if we're talking using "many hundreds or even thousands of them" on a page.