The canvas performance toolbox
Canvas is the web's most widely supported standard for 2D immediate mode graphics, and it powers everything from games to data visualizations. But as projects grow in scope, performance bottlenecks quickly surface. The good news is that many of the most impactful optimizations are simple to apply once you understand where the costs actually live.
The techniques below are drawn from practical experience and verified with JSPerf benchmarks. Browser implementations change, and some optimizations will lose relevance as GPU acceleration becomes more common. Where that's the case, it's noted explicitly.
Render once, draw many times with off-screen canvases
If you're redrawing the same complex primitives every frame, you're paying for that complexity over and over. Pre-rendering to an off-screen canvas lets you do the expensive work once, then blit the result onto the visible canvas each frame.
Rather than this, which redraws every detail of Mario on every frame:
// canvas, context are defined
function render() {
drawMario(context);
requestAnimationFrame(render);
}
…you draw Mario to a hidden canvas once and copy it into view each frame:
var m_canvas = document.createElement('canvas');
m_canvas.width = 64;
m_canvas.height = 64;
var m_context = m_canvas.getContext('2d');
drawMario(m_context);
function render() {
context.drawImage(m_canvas, 0, 0);
requestAnimationFrame(render);
}
This pays off most when the rendering operation itself is costly—text rendering is a classic example. But there's a catch: the off-screen canvas needs to be sized tightly around its contents. A loose "pre-rendered loose" canvas that's much larger than the image defeats the benefit, because copying a large canvas onto another is expensive. Use a snug temporary canvas instead:
can2.width = 100;
can2.height = 40;
…not a larger one like this:
can3.width = 300;
can3.height = 100;
Batch your draw calls
Each drawing operation is expensive, so it's more efficient to feed the drawing state machine a long command list and let it flush everything to the video buffer in one go. For example, drawing separate line segments means multiple draw calls and path state changes:
for (var i = 0; i < points.length - 1; i++) {
var p1 = points[i];
var p2 = points[i+1];
context.beginPath();
context.moveTo(p1.x, p1.y);
context.lineTo(p2.x, p2.y);
context.stroke();
}
Building a single polyline path with all the points and drawing it once performs better:
context.beginPath();
for (var i = 0; i < points.length - 1; i++) {
var p1 = points[i];
var p2 = points[i+1];
context.moveTo(p1.x, p1.y);
context.lineTo(p2.x, p2.y);
}
context.stroke();
There's an important exception: if the primitives have small bounding boxes, like horizontal and vertical lines, rendering them separately can actually be faster. Batching is a rule of thumb, not a universal law.
Minimize state machine changes
The canvas API is built on a state machine tracking fill styles, stroke styles, and path points. Manipulating that state machinery has a cost of its own. If you're using multiple fill colors, sorting your drawing by color rather than by position can be a significant win. Instead of interleaving state changes as you draw each stripe of a pinstripe pattern:
for (var i = 0; i < STRIPES; i++) {
context.fillStyle = (i % 2 ? COLOR1 : COLOR2);
context.fillRect(i * GAP, 0, GAP, 480);
}
Group all the odd stripes together, then all the even ones:
context.fillStyle = COLOR1;
for (var i = 0; i < STRIPES/2; i++) {
context.fillRect((i*2) * GAP, 0, GAP, 480);
}
context.fillStyle = COLOR2;
for (var i = 0; i < STRIPES/2; i++) {
context.fillRect((i*2+1) * GAP, 0, GAP, 480);
}
State changes are the bottleneck here; minimizing them speeds up the whole frame.
Clear the difference, not the whole screen
Less drawing is cheaper drawing. If only part of your scene changes between frames, you don't need to clear and redraw everything. Keeping track of the bounding box of what you drew and only clearing that region gives you a "redraw regions" style optimization. Instead of clearing the full canvas before redrawing:
context.fillRect(0, 0, canvas.width, canvas.height);
Save the previously drawn bounds and clear only that area:
context.fillRect(last.x, last.y, last.width, last.height);
This approach carries over to pixel-based contexts too, as shown in JavaScript-based emulator implementations.
Layer canvases for complex scenes
Large canvases are expensive to draw and clear. You can sidestep that by stacking multiple transparent canvases with CSS positioning, letting the compositor handle blending the layers. Setting up two absolutely positioned canvases, a background and a foreground, lets you redraw the foreground without ever touching the background:
<canvas id="bg" width="640" height="480" style="position: absolute; z-index: 0">
</canvas>
<canvas id="fg" width="640" height="480" style="position: absolute; z-index: 1">
</canvas>
You can push this further by exploiting visual perception: a background that changes slowly doesn't need to render at 60 FPS. Update it every Nth frame while the foreground updates continuously. The same structure generalizes beyond two layers if it fits your application.
Skip shadowBlur and other expensive effects
Blur effects via shadowBlur are straightforward to use but among the most computationally expensive operations canvas supports:
context.shadowOffsetX = 5;
context.shadowOffsetY = 5;
context.shadowBlur = 4;
context.shadowColor = 'rgba(255, 0, 0, 0.5)';
context.fillRect(20, 20, 150, 100);
In a scene where performance matters, shadow effects are a luxury you'll likely want to avoid.
Clearing the canvas: two ways, two costs
Immediate mode graphics means every frame you must redraw your scene, which makes clearing an essential and frequent operation. If you have to clear the whole canvas, there are two primary options: context.clearRect(0, 0, width, height) or the canvas width reset technique, canvas.width = canvas.width. Generally clearRect is faster, but under some implementations—like certain versions of Chrome—the width reset trick can be significantly quicker. This behavior is highly implementation-specific and likely to change, so re-test in your target browsers.
Use integer coordinates for sprites
Canvas always enables sub-pixel rendering and anti-aliases non-integer coordinates. If that extra smoothing isn't what you're after, it's pure overhead. For sprites that look better pixel-aligned anyway, rounding coordinates can dramatically improve performance. Use Math.round or Math.floor, or go even faster with a bitwise truncation hack:
// With a bitwise or.
rounded = (0.5 + somenum) | 0;
// A double bitwise not.
rounded = ~~ (0.5 + somenum);
// Finally, a left bitwise shift.
rounded = (0.5 + somenum) << 0;
Once canvas implementations get GPU accelerated, non-integer coordinates will render cheaply and this optimization won't be needed.
Animate with requestAnimationFrame
Instead of forcing a fixed frame rate with timers, the requestAnimationFrame API politely asks the browser to call your rendering routine when it's ready. The browser targets 60 FPS but makes no guarantee, so you need to track elapsed time yourself:
var x = 100;
var y = 100;
var lastRender = Date.now();
function render() {
var delta = Date.now() - lastRender;
x += delta;
y += delta;
context.fillRect(x, y, W, H);
requestAnimationFrame(render);
}
render();
In return, the browser won't fire the callback when the page is in a background tab, saving cycles and battery. The same API serves WebGL and other rendering contexts, and it's broadly supported in current browsers.
The mobile gap
Mobile canvas remains inconsistent in performance. As of this writing, only certain browsers on iOS have any GPU accelerated canvas, and desktop quality is not a safe expectation on mobile hardware. The JSPerf tests referenced throughout this article run an order of magnitude worse on mobile devices, which sharply limits the kinds of cross-device applications you can realistically support. Profile aggressively on the mobile targets you actually care about.
Avoiding Unnecessary Renders
Implementing a dirty-rectangle scheme is one of the most effective ways to cut down on per-frame work. Instead of clearing and redrawing the entire canvas on every animation frame, track which regions of the screen actually changed and only clear those specific areas before repainting them. This is especially valuable in small, controlled regions, where the performance gain is most pronounced. When used in conjunction with requestAnimationFrame, which aligns updates with the display's refresh cycle, this approach can dramatically reduce wasted GPU and CPU cycles on static scenes.
For case-specific optimization, the Chrome DevTools offers a dedicated canvas profiler. This tool provides a per-call breakdown of drawing operations, allowing you to pinpoint the exact functions—like drawImage or fillRect—that are consuming the most time. This data lets you target your optimization efforts rather than guessing where the bottlenecks are.
Sub-pixel rendering is another common source of hidden jank. When non-integer coordinates are used for drawing, the browser must perform costly anti-aliasing. A simple check using an "early-out" boolean to ensure all sprites are placed on whole pixels can yield significant performance benefits, particularly with large canvases and renders. The visual difference is often negligible, but the speed improvement is measurable.
Mobile-First Rendering
Note: A prior section of this article covered sprite-atlas creation and mirroring in canvas—this section assumes a baseline from that discussion.
On mobile devices, context creation and canvas size are critical, resource-heavy operations. While the webgl context can be vastly faster than the legacy 2d context—in some cases up to 10x or more—it's rarely a drop-in solution. WebGL requires a different pixel pipeline, restricts certain color operations, and can hard-crash the GPU if you exceed texture limits.
A more practical approach for mobile is to keep the canvas as small as possible and use CSS to scale it up to fill the viewport
. This avoids the memory strain of backing a huge canvas. Also, beware of dynamically toggling the display CSS property for backing-store canvases; always use visibility:hidden over display:none, as the latter can trigger a context loss in some mobile browsers.
Always check for the contextLost event and handle it gracefully. It's a standard part of the API and is the only reliable way to catch memory-related resets, which can happen if your app is consuming too much memory or if another tab forces a background tab to shed resources. If you ignore this event, your canvas may turn blank or freeze forever without warning.
Don't Fear Retained-Mode**
While the immediate-mode nature of Canvas gives you full control, there is no shame in hybridizing. The primary 2D API lacks a reliable native method for hit-testing that respects the current transformation matrix, but you can try wrapping every click with a save/restore pair and calling getImageData to read a pixel. If you're working with WebGL, a redraw with color-keyed object IDs serves the same purpose.
For scenarios that don't demand the raw speed of immediate mode, your app might be easier to build with the retained mode of the DOM or Viewport. Find the low-hanging fruit: if there's a rigid widget in a game HUD, consider drawing it with HTML and CSS.
Try overlaying static DOM elements, especially for simple UI elements. Dynamic text layout—when you need rich text or natural wrapping—is inherently slow in canvas. Let the browser handle that. But avoid the reverse: do not append DOM nodes into an animation loop for transient effects. If you're drawing 50 individual coins in a loop to pick up, none of them should be touched by the CSS engine; that will cause a layout thrash.
Dirty rectangles are a very large subject that deserves its own space. This is how I generally think about doing it well: http://jsfiddle.net/9dMwk1/2/ ## Conclusion Never import the entirety of your project's codebase into one optimization pass. The best trick is increasing scope incrementally. Within your loop, never rely on the context's clearRect if you can afford a manual fill; the former is slower in more than one browser. Looking forward, use the new compositor-friendly CSS propertiestransform and opacity to move canvas elements with the GPU.
Finally, know when to play nicely and use those painting words. Switching layers to DOM or CSS and making a snippet of your