Diagnose and fix slow canvas, dashboard and data-heavy browser applications.
When a web application drops frames, lags during interaction or drains laptop batteries under real datasets, the bottleneck is almost always how the code talks to the browser. I profile the hot path and fix it in a focused sprint.
Common performance bottlenecks
- Your dashboard, map, editor or simulator was fast during early testing, but now stutters and drops frames with real-world customer datasets.
- Heavy Canvas 2D rendering or complex data structures cause UI interactions, zooming and panning to feel sluggish.
- Layering multiple third-party charting libraries has led to a bloated bundle and frequent garbage collection freezes.
- Your team is considering WebAssembly to speed up critical loops, but has not yet shipped WASM modules in production.
Profile the bottleneck, batch the rendering
Most browser performance issues are not because modern JavaScript is slow at raw arithmetic, but because of how frequently the application crosses boundaries or forces the browser to re-allocate memory.
Every time code repeatedly calls between JavaScript, the Canvas 2D context or a WebAssembly instance within an animation frame, you pay boundary overhead. I created Batchiness to solve this in my own projects: batching canvas draw calls so the boundary is crossed just once per frame.
- Measure first: Using browser profilers and allocation traces, I isolate where frame time is actually spent: draw calls, layout recalculations, GC pauses or redundant DOM updates.
- Fix the critical path: We move the computation loop to WebAssembly (Go, Zig, Odin) or batch canvas rendering, eliminating per-frame allocations.
- Keep your existing stack: You don't need a total rewrite of your web app. We fix the specific bottleneck that is causing lag and leave the rest of your architecture intact.
These demos run live in your browser and demonstrate high-throughput rendering without stutter:
- Batchiness: My open-source library for batching Canvas 2D operations from WebAssembly. It powers several of my games to maintain a steady 60fps with thousands of animated entities.
Batchiness on GitHubTechnical walkthrough - OdinDom & ZigDom: Direct WebAssembly-to-DOM/Canvas bridges I wrote for Odin and Zig, avoiding heavy runtime frameworks.
OdinDomZigDom - Destroids & Odin Particles: Vector arcade physics and high-particle count simulations running at steady 60fps with zero external graphical assets.
DestroidsOdin Particles - ZigFlame & 3D Heatmap: Real-time numerical diffusion and thermal calculations running client-side in WebAssembly.
ZigFlame3D Heatmap
How the engagement works
- 1. Performance Audit (1 week, R15,000 fixed). With staging access or repository review, I profile the application under real load. You receive a technical report outlining the root causes, profiling traces, a prioritised fix list, and expected speedup. If we proceed with the fix sprint, this fee is credited towards it.
- 2. Fix Sprint (1 to 2 weeks, fixed price from audit). I tackle the primary bottleneck directly: canvas batching, hot loop migration to WebAssembly, or memory churning. You get a pull request with benchmarks, tests and documentation.
- 3. Optional Review Retainer: A lightweight arrangement (typically one day a week or bi-weekly) to review performance of new features before they reach production.
Is this a good fit?
Good fit if- You have an active product with real users, and performance lag is impacting retention or sales demos
- Your application involves Canvas, WebGL, maps, charts, audio, or continuous state simulation
- Your product team wants a specialist to solve the rendering bottleneck without derailing feature roadmaps
- You value concrete benchmarks over speculative advice
- You have a typical marketing or WordPress site with slow hosting or unoptimised images; that is standard web optimisation, not a systems performance issue
- You are looking to build a brand new application from scratch (see Startup MVP in 4 Weeks), or migrate an old desktop app (see Legacy Rescue)
- You want team management rather than focused engineering and profiling
Pricing
Prices below are indicative; we agree on a firm fixed price in writing before any work starts.
- Performance Audit: R15,000 fixed for the profiling report, identified bottlenecks and recommended roadmap (credited to the fix sprint).
- Fix Sprint: From R55,000 fixed price agreed after the audit, focused on measurable improvements for the core bottleneck.
- Performance Retainer: From R8,000/month for ongoing code reviews, profiling checks and architectural guidance. Cancel anytime.
Frequently asked questions
Do we have to use Odin or Zig?
No. I work in whatever stack your team uses. If your backend or client is in Go, C#, TypeScript or JavaScript, that is where we make the fix. While I use Odin and Zig for personal graphics and compiler projects because they are pleasant to iterate in, client work stays in code your team can maintain.
Will this break our existing code?
No. The fix sprint is scoped to a specific hot loop, render cycle or memory allocation bottleneck. The changes are covered by tests and benchmarks, and submitted as a standard PR for your team to review.
Can you work under an NDA and inside our repo?
Yes. Signing NDAs, working directly in your Git repository and coordinating via Slack or async check-ins during the sprint is completely normal.
Is WebAssembly always the answer?
No, and that is what the audit is for. Frequently the issue is excessive DOM re-renders, unnecessary garbage collection churn, or poorly structured canvas state. If the fix can be done in plain JavaScript without introducing WASM, I will tell you to do that.
What kind of performance improvement should we expect?
It depends on the bottleneck. Batching Canvas 2D calls to cross the JS/WASM boundary once per frame typically yields an immediate 3x to 5x frame rate improvement on object-heavy screens. The audit gives you measured numbers from your actual code rather than generic claims.
Let's look at your application's bottleneck
Book a 30-min Performance Call