Vijay T - Technical Blog

Introduction

When building web graphics you have two main rendering options: SVG (Scalable Vector Graphics) and Canvas (bitmap‑based drawing). Both have strengths, but the number of visual elements you need to display—and how often they change—determines which technology will give you the smoothest, most performant experience.

Below is a practical guide that walks through:

• Why element count matters
• Real‑world “cut‑off” ranges measured on desktop and mobile browsers
• A decision matrix for choosing SVG, Canvas, or a hybrid approach
• How to benchmark your own limits
• Optimisation tricks for each technology
• Edge‑case considerations and a handy checklist

---

1. Why the “element count” matters

Aspect	SVG	Canvas
DOM representation	Every shape = a DOM node → layout, style, paint, composite per node.	One <canvas> element; drawing happens on a bitmap, no per‑shape DOM.
Repaint cost	Changing an attribute triggers style → layout → paint → composite for that node (and possibly ancestors).	Any change means redrawing the bitmap (whole canvas or a region).
Event handling	Native listeners on each element (click, mouseenter, …).	You must implement hit‑testing manually.
Memory	Grows with each node (styles, bounding boxes, etc.).	Roughly width × height × 4 bytes (RGBA) + any JS data structures you keep.
Scalability	True vectors – crisp at any zoom/DPI.	Bitmap – must be resized or rendered at high DPI to stay sharp.
Accessibility	Directly part of the DOM → searchable, focusable, ARIA‑friendly.	Not accessible by default – requires a parallel HTML description.

Because SVG’s cost is tied to the number of DOM nodes and how often they mutate, its performance ceiling is fundamentally different from Canvas, where the bottleneck is typically the amount of pixel work per frame.

---

2. Empirical “cut‑off” ranges

The numbers below come from quick benchmarks on:

• Mid‑range laptop – Intel i5‑8250U, Chrome 124, Windows 11
• Low‑end Android phone – Snapdragon 460, Chrome 124

Scenario	Approx. # Elements	FPS / Performance	Observations
Static SVG (simple <rect>/<circle>)	500	60 fps (no repaint)	No issue.
Static SVG (complex <path>)	1 000	60 fps	Path complexity matters more than count.
Hover/CSS transition on SVG	1 500	55 fps	Small slowdown from style recompute.
Animating 2 000 simple SVG objects (via transform)	2 000	30‑40 fps	Layout + paint cost spikes.
Canvas: 2 000 objects, full redraw each frame	2 000	60 fps (GPU‑accelerated)	Smooth even on low‑end device.
Canvas: 10 000 objects, full redraw	10 000	45‑55 fps	Still acceptable for many dashboards.
Large SVG (> 5 000 nodes, e.g., detailed map)	5 000	20‑30 fps	Heavy layout & paint.
Canvas: 20 000 objects (particle system)	20 000	30‑45 fps	May need dirty‑rect optimisation.

Rule of thumb

• ≤ 500 – 1 000 simple SVG nodes → safe for static or lightly interactive graphics.
• > 1 000 dynamic SVG nodes → start seeing slowdown; test thoroughly.
• ≥ 2 000 objects that change every frame → Canvas (or WebGL) is usually faster.

---

3. Decision matrix – When to pick each technology

Use‑case	Recommended tech	Why
Small icons, UI widgets (≤ 50 nodes)	SVG	Perfect crispness, easy styling, native events.
Data visualisations with < 300 – 500 data points (bars, lines)	SVG	Declarative, easy tooltips, ARIA support.
Heat‑maps, pixel‑art, image manipulation	Canvas	Needs per‑pixel drawing; SVG would be massive.
Real‑time simulation / game with > 1 000 moving entities	Canvas	Redraw per frame; DOM overhead would kill FPS.
Large vector maps with < 1 000 elements, occasional interaction	SVG (or hybrid)	Vector benefits outweigh overhead for moderate size.
Force‑directed graphs with > 2 000 nodes, frequent layout updates	Canvas	Layout recomputation + DOM updates become too costly.
Hybrid dashboards (static legends + fast‑updating chart)	SVG + Canvas (layered)	SVG for UI, Canvas for data surface.
Accessibility‑first visualisations	SVG (or provide HTML fallback)	Native DOM elements are indexable.
High‑DPI/Retina displays	SVG (auto‑scales)	Canvas needs manual scaling.

---

4. How to test your cut‑off

The most reliable way to know when you’ll hit the performance wall is to measure it yourself. Below is a minimal benchmark you can drop into any page:

<!DOCTYPE html>
<html>
<head>
  <style>
    #svg, #canvas { border:1px solid #aaa; margin:1rem; }
  </style>
</head>
<body>
<div>
  <label>Elements: <input id="count" type="range" min="100" max="5000" step="100" value="1000"></label>
  <span id="num"></span>
</div>

<svg id="svg" width="600" height="400"></svg>
<canvas id="canvas" width="600" height="400"></canvas>

