More serious answer: it's using HTML5 canvas, which is quite inefficient as rendering APIs go. For example, if you use n colours when rendering a frame, and your game runs at m frames per second, you are invoking the browser's CSS parser n×m times a second, because CSS colour strings are the only way to express colours, and it is an exclusively immediate-mode API.
The engine in use might be layering on top additional inefficiencies.
(I love how easy to use HTML5 canvas is, but its CPU usage, performance and power consumption properties make me want to cry.)
That's only if you switch colors frequently. Canvas can be quite efficient.
It's irrelevant here-- the game is using Phaser, which can render as either Canvas or WebGL (WebGL in my case), but it's spending most of it's time in engine code updating expensive transforms every frame.
If you're willing to forgo the built-in drawing primitives, you can get access to the underlying buffer and draw directly to that. That way you avoid the CSS parser.
Edit: in particular, getImageData and putImageData.
Is it? It's only using about 10% of a core here. While that's a lot for a game that could run comfortable on a Nokia 3310, it still feels pretty low for JavaScript.
More serious answer: it's using HTML5 canvas, which is quite inefficient as rendering APIs go. For example, if you use n colours when rendering a frame, and your game runs at m frames per second, you are invoking the browser's CSS parser n×m times a second, because CSS colour strings are the only way to express colours, and it is an exclusively immediate-mode API.
The engine in use might be layering on top additional inefficiencies.
(I love how easy to use HTML5 canvas is, but its CPU usage, performance and power consumption properties make me want to cry.)