Why a small animation can feel slow
A smooth animation needs the browser to produce each visual update in time for the next screen refresh. If an update takes too long, the browser may miss a frame and the motion can appear to jump. The visible result depends on the device, the page, and what else the browser is doing, so an animation that feels fine on one computer may struggle on another.
Two common causes are layout thrashing and excessive main-thread work. Layout thrashing happens when code repeatedly changes the page and then asks the browser for measurements that depend on those changes. Main-thread work is broader: JavaScript, style calculation, layout, and other tasks can compete for time with input handling and rendering. Understanding the difference helps you fix the cause rather than simply shortening the animation.
Mistake 1: Mixing layout reads and writes in a loop
Browsers normally group rendering work when they can. A script can disrupt that grouping by changing an element’s size or position, immediately reading a measurement such as offsetWidth or getBoundingClientRect(), then changing another element and reading again. To answer each measurement accurately, the browser may need to update styles and calculate layout before continuing the script. Repeating that pattern across many elements can turn one planned layout calculation into many.
Imagine moving a row of cards by first setting one card’s width, measuring the next card’s position, and repeating for every card. The measurements may be necessary, but alternating reads and writes makes them expensive. A better approach is to collect the needed positions first, then apply the changes. If the new positions can be calculated from known values, avoid measuring the page on every frame.
Be careful with computed styles and element geometry inside animation callbacks or scroll handlers. Not every read forces layout, and the exact cost depends on what has changed, but a measurement after a layout-affecting write is worth investigating. Replacing repeated live measurements with cached values can help, provided you refresh that cache when the viewport or content changes.
Mistake 2: Animating properties that trigger extra rendering work
Changing width, height, top, or left may require layout because those properties can affect where elements belong on the page. Changes that do not affect layout may still require painting. For motion that does not need to rearrange surrounding content, transform is often a better fit; opacity is often suitable for fades. These properties can sometimes be handled through compositing, reducing the work required for each frame.
That is a useful guideline, not a guarantee that every transform is cheap. Large moving layers, complex visual effects, and too many promoted elements can consume substantial memory or rendering time. Use will-change sparingly rather than applying it to every animated item. First choose properties that match the effect, then test the complete page on a device representative of your audience.
Mistake 3: Filling the main thread during animation
An animation can stutter even when its own code is efficient. Parsing a large response, sorting a big collection, updating many DOM nodes, or running an expensive event handler can occupy the main thread while the browser is trying to respond to input and prepare frames. A requestAnimationFrame callback is useful for scheduling visual updates before a render, but it does not make costly work disappear. A long callback can still delay the next frame.
Keep per-frame work narrow: calculate only what is needed and update only the elements that changed. For pointer or scroll-driven effects, avoid performing a full DOM update for every incoming event when one update per frame will do. Passive listeners can help the browser handle scrolling when the listener does not need to cancel it, but they do not reduce the time spent running your handler. Where practical, split unrelated heavy work into smaller tasks or move suitable calculations to a worker; DOM changes still need to happen on the main thread.
A practical way to diagnose and improve an animation
Start by reproducing the stutter and recording it with browser performance tools. Look for long JavaScript tasks, repeated layout calculations, and paint work around the affected frames. Then inspect the code that runs during those moments. A measurement immediately after a style change suggests a read-and-write problem; a long handler or animation callback suggests too much work in one turn.
Change one thing at a time. Batch measurements before DOM writes, replace layout-changing motion with transforms when the design allows it, or reduce the amount of work done per frame. Record the interaction again to see whether the change helped. The goal is not to eliminate all layout or JavaScript: it is to perform necessary work at predictable times, without repeatedly interrupting the browser’s rendering pipeline.
