Motion design earns its place in modern interfaces – a well-placed transition guides attention, confirms an action, and makes an interface feel responsive rather than static. It also has a well-documented failure mode: the same animation techniques that make a UI feel polished can quietly wreck Interaction to Next Paint (INP), the Core Web Vital that replaced First Input Delay in March 2024 and now measures responsiveness across every interaction on a page, not just the first one.
The good news is that this is a solvable engineering problem, not a trade-off you have to accept. Which CSS properties you animate, and which thread the browser runs that animation on, determines almost entirely whether motion design helps or hurts your Core Web Vitals. This article breaks down exactly how the browser handles animation under the hood, and the specific techniques that let motion design enhance UX without competing with INP for the same thread.
How the Browser Renders Animation: Main Thread vs. Compositor Thread
Every animation ultimately runs on one of two browser threads, and which one determines its performance ceiling. The main thread handles JavaScript execution, style recalculation, layout, and paint – the bulk of a page’s work, and the same thread responsible for handling user interactions and, by extension, INP. The compositor thread handles composite layer operations, running independently of whatever the main thread is doing.
This distinction matters because most main-thread work routinely stalls for tens or even hundreds of milliseconds at a time under normal page activity. An animation that depends on the main thread being free to render each frame will visibly stutter whenever that thread gets busy – and an animation implemented in JavaScript using setInterval or manual style updates runs entirely on the main thread, competing directly with the same resources INP depends on to respond quickly to a click, tap, or keypress.
The compositor thread, by contrast, keeps animations smooth even when the main thread is fully occupied with React re-renders, data processing, or other JavaScript work. Offloading animation there isn’t a minor optimization – it’s the difference between an animation that stays smooth under load and one that becomes the reason your INP score fails.
The Animation Performance Tier List: Which CSS Properties Are Safe
Not every CSS property that can be animated is safe to animate. A useful mental model ranks properties by which stage of the browser’s rendering pipeline – Style, Layout, Paint, Composite – they trigger on every frame.
| Property Type | Rendering Stage Triggered | Thread | INP Impact |
| transform, opacity, filter, clip-path | Composite only | Compositor thread | None – main thread stays free |
| width, height, top, left, margin, padding | Style → Layout → Paint → Composite | Main thread | Severe – full pipeline runs every frame |
| background-position, box-shadow | Paint → Composite | Main thread | Moderate to severe on low-end devices |
The four compositor-safe properties – transform, opacity, filter, and clip-path – can produce a genuinely wide range of motion design: slides, fades, scales, rotations, blurs, and reveal effects are all achievable using only these properties. Animating layout-triggering properties like top, left, width, or height instead forces the browser to recalculate layout on every single frame of the animation, which is both a common cause of poor Cumulative Layout Shift scores and a direct drain on the main thread that INP depends on.
Why Does Animating top or left Hurt Performance More Than transform?
Animating top or left triggers a full layout recalculation on every frame, because the browser has to determine how that position change affects surrounding content. Animating transform instead moves an element visually without recalculating layout at all, since the transform is applied purely during compositing – skipping layout and paint entirely and running on a dedicated GPU-accelerated thread.
Why JavaScript-Driven Animations Threaten INP Specifically
Even when an animation targets compositor-safe properties like transform and opacity, the mechanism used to drive it still matters. CSS-based animations and transitions, along with the Web Animations API, can run entirely on the compositor thread once initiated. JavaScript animation libraries built on requestAnimationFrame, by contrast, update these same properties from the main thread – meaning the animation itself remains interruptible, generally smooth, but vulnerable to jank whenever the main thread gets blocked by something else, such as a heavy interaction handler.
This is precisely why heavy scroll-linked or hover-triggered JavaScript animations tend to show up as INP problems in field data – a pattern Search Savvy sees repeatedly when auditing interaction-heavy product pages: they compete for the exact same thread INP measures responsiveness on, so a page can look fine in a quiet lab test and still register poor real-world INP once actual user interactions overlap with animation work.
Modern Techniques for GPU-Accelerated Motion Design in 2026
Several current browser capabilities make it easier than ever to build rich motion design without touching the main thread:
- Native CSS scroll-driven animations. Modern CSS scroll timelines let scroll-linked effects run entirely on the compositor thread, remaining smooth even when the main thread is blocked by heavy JavaScript or data processing – a significant improvement over the older pattern of updating styles from a scroll event listener in JavaScript, which routinely produces visible jank because it competes directly with layout and script execution.
- The animation-composition property. For complex, stacked scroll-driven sequences – a simultaneous scroll-linked rotation and translation, for example – this property lets multiple transforms accumulate rather than overwrite each other, without falling back to JavaScript orchestration.
- The FLIP pattern for layout animations. When an animation genuinely needs to represent a layout change – repositioning an element from one part of the page to another – the FLIP technique (First, Last, Invert, Play) calculates the transform needed to fake the layout change visually, then animates that transform on the compositor thread instead of animating the actual layout properties frame by frame.
- scheduler.yield() for necessary main-thread work. When some animation-adjacent logic genuinely must run on the main thread, this API allows that work to yield periodically to the browser, keeping the thread responsive to user interactions rather than blocking it for the full duration of the task.
A Practical Checklist for Motion Design That Protects INP
- Audit existing animations for layout-triggering properties. Search your CSS and JavaScript for animations touching top, left, width, height, margin, or padding, and rebuild them using transform and opacity wherever the visual effect allows it.
- Prefer CSS transitions and animations over JavaScript-driven ones for any effect achievable with transform, opacity, filter, or clip-path, since these run on the compositor thread by default without additional configuration.
- Reserve JavaScript animation libraries for effects CSS genuinely can’t achieve, and be aware that doing so reintroduces main-thread dependency, with the corresponding INP risk under load.
- Use native scroll-driven CSS animations instead of scroll event listeners wherever the effect is achievable with scroll timelines, avoiding the jank that comes from updating styles via JavaScript on every scroll tick.
- Test animation performance under realistic main-thread load, not just in isolation – an animation that looks smooth on an idle page can behave very differently once real interaction handlers, analytics scripts, and data fetching are competing for the same thread.
A structural review of where animation logic actually runs is often what surfaces these hidden INP costs, since they’re rarely visible from a simple visual QA pass. This is exactly the kind of rendering-pipeline diagnosis Search Savvy runs before recommending any front-end changes as part of its technical SEO services, treating INP as a rendering problem first rather than assuming it’s purely a JavaScript bundle-size issue.
Common Mistakes in Motion Design for Core Web Vitals
- Animating layout properties for simple slide or fade effects. Almost any slide, fade, or reveal effect achievable with top/left/width/height can be rebuilt using transform and opacity with no visual compromise and a significant performance gain.
- Driving compositor-safe properties through JavaScript unnecessarily. Even transform and opacity lose their compositor-thread advantage if updated manually through requestAnimationFrame when a CSS transition or the Web Animations API would achieve the same effect natively.
- Treating INP purely as a JavaScript execution-time problem. Animation choices are frequently the hidden contributor to poor INP scores, especially on interaction-heavy pages like product configurators or dashboards.
- Testing animations only on idle pages. Motion that looks perfectly smooth in isolated testing can degrade significantly once real user interactions and background scripts compete for the same main thread.
- Ignoring scroll-linked animations built on JavaScript scroll listeners. These are a common, easily overlooked source of main-thread jank that native CSS scroll-driven animations can eliminate entirely.
The Bottom Line
Motion design and Core Web Vitals aren’t inherently in tension – the conflict only appears when animations are implemented in ways that compete with the main thread INP depends on. Restricting animations to transform, opacity, filter, and clip-path, driving them through CSS or the Web Animations API rather than JavaScript wherever possible, and using modern scroll-driven CSS capabilities instead of scroll event listeners lets teams build genuinely rich motion design while keeping INP scores in the “good” range.
The practical next step is auditing your site’s current animations for layout-triggering properties and JavaScript-driven effects that could be rebuilt on the compositor thread instead. Search Savvy’s website audit services identify exactly these rendering-pipeline issues as part of a full Core Web Vitals assessment, and its website design and development services can rebuild the affected components so motion design becomes an asset for user experience rather than a hidden liability for performance.
Frequently Asked Questions
Which CSS properties are safe to animate without hurting INP? transform, opacity, filter, and clip-path can all be animated entirely on the compositor thread, without triggering layout or paint operations, which keeps the main thread free to respond to user interactions.
Why do animations using top and left hurt performance? Animating top or left forces the browser to recalculate layout on every single frame, since it needs to determine how the position change affects surrounding content. This runs on the main thread and competes directly with the work INP measures.
Does using a JavaScript animation library automatically hurt INP? Not automatically, but it introduces risk. JavaScript-driven animations built on requestAnimationFrame run on the main thread even when animating compositor-safe properties like transform, meaning the animation becomes interruptible and vulnerable to jank whenever the main thread is busy with other work.
What replaced FID as the responsiveness metric that motion design can affect? INP (Interaction to Next Paint) replaced First Input Delay as a Core Web Vital in March 2024. It measures the full responsiveness cycle across all interactions on a page, not just the delay before the first one, making sustained animation performance more relevant to the score than it was under FID.
Can scroll-linked animations be made INP-safe? Yes, primarily by using native CSS scroll-driven animations and scroll timelines instead of JavaScript scroll event listeners. Scroll-linked effects driven by JavaScript style updates routinely produce main-thread jank, while CSS-based scroll timelines run on the compositor thread and remain smooth even under heavy main-thread load.
What is the FLIP pattern, and when should it be used? FLIP (First, Last, Invert, Play) is a technique for animating layout changes efficiently by calculating the transform needed to visually fake the layout change, then animating that transform on the compositor thread instead of animating the actual layout properties frame by frame. It’s most useful when an animation genuinely needs to represent an element moving between different layout positions.
