Why a number, and why this one
Most teams talk about performance in adjectives. Fast. Smooth. Snappy. Adjectives are unfalsifiable, which is exactly why they are popular - nobody can be held to them. We replaced the adjectives with a number. Every interaction we build must hold 120 frames per second on hardware that is a year old. If it cannot, it is not finished.
A number changes the conversation. It turns 'this feels a bit laggy' into 'this dropped to 48fps for 200 milliseconds during the open transition, here is the flame chart.' It gives a junior engineer the authority to reject their own work without waiting for a senior to feel that something is off. The floor is the same for everyone, so the standard does not erode under deadline pressure.
The frame budget is brutal, and that is the point
At 120fps you have roughly 8.3 milliseconds to produce a frame. Subtract the browser's own overhead and you are left with about 5 milliseconds of usable time per frame for your own work. That is not a lot. It is enough to move pixels that are already on the GPU. It is not enough to recalculate layout, run an unoptimised React render, and garbage-collect, all in the same frame.
This brutal budget is a forcing function. It makes certain decisions for you. You stop animating properties that trigger layout - width, height, top, left - and animate only transform and opacity, which the compositor can handle without touching the main thread. You stop reaching for the heaviest animation library out of habit and reach for the cheapest tool that does the job. The constraint does the architecture's arguing for you.
Year-old hardware, not the flagship on the desk
The second half of the rule matters as much as the first. We do not test on the newest machine in the studio. We test on hardware that is roughly a year behind, because that is closer to the median device our clients' customers actually hold in their hands.
It is easy to ship a site that flies on a top-tier laptop wired to gigabit fibre and forget that a meaningful share of your audience is on a mid-range phone, two years old, on a congested mobile network. Performance is an equity issue. A site that only feels premium on premium devices is not a premium site - it is a demo. Designing to the slower device is how you make sure the experience holds for everyone, not just the people who can afford the fastest one.
What the floor forces you to build
Committing to 120fps is not a setting you toggle. It reshapes the whole stack. A few of the decisions it has forced on us:
We render on the server and hydrate carefully, so the main thread is not buried in JavaScript before the user can interact. This is the backbone of our web architecture practice.
We animate on the compositor wherever possible, keeping work off the main thread so a heavy render somewhere else cannot stall a transition. We virtualise long lists so the DOM never holds more nodes than the screen can show. We profile on real hardware, not just the desktop emulator, because the emulator lies about exactly the cases that matter. And we treat the performance budget as a release gate: a feature that breaks the floor does not ship until it is back under it.
It is not the same as Core Web Vitals - but it helps them
Frame rate and Google's Core Web Vitals are related but not identical. Vitals measure loading, layout stability, and responsiveness to input. Holding a high frame rate does not automatically pass them - you can have a buttery animation on a page that loads slowly. But the disciplines reinforce each other. The same restraint that keeps frames cheap keeps your JavaScript bundle small, which improves Interaction to Next Paint and every other metric that lives or dies on main-thread time.
In other words, chasing the frame rate is not at odds with chasing search performance. It is one of the more reliable ways to get there, because both reward the same thing: doing less work, later, off the critical path.
The honest cost
This standard is slower to build to. It rules out shortcuts that would otherwise save a day. It means saying no to effects that would look impressive in isolation but cannot survive the budget. We accept that trade because the alternative - a site that demos beautifully and degrades the moment it meets a real device - is not work we are willing to put our name on.
If you want to know whether your current site clears the floor, we will profile it. Tell us about your project and we will send back the flame charts.