60 frames, no compromises

Animation quality is one of the clearest signals that separates a premium product from a mediocre one — even if users can't articulate why. When a page feels sluggish, when scrolling hitches, when a hover state flickers — that's a performance problem, not a design one. And it almost always comes from the same root cause: JavaScript doing work it shouldn't be doing.

The browser has two rendering stages that matter here: the main thread and the compositor thread. The main thread handles JavaScript execution, layout calculations, and paint. The compositor thread handles the final compositing of layers. Only two CSS properties run entirely on the compositor thread: transform and opacity. Everything else — top, left, width, height, background-color — forces the main thread to recalculate layout or repaint, which drops frames.

We work compositor-first. Animations that move things use transform: translate() instead of changing top or left. Animations that show or hide things use opacity instead of display or visibility. The browser handles these on a dedicated thread that runs even when the main thread is busy processing a click or running a script. That's why these animations stay at 60fps even on a loaded page.

For complex multi-step animations we use GSAP, and for component-level interactions — hover states, scroll reveals, 3D card tilts — we use Motion. Both libraries respect the compositor boundary. The practical result is animations that feel instant and inevitable rather than impressive — which is exactly the right calibration for a product that wants to feel premium.