Graphics timing in modern browsers, including (especially) on mobile, is done via
requestAnimationFrame(), introduced as a result of the W3C's specs on timing control for script-based animations, replacing the older
setInterval() approach. Both call an event handler.
requestAnimationFrame() (RAF) ensures far more reliable / regular timing than
setInterval() and the like. How it works (loosely) under the hood is to let the browser know that what is currently happening in the timed event handler is an animation, and as such certain measures should be taken (by supporting browsers) to ensure this process proceeds smoothly. And to quote MSDN:
simplifies animations by scheduling the next animation frame only when the system is ready to
paint. This leads to smoother animations and less power consumption
than previous animation techniques because requestAnimationFrame takes
the visibility of the web application and the refresh rate of the
display into account.
At least for Mozilla-based browsers and IE, RAF will typically match the display refresh rate and so generally guarantees a steady refresh period / frequency of around 60FPS, although admittedly Opera docs suggest that RAF does not guarantee this. In general, however, I would go with the Chrome/Firefox/IE recommendation, which is that you can rely on the rate noted above.
Under the hood, Three.js will be using RAF, or if the browser doesn't support it, will fall back to