Building an interactive diagram viewer isn’t just “draw some boxes and lines.” In real life you’ve got thousands of shapes, labels everywhere, selection handles, arrows, hover states, drag interactions, pan/zoom, maybe a minimap, plus hit-testing that needs to feel instant. Sometimes you also have auto-routing that wants to run right when the user drops a node. So when folks ask “SVG or Canvas or WebGL?”, what they’re really asking is: who owns the scene graph and the interaction model: you or the browser, – and what kind of workload are you optimizing for? Let’s break it down, nice and practical.
1. The mental model: what a diagram viewer is actually doing
Most diagram viewers have three layers whether you call them that or not:
- Scene graph: your nodes/edges/labels, geometry, styles, z-order.
- Interaction: hit-testing (click/hover), dragging, selection boxes, snapping, keyboard shortcuts.
- Redraw strategy: how you repaint when the user pans/zooms, drags one thing, or updates a subset of edges.
SVG, Canvas, and WebGL differ mainly in this: SVG gives you a built-in retained-mode scene graph (DOM), while Canvas and WebGL are immediate-mode and you manage the data + picking yourself.
2. SVG: the “it just works” option … until it doesn’t
When SVG is the right call
- Small to medium diagrams (think: hundreds to a few thousand DOM elements, – depends on browser and styling).
- Text-heavy diagrams where labels matter and you want decent typography without building a text engine.
- You want simple events: click/hover handlers attached to elements, easy accessibility hooks, CSS theming.
- You want fast iteration: it’s a great way to ship an MVP.
- You want clean exports: SVG for lossless scaling and easy post-processing, with raster formats available when you need flat images. SVG is an image format itself, with broad native support across all platforms.
Where SVG usually bottlenecks
- DOM size: every node/edge/label/handle is a DOM element. Too many and the browser starts paying for it in layout/paint/compositing.
- Frequent attribute updates: if you’re updating transform, path d, x/y, classes, styles every frame, you’ll feel it.
- Expensive visuals: filters (blur/shadow), lots of strokes, dash patterns on thousands of paths can get rough.
- Text churn: measuring and re-rendering lots of text on zoom/drag adds up.
Practical SVG tips
- Pan/zoom on one parent , not on every element.
- Avoid “always-on” UI chrome (handles/guides) for every node. Render that only for selection/hover.
- Keep heavy filters rare. Use them surgically.
- Cache text measurements and don’t re-measure every tick.
SVG can feel buttery for the right scale. Past a point, the DOM becomes your tax bill.
3. Canvas 2D: fast drawing, but you own the engine
Canvas is immediate-mode: you redraw what you want each frame. It can be very fast for big scenes, but you’re responsible for the stuff SVG gives you for free.
When Canvas is the right call
- You’re hitting SVG/DOM limits and pan/zoom/drag needs to stay smooth.
- You’re fine implementing picking (hit-testing), selection, and a scene structure yourself.
- You want predictable performance: fewer DOM nodes, more “just pixels.”
Common Canvas bottlenecks
- Full-scene redraw: naive implementations repaint everything every frame. Sometimes that’s okay; sometimes it’s your biggest cost.
- Text: often the first thing to hurt. measureText, lots of labels, and zooming text are expensive.
- Complex paths: thousands of polylines, arrowheads, and strokes can get heavy if you rebuild them constantly.
- Hit-testing: doing a linear scan of every object on every mousemove will absolutely cook your CPU.
Practical Canvas tips
- Use layers: one canvas for the “base scene,” one for interactions (selection box, guides, hover glow).
- Add a spatial index: grid/quadtree/R-tree so you only consider nearby objects for hit-testing and visibility.
- Cache geometry: precompute Path2D where it helps, cache arrowheads/icons.
- Consider OffscreenCanvas/Workers when feasible for heavy redraw or routing work.
Canvas is usually the best “grown-up step” when SVG is struggling. Just know you’re signing up to build more infrastructure.
4. WebGL: the throughput king (with a big engineering price tag)
WebGL shines when you have a lot of primitives and need to push them efficiently on the GPU.
When WebGL is the right call
- Very large scenes: tens/hundreds of thousands of primitives.
- You need GPU-friendly effects and smooth zooming/panning at scale.
- You’re willing to build a rendering pipeline (batching, buffers, shaders).
Common WebGL bottlenecks
- CPU → GPU uploads: if you rebuild and upload massive buffers every frame, you lose the whole point.
- Too many draw calls/state changes: lack of batching/instancing kills performance.
- Text: you’ll likely need SDF (Signed Distance Field) fonts, glyph atlases, or a hybrid approach.
- Picking: you’ll implement CPU indexing, or color picking, or both.
Practical WebGL tips
- Batch and instance aggressively.
- Keep buffers stable and update only what changed.
- Go hybrid: WebGL for geometry, DOM/SVG/HTML overlay for editable text and UI controls is a very common “best of both worlds” move.
WebGL pays off when you’re truly operating at scale. For many viewers, it’s overkill unless you know your targets.
5. Choosing quickly: some solid rules of thumb
- Shipping fast + lots of labels: start with SVG, maybe with a plan to hybridize later.
- You need consistent 60 FPS on moderately large scenes: Canvas 2D (with indexing + layers).
- You’re aiming at huge graphs or GPU-level visuals: WebGL, often hybridized for text/UI.
And yeah, hybrids are normal:
- Canvas/WebGL for the scene + HTML/SVG for labels and UI
- SVG for editing overlays + Canvas for the heavy background layer
6. Where diagram viewers actually bottleneck (the usual suspects)
In practice, it’s rarely “drawing one line” that hurts. It’s stuff like:
- Hit-testing on mousemove without a spatial index
- Text layout/measurement and label placement churn
- Mass style effects (shadows, blurs, opacity layers)
- Huge DOM updates (SVG) during drag/zoom
- Heavy computations on the main thread (routing/layout) without worker/batching
- GC pressure from allocating tons of temporary objects per frame
If your viewer “feels laggy,” one of these is usually the culprit.
7. How to measure (so you’re not arguing vibes)
7.1 Define workloads
Pick 3-5 scenarios and fix the scale (N nodes, M edges, labels per node):
- Pan/zoom around a dense diagram
- Drag a node (update connected edges)
- Box selection over many elements
- Hover highlight (mousemove)
- Auto-route/reroute (if applicable)
7.2 Track the right metrics
- Frame time: average plus p95/p99 (60 FPS target is ~16.6ms per frame)
- Long tasks: anything over 50ms on the main thread
- Input latency: how long between pointer move and visible response
- Memory & GC: heap growth, GC spikes
- CPU vs GPU: what’s dominating in the profile
7.3 Use the right tools
- Chrome DevTools Performance: record pan/zoom/drag and inspect Main + Rendering/Paint.
- performance.mark() / performance.measure() for your own hotspots (routing, redraw, hit-test).
- PerformanceObserver for long tasks.
- Optional: a simple FPS overlay, but treat it as secondary to frame-time percentiles.
7.4 Benchmark fair
- Warm up once (first render is often slower).
- Measure with DevTools closed for “final numbers” (DevTools adds overhead).
- Compare apples-to-apples UX (SVG gives event handling “for free”; Canvas/WebGL need picking logic, include that cost).
8. The bottom line
- SVG is fantastic for shipping quickly and for text-heavy diagrams, until DOM + paint cost catches up.
- Canvas 2D is the practical performance workhorse if you can own hit-testing and scene management.
- WebGL is what you reach for when your scene is big-big and you’re ready to build a rendering pipeline, often paired with DOM for text/UI.
Top comments (0)