<script>
const svg = document.getElementById('svg');
const ctx = document.getElementById('canvas').getContext('2d');
const countEl = document.getElementById('count');
const numSpan = document.getElementById('num');
function randomColor(){return `rgb(${Math.random()*255|0},${Math.random()*255|0},${Math.random()*255|0})`;}

function drawSVG(n){
  while(svg.lastChild) svg.removeChild(svg.lastChild);
  const NS = "http://www.w3.org/2000/svg";
  for(let i=0;i<n;i++){
    const c = document.createElementNS(NS,'circle');
    c.setAttribute('cx', Math.random()*600);
    c.setAttribute('cy', Math.random()*400);
    c.setAttribute('r',5);
    c.setAttribute('fill', randomColor());
    svg.appendChild(c);
  }
}
function drawCanvas(n){
  ctx.clearRect(0,0,600,400);
  for(let i=0;i<n;i++){
    ctx.beginPath();
    ctx.arc(Math.random()*600, Math.random()*400, 5, 0, Math.PI*2);
    ctx.fillStyle = randomColor();
    ctx.fill();
  }
}
function bench(fn){
  const t0 = performance.now();
  fn();
  return (performance.now() - t0).toFixed(2);
}
function update(){
  const n = +countEl.value;
  numSpan.textContent = n;
  console.clear();
  console.log(`Elements: ${n}`);
  console.log(`SVG draw: ${bench(()=>drawSVG(n))} ms`);
  console.log(`Canvas draw: ${bench(()=>drawCanvas(n))} ms`);
}
countEl.addEventListener('input', update);
update();
</script>
</body>
</html>

What to look for

1. Initial draw time – shows DOM creation cost (SVG) vs. bitmap fill (Canvas).
2. Subsequent update time – replace the draw functions with a loop that mutates attributes (SVG) or re‑draws each frame (Canvas) to see repaint cost.
3. Memory usage – open DevTools → Performance → Memory to watch how RAM grows.

Run the test on the devices you support (desktop, tablet, phone) and note where the draw time exceeds ~16 ms (≈ 60 fps) or the UI feels “janky”.

---

5. Optimisation tips

SVG

Technique	Effect
<use> + <symbol>	Re‑use a shape definition → far fewer DOM nodes.
<foreignObject> for big text blocks	Offloads heavy text to HTML, shrinking the SVG tree.
will-change: transform / translateZ(0)	Prompts compositor‑layer creation for moving elements, reducing repaint cost.
Simplify d in <path> (SVGO)	Fewer commands → quicker parsing.
Batch DOM updates inside requestAnimationFrame	Avoid layout thrashing.
Virtualisation / clipping	Render only the visible part of a massive SVG (e.g., map tiles).
Consolidate geometry with <mask> / <clipPath>	Cuts down on separate shapes.
Share styles via CSS classes, not inline style attributes	Reduces style‑rule duplication.

Canvas

Technique	Effect
Dirty‑rect (region) redraw	Clear & redraw only the area that changed.
Off‑screen canvas (createImageBitmap)	Pre‑render static background once, then composit fast.
Object pooling	Re‑use JS objects for each entity → fewer GC pauses.
requestAnimationFrame for all animation loops	Syncs with display refresh (60 fps).
High‑DPI handling (canvas.width = cssWidth * devicePixelRatio)	Keeps graphics crisp on Retina screens.
Layered canvases (static background on one, sprites on another)	Reduces work per frame.
Batch drawing (ctx.beginPath() once, then many sub‑paths)	One paint call instead of many.
WebGL (canvas.getContext('webgl')) when you need > 10 k objects or heavy transforms	Full GPU acceleration.

---

6. Hybrid patterns – Getting the best of both worlds

A common production pattern is stacking layers:

<div class="chart">
  <!-- UI, axes, legends – crisp, accessible -->
  <svg class="axes" width="800" height="600"></svg>

  <!-- Fast‑changing data surface -->
  <canvas class="data" width="800" height="600"></canvas>

  <!-- Tiny interactive overlay (tooltips, selections) -->
  <svg class="overlay" width="800" height="600" pointer-events="none"></svg>
</div>

Axes & legends stay as SVG for perfect scaling and accessibility.
Data points (often thousands) are drawn on the canvas for speed.
Hover/highlight elements are a handful of SVG shapes, keeping event handling simple.

Example: A scatter plot with 20 k points – points are drawn on canvas, while the selected point and its label are rendered with a tiny SVG overlay.

---

7. Edge cases & special considerations

