If you're interested in more information about it, I posted an article about how the FPS of a Construct project is tied to the refresh rate on the C2 wiki:
Delta Time and Refresh Rate
Collisions and Framerate
I actually ended up figuring out how it worked on accident as a result of playing with the preview.js file a ways back.
Here's part of the article:
The underlying Construct 2 engine uses something called "requestAnimationFrame" (underlying v-sync related browser timing) to attempt to peg the game tick at approximately 60 times per second, however, it usually matches the display refresh rate of the browser/computer which is nearly always 60hz except in the case of some new 120hz monitors. This means that in most cases, dt ~= 0.0167 of a second (remember that dt is the elapsed time in seconds since the previous game tick). Obviously though, cpu intensive games and other things can cause the frame-rate to fluctuate.
Construct makes use of delta-time in order to be frame-rate independent. A frame-rate independent game tries to ensure that a game behaves in the same way regardless of the actual FPS. In some older games, the movement of sprites in the game was proportional to the frame rate. This meant that if you tried to play the game on a modern system today, the high frame rate would cause everything in the game world to move extremely fast making the game virtually unplayable.
In most cases, this means that delta-time returns the actual time in seconds from the last game tick. However, if the frame-rate dips below 10 fps, Construct will cap the returned value of DT at 0.1 seconds. When this happens, the game will physically appear to slow down. As outlined in the article on delta time, Construct synchronizes the logic and rendering loop through something called requestAnimationFrame which is used internally by the browser to peg the FPS to the refresh rate of the local monitor, typically 60hz so 60fps.