@uwdlg Letting the browser decide on the refresh rate (reqeustAnimationFrame) is the better way from the browsers perspective, in terms of trying to maintain a consistent framerate. Alternatively, skipping frames from requestAnimationFrame is also a reasonable solution. Because there is no way to reliably query the browser for the refresh rate requestAnimationFrame is targetting, which is dependent on the refresh rate of the current monitor, Unity makes the arguably naïve assumption of 60 Hz, because that’s still the most common monitor refresh rate. Unity will use requestAnimationFrame and skip frames if your target frame rate is evenly divisible from 60. For example, a target frame rate of 30 will use requestAnimationFrame and skip every other frame. A target frame rate of 15 will use requestAnimationFrame and render every 4th frame. Setting the target frame rate to any other value will use a timer instead of requestAnimationFrame for the rendering rate. While this gives you some more control, there is no way for the browser to guarantee to any reasonable degree that timing, because the browser will still composite the page at the rate it wants to, and the frame you just rendered may have to wait for that to be displayed. VSync options in Unity have no affect for the web platform because there is no way to know what the vsync rate is or wait for it from a browser. If setting the target frame rate is not working, as you seem to be saying, then that is a Unity bug.