Creative case study
Slot Game Performance Overhaul
Diagnosing and resolving critical performance bottlenecks in a live HTML5 slot title — achieving a 3x framerate improvement on mid-range Android devices.
Creative case study
Diagnosing and resolving critical performance bottlenecks in a live HTML5 slot title — achieving a 3x framerate improvement on mid-range Android devices.
Client
Live iGaming Operator
Role
Performance Engineer
Year
2025
Discipline
Optimization
Framerate on target Android device went from an average of 18 FPS to a stable 60 FPS without asset quality reduction.
The hero image is loaded from the MDX coverImage field. Replace the demo URL with your own gameplay capture, PixiJS canvas screenshot, or rendered artwork.
18 → 60
FPS improvement
94 → 8
Draw calls cut
40%
Memory reduction
A live slot game with an existing player base was receiving complaints about poor performance on budget Android phones. The game ran well on desktop but suffered frame drops, jank, and occasional crashes on mobile. The operator could not afford a full rewrite.
I started with SpectorJS to capture a WebGL frame and count draw calls. The result was alarming: 94 draw calls per frame for a relatively simple reel scene.
The culprits, identified by the capture:
PIXI.Sprite loaded from individual PNG files — no texture atlas.requestAnimationFrame callbacks simultaneously.I ran all game assets through TexturePacker to generate two atlases: symbols.atlas and ui.atlas. This alone dropped draw calls from 94 to 22.
The win-burst effects were using PIXI.Container with individual sprite children. Migrating them to PIXI.ParticleContainer with pre-allocated capacity cut particle-related draw calls to 1 and eliminated GC pauses during big-win animations.
Background scroll layers were converted to PIXI.TilingSprite, eliminating the need for multiple sprites and reducing draw calls for the background to 2.
After all rendering fixes: 8 draw calls per frame.
Chrome DevTools heap snapshots revealed that the bonus round screen was creating new PIXI.Text objects on every trigger without destroying the old ones. The fix was straightforward: a text object pool with a getText() / returnText() API.
A similar issue existed in the sound manager — Howler.js instances were being created without unloading, consuming growing amounts of audio buffer memory.
Stable 60 FPS on the target device. Memory footprint reduced by 40%. Player complaints dropped to zero within two weeks of the patch going live. The profiling and fix methodology is now part of the team's internal QA checklist.
More Case Studies
A technical deep-dive into how production iGaming studios store, version, and serve complex game math configurations across operators, jurisdictions, and variants.
A complete blueprint of an enterprise iGaming backend system: from the Seven-Layer Model and 48ms game transaction loops to GLI compliance and scaling pipelines.

An educational compiler project translating academic Computer Science theory into a working plain-English general-purpose compiler that compiles directly to zero-overhead x64 assembly.