We have occasional but repeated support requests along the following lines:
1) User with 300mb of images on a single layout wonders why their game doesn't run on a device with 50mb of free memory for applications
2) User with 4 fullscreen size images, all on-screen, wondering why such a "simple" game performs poorly on mobile
In some cases the users blame Construct 2 for being slow or buggy. I always try to explain how mobile devices are much, much weaker than desktops, but it seems almost everyone new to Construct 2 assumes a game running well on their 500W desktop PC with a 300-core GPU and 1 GB of dedicated VRAM will run well on a battery-powered phone with a 4-core GPU with no dedicated VRAM, just shared system memory, of which there might be only 50mb free.
This paper is also interesting for pointing out how mobile GPUs are actually optimised for 3D, and also how native developers go to quite extraordinary lengths to squeeze extra performance out of low-end hardware. We do our best to make Construct 2's engine as fast as possible, but when you do things like use your entire overdraw budget with four sprites, it's difficult for us to do much in the engine to mitigate that. Good game designers just design their games better than that, with awareness of the capabilities of the hardware.
The technique the paper describes is interesting, but impossible to apply in the canvas 2D renderer (so it won't work on Safari for iOS). It's also still pretty complicated to apply automatically in the WebGL renderer since as the paper notes it can't handle disjoint images, as well as the fact we've already highly optimised the WebGL renderer for quads. However it helps you understand how to design an efficient mobile game, even in Construct 2. Remembering transparent pixels are still "drawn" is a good rule of thumb. A common mistake I've seen is people making window borders by making a fullscreen sprite, mostly transparent, but with borders round the edges. Splitting this in to four separate objects for each edge should give a good performance boost - and save lots of memory! In general, splitting up sprites with large areas of transparency is sort of the manual version of what the paper suggests.
I'm sure Javascript is fast enough. The fact our WebGL renderer is usually twice as fast as the canvas 2D renderer, where the rendering calls happen in native code, is a sign how good it can get. However we need more widespread WebGL support to get the benefit of that. In the mean time I think the most common problem is just that Construct 2 makes it really easy to throw in loads of sprites and effects and give a mobile device more than it can handle - something that native developers usually know to avoid.