Scenario	Gotcha	Recommendation
Printing / PDF export	Canvas becomes rasterized → low DPI if not up‑scaled.	Generate an SVG version for export, or render a high‑resolution canvas (width = cssWidth * 4).
Screen readers	Canvas content is invisible to assistive tech.	Provide an off‑screen ARIA description or a fallback HTML table/graph.
CSS animations on many elements	SVG suffers from layout + paint per element.	Prefer transform (GPU‑accelerated) and add will-change.
Responsive scaling	Canvas needs manual size update on resize.	Listen to resize events and recompute canvas width/height * devicePixelRatio.
Large static background (tiles)	Adding hundreds of <image> tags creates many DOM nodes.	Draw tiles on Canvas, or use a single tiled <svg> definition with <use>.
Complex filters (blur, drop‑shadow)	Each filtered SVG element creates a compositor layer.	Limit filter usage, or group elements under one <g filter>.
Animations driven by live data (WebSocket)	Frequent updates cause many SVG attribute changes.	Buffer updates and draw them in a single Canvas frame.

---

8. Checklist for your project

1. Count the elements you plan to render (including hidden/virtual ones).
2. Identify interaction density – how many need individual listeners?
3. Determine scalability & accessibility needs (zoom, DPI, screen‑reader).
4. Prototype quickly using the benchmark snippet above with realistic data.
5. Measure FPS and memory on target devices (desktop, tablet, phone).
6. Choose:
   • ≤ 1 000 static/simple nodes → SVG.
   • > 1 000 nodes that animate or update frequently → Canvas (or WebGL).
   • Mixed requirements → layered hybrid.
7. Apply relevant optimisations (use <use>, dirty‑rects, object pooling, etc.).
8. Add fallback/ARIA layers for accessibility.
9. Test on low‑end hardware and browsers you support.
10. Document the decision so future maintainers understand the performance trade‑offs.

---

9. Quick code example – Layered scatter plot

<style>
  .chart { position:relative; width:800px; height:600px; }
  canvas, svg { position:absolute; top:0; left:0; }
</style>

<div class="chart">
  <svg id="axes" width="800" height="600"></svg>
  <canvas id="points" width="800" height="600"></canvas>
  <svg id="overlay" width="800" height="600" pointer-events="none"></svg>
</div>

<script>
const canvas = document.getElementById('points');
const ctx = canvas.getContext('2d');
const overlay = document.getElementById('overlay');
const NS = "http://www.w3.org/2000/svg";

// 20 000 random points
const data = Array.from({length:20000}, () => ({
  x: Math.random()*800,
  y: Math.random()*600,
  r: 2 + Math.random()*3,
  c: `hsl(${Math.random()*360},80%,60%)`
}));

function drawCanvas(){
  ctx.clearRect(0,0,canvas.width,canvas.height);
  ctx.beginPath();
  data.forEach(p => {
    ctx.moveTo(p.x, p.y);
    ctx.arc(p.x, p.y, p.r, 0, Math.PI*2);
  });
  ctx.fillStyle = '#444';
  ctx.fill();
}

function drawOverlay(point){
  overlay.innerHTML = '';
  const circ = document.createElementNS(NS,'circle');
  circ.setAttribute('cx', point.x);
  circ.setAttribute('cy', point.y);
  circ.setAttribute('r', 10);
  circ.setAttribute('stroke','orange');
  circ.setAttribute('stroke-width','2');
  circ.setAttribute('fill','none');
  overlay.appendChild(circ);

  const txt = document.createElementNS(NS,'text');
  txt.setAttribute('x', point.x + 12);
  txt.setAttribute('y', point.y - 12);
  txt.textContent = `(${point.x.toFixed(0)},${point.y.toFixed(0)})`;
  txt.setAttribute('fill','white');
  txt.setAttribute('font-size','12');
  overlay.appendChild(txt);
}

// Simple hover hit‑test (naïve O(N) – replace with a spatial index for production)
canvas.addEventListener('mousemove', e => {
  const rect = canvas.getBoundingClientRect();
  const mx = e.clientX - rect.left;
  const my = e.clientY - rect.top;
  const hit = data.find(p => Math.hypot(p.x-mx, p.y-my) <= p.r + 2);
  if (hit) drawOverlay(hit);
  else overlay.innerHTML = '';
});

drawCanvas();
</script>

Result:

• 20 k points rendered at 60 fps on Canvas.
• Hover highlight uses only a couple of SVG elements – negligible overhead.

---

10. Bottom line

Situation	Approx. cut‑off	Primary tech	Typical add‑on
Static diagrams, ≤ 1 000 elements	≤ 1 000	SVG	–
Light interaction, ≤ 500 elements	≤ 500	SVG	–
Frequent animation with > 1 000 objects	> 1 000	Canvas (2D)	Optional SVG overlay
Very high‑density visualisation (> 10 000)	> 10 000	Canvas (or WebGL)	SVG for UI
Must support screen‑readers & printing	Any	SVG (or provide fallback)	Canvas for heavy drawing, plus ARIA description
Need crisp scaling on any DPI	Any	SVG	Canvas → high‑DPI scaling if used

Takeaway: Use SVG for modest‑size, declarative, accessible graphics; switch to Canvas when you cross the “few‑hundred‑to‑thousand‑dynamic‑elements” threshold, or when you need pixel‑level control and high‑frame‑rate animation. A layered hybrid approach often gives you the best of both worlds.

Happy rendering! 🚀