MicrosoftEdge
[Animation Smoothness] Feedback for the Animation Smoothness Explainer
Thank you for reviewing the Animation Smoothness Explainer. We invite you to share your thoughts and feedback on the proposed methods in the explainer. Your feedback will help us develop a way to effectively measure animation smoothness in Edge and will ensure that the API meets your needs.
I'm from Framer, a no-code website builder. We have high interest in this proposal as animation smoothness is one of our key features and important for our animation library Motion. The goals of the proposal match with what we have in mind, especially considering measuring can be quite expensive using the rAF polling, so we'd be in favour of this new API to collect data.
I'm also very excited about this proposal and it's something we've long desired. A bunch of thoughts in no particular order:
- I slightly prefer the PerformanceObserver approach. It conforms to the same pattern as most other CWV tools and is flexible enough that it could include a large variety of useful data. It might even have multiple types of data emitted from the same listener (could be opt-in per type). E.g. summary data of larger time periods. Individual or batch instances of non-smoothness. State changes for dynamic refresh rate. Whatever the final proposal lands on being appropriate.
- I largely think about smoothness from the opposite perspective of jank. 1 FPS isn't a problem if nothing is happening. 60 FPS might be a big problem if we're on a 120hz device and the user is used to that. Have you considered dropped frames (frames that would have painted if there was more time) as a metric of smoothness? This is where user-noticeable moments occur. Some prior art that comes to mind is the colored frame squares in Chromium DevTools, showing when frames are delivered on time, the main thread drops frames, or the main thread drops but the compositor still delivers frames. I could imagine different events delivered for the main thread and compositor if they separately drop frames.
- Are web workers drawing to offscreen canvases (as an example) in scope of other ways of rendering? Just a minor detail but didn't see it called out though it could impact some use cases like gaming.
- Why are specific animations off-limits? That seems like one of the most actionable pieces that could be exposed here. Otherwise authors will have to try and manually correlate frame drops with animation time periods. If using the PerformanceObserver approach, I could imagine it including a list of affected animations.
- Whatever data is collected here, exposing it in DevTools on the timeline would also be extremely valuable. Even if it required an explicit checkbox if it's expensive to collect.
- Gesture-linked animations are perhaps the most critical area of smoothness in terms of feeling the jank. I don't know if there's a generic way to capture this today given most gestures are JS implementation using touch or pointer events, but capturing that for available browser gestures could be useful. Scroll would likely be the easiest, both whole page and scroll containers.
It could be valuable to explore ideas from the “Media Playback Quality” talk presented at TPAC 2025 (@handellm):
Exposing metrics such as Harmonic FPS and Jitter RMSE (computed over sufficiently long animation ranges) would give developers actionable insights into animation smoothness. Unlike simple FPS averages—which can mask short bursts of stutter—these metrics capture both frame pacing consistency and variability. This helps developers diagnose subtle performance issues, prioritize optimizations, and deliver a more fluid user experience.
