At first, I will say that if the game is working fine in your targeted platforms, keep a backup so you don t break anything (but that is sort of obvious), then try to see if there is no code repetitions, or things that can be bothersome to read/debug inside your events.
The estimated image memory as far as I know won t be the same in the debbuger and on cocoonJS, the debbuger should have a lower value (Unless cocoonJS does layout by layout loading, which I don t think it does).
There are basically 3 aspects you want to verify:
Memory use (not only pictures, but mostly them): it is sort of a everything or nothing type of thing, if the ressources fits inside at runtime, it is ok (in cocoonJS, I think that means every ressources combined have to fit it, but others will explain better), if it does not fit, then slowdown will occur because the texture and sounds will be loaded from the main drive. Keep in mind we are talking about uncompressed data here. Basically this will determine mostly the range of devices that can use the game. The OS also gets a part of it too.reducing the size of the assets is the way to go, if needed, try to see if something can be reduced (sometimes, a blurry graphics is not a problem, exemple, a cloud in the sky, also for a gradient, a huge texture size is not needed, remember also that textures works mostly as the same or just above power of 2 square)
-Canvas2D renderer is slower, and so will take more time to render the same things the webGL renderer can.
-Fillrate: dont draw too many surfaces at once, the GPU can only render a certain size of all texture combined (pretty sure it is more complex than that, but it is to explain the basic concept). Also with the OS running, a part of it is already used I think
-calculations:graphic calculations for the rendering can be somewhat big when you are using WebGL effects (depend on the effect used), and blend modes (again, a non abusive use is fine)
-texture load and unload takes time, but this is completely out of the question qith cocoonJS if I remember.
-having an option to switch to the Low quality setting can help if the user is having graphic troubles.
-calculating something when it is not needed will take a certain time (depending on what it is, it could be a problem or not), groups can help you deactivate useless stuffs easily
-unecesary loops will also drain performances, however in case the loops are the best choice, don t restrain yourself from using them
-draw calls can be pretty heavy
-try to use the better physic engine for you if you are using physics(the cocoonJS one should do the trick in your case, it is not the default one)
-software rendering is your worst nightmare, that basically means that the graphics are handled by the cpu, as well as the logic, which means that their time are summed together, instead of being the most out of the two, also, a cpu is not good at doing graphic calculations
-functions are good enough to be used, so do not try to take them away
-micro optimisation is not worth it, don t try to optimise everything, concentrate on what matters.
Hope that helps, and that it was not too wrong.