A product manager reports that a list animation "feels janky" on real phones, though it looks fine on your laptop. What number would you use to describe animation smoothness, and how would you measure it?

## Why "janky" needs a number "Feels janky" is a real report and a useless bug ticket. It cannot be assigned, cannot be verified as fixed, and cannot be defended in a review. The first job is to convert the complaint into a measurement that (a) reproduces, (b) matches what the user perceived, and (c) has a threshold you can pass or fail. ## Why average fps is the wrong metric Frame rate averaged over an animation hides exactly the events people notice. Consider a 3-second animation at 60 Hz: about 180 frames. If 176 land on time and four frames each take 100 ms, the arithmetic still reports something in the high 50s — while the user sees the animation freeze for a quarter of a second in the middle. Smoothness is a property of the worst frames, not the mean. The same reasoning is why a frames-per-second counter drawn on the page is a weak tool. Besides costing work of its own, it typically shows a rolling average, which is the number that hides the problem. And counting your own callbacks is not the same as counting frames the display actually presented — an animation can be delivering frames without your loop running, and your loop can run without a frame reaching the screen. ## The numbers worth reporting Two, together: 1. **Dropped-frame percentage over the interaction window.** Of the frames the display expected during the animation, what share did the browser fail to present? This is the metric browsers themselves use for smoothness, and it is scale-independent — it means the same thing at 60 Hz and 120 Hz, which matters when your users are on both. 2. **The longest frame.** One 250 ms frame is a different defect from fifty 20 ms frames, with a different cause and a different fix. The maximum, or a high percentile of frame duration, keeps that distinction visible. If you want a third, add *when* in the animation the drops cluster: at the start (setup cost — measurement, style recalculation, new elements entering), spread evenly (per-frame work simply exceeds the budget), or in one lump partway through (something unrelated stole the thread). ## Measuring it honestly **Reproduce on representative hardware.** This is the whole reason the laptop showed nothing. A developer machine can be several times faster than a mid-range phone, so the same per-frame work fits comfortably in one place and misses the deadline in the other. Either test on a real device from your target tier, or apply CPU throttling in DevTools so the profile approximates one. Pick a specific reference device and keep it fixed, otherwise numbers from different weeks are not comparable. **Record the interaction, not the page.** Start the recording, perform the exact gesture, stop. A trace of the whole page load buries the three seconds you care about. **Read the frames, then read the cause.** A performance recording shows each frame the browser produced and flags the ones it could not present in time. Chrome's Rendering drawer additionally offers a frame-rendering-stats overlay that shows a live dropped-frame reading while you interact, which is handy for a first pass before you commit to a full trace. **Confirm the fix by re-measuring the same way.** Same device, same throttling, same gesture, same window. "It feels better now" is how the ticket started. ## Turning it into a budget Once you have a number, write it down as an acceptance condition for the interaction: for example, *no more than 2% of frames dropped, and no frame over 32 ms, on the reference device*. Two things follow. First, the fix has a definition of done. Second, the number is a ceiling the next feature has to respect — motion tends to accumulate, and "one more animated element" is how a smooth interaction becomes a janky one over three sprints. Budget the *interaction*, not the page. A global "the app runs at 60 fps" is unmeasurable; "opening the filter drawer drops under 2% of frames on a Pixel-class device" is a test. ## Lab numbers versus what users get Even a well-run trace is a lab measurement: one device, one network, one state, one operator. It proves the animation *can* be smooth, not that it *is* smooth in production, where users have extensions, background tabs, thermal throttling and older hardware. Treat the trace as the diagnostic tool and the field data as the verdict — and expect the field distribution to be worse than your reference run, not better. ## What a strong answer sounds like Name the metric (dropped-frame share plus worst frame), reject the average, insist on representative hardware, describe how you would reproduce and record the specific interaction, and close the loop with a budget that makes the fix verifiable and protects it afterwards. Candidates who jump straight to a fix — "I'd use transforms" — are guessing; the interviewer is checking whether you measure before you change anything.