Author here. Perhaps the "if sbperftest runs well, most other HTML5 games should run decently as well" statement should have been inverted, so it reads "if sbpe

Author here. Perhaps the "if sbperftest runs well, most other HTML5 games should run decently as well" statement should have been inverted, so it reads "if sbperftest doesn't run well, few other HTML5 games will". We develop a major HTML5 game engine, and this statement is backed by quite a bit of testing and profiling of real-world games. The test is deliberately based on a real-world game (it was adapted from an interactive game) so it's not a synthetic benchmark. No it is not enormously onerous for the CPU or GPU, but if you look at the results many mobile devices still can't quite manage a rock-solid 60 FPS, so I think it serves pretty well to see if mobile devices are fast enough for relatively simple games. There is actually a lot of collision testing in the laser-to-enemy intersection test - all of the objects in the game have custom collision polygons, it's not a simple bounding box test. The explosions use additive blending (or "lighter" composite mode) which actually seems to stress many canvas2d implementations but generally is a lot smoother with WebGL. So it's not that simple a test. I'm not sure why the 60 second period is important; the most intensive part is the waves of green sprites which should come well within the measured period, and it gets quieter after that when the test ends, so it's not skipping the hard bit.