# Framer Motion Hardware Acceleration Caveats with `x` / `y` / `scale` Shorthands > Discover Framer Motion hardware acceleration caveats. Learn why x/y/scale shorthands use the main thread while transform strings leverage GPU acceleration for smoother animations. - Repository: [Emil Kowalski/skills](https://github.com/emilkowalski/skills) - Tags: deep-dive - Published: 2026-08-05 --- **Framer Motion's `x`, `y`, and `scale` shorthands run on the main thread via `requestAnimationFrame` and do not benefit from GPU acceleration, while full `transform` strings are executed by the compositor thread for smooth, hardware-accelerated animations.** Understanding when Framer Motion can leverage GPU acceleration is critical for building fluid web interfaces. While the library's shorthand properties offer concise, readable code, they come with significant performance trade-offs that every developer should know. This guide examines the hardware acceleration caveats documented in the `emilkowalski/skills` repository and shows exactly how to write performant animations. ## Why Shorthand Properties Lack Hardware Acceleration Framer Motion provides intuitive shorthands like `x`, `y`, and `scale` for common transform operations. However, these conveniences hide an important implementation detail: **they execute on the main thread**. According to [`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md) at lines 118-122, the shorthands are explicitly marked as **"NOT hardware-accelerated"**. The repository explains that these properties are driven by `requestAnimationFrame` callbacks, meaning each frame must wait for JavaScript execution before the browser can apply visual changes. This creates a performance bottleneck under several conditions: - High-frequency animations (60fps continuous motion) - Concurrent animations running simultaneously - Heavy JavaScript workload competing for main thread time - Complex layout calculations triggering reflows The same warning appears in [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) at lines 495-502, where the documentation states that `x`/`y`/`scale` "run on the main thread via rAF and drop frames under load." ## Hardware-Accelerated Alternative: Full `transform` Strings For GPU-accelerated motion, animate the complete CSS `transform` property instead of individual shorthands. The compositor thread handles these animations independently, keeping motion smooth even when JavaScript is busy. ### Performance Comparison | Approach | Execution Thread | Performance Characteristic | Best For | |----------|----------------|----------------------------|----------| | `x`, `y`, `scale` shorthands | Main thread (rAF) | CPU-bound, frame drops possible | Simple, infrequent UI feedback | | `transform: "translateX(...)"` | Compositor/GPU | GPU-bound, consistent 60fps | Drag gestures, drawers, scroll-driven effects | | Web Animations API | Compositor/GPU | Native browser optimization | Programmatic control + maximum performance | ### Code Examples: Shorthand vs. Hardware-Accelerated **Avoid:** Shorthand properties without GPU acceleration ```tsx // ❌ Runs on main thread — may drop frames under load ``` **Prefer:** Full transform string with compositor acceleration ```tsx // ✅ Executed by GPU — smooth even when JS thread is busy ``` ## Advanced: Web Animations API for Maximum Performance When you need **both** JavaScript control and hardware acceleration, the native Web Animations API (WAAPI) provides an optimal middle ground. It offers compositor-level performance with programmatic interruptibility. ```js // ✅ Hardware-accelerated and interruptible const element = document.querySelector('.animated-element'); element.animate( [ { transform: 'translateX(0)' }, { transform: 'translateX(100px)' } ], { duration: 300, easing: 'cubic-bezier(0.23, 1, 0.32, 1)' } ); ``` ### Combining Framer Motion with WAAPI For complex React components, you can reference Framer Motion elements and apply WAAPI animations directly: ```tsx import { useEffect, useRef } from 'react'; import { motion } from 'framer-motion'; function SlidingDrawer({ isOpen }) { const drawerRef = useRef(null); useEffect(() => { if (!drawerRef.current) return; const keyframes = isOpen ? [ { transform: 'translateX(-100%)' }, { transform: 'translateX(0)' } ] : [ { transform: 'translateX(0)' }, { transform: 'translateX(-100%)' } ]; drawerRef.current.animate(keyframes, { duration: 250, fill: 'forwards', easing: 'cubic-bezier(0.32, 0.72, 0, 1)' }); }, [isOpen]); return ; } ``` ## Practical Decision Framework Choose your animation strategy based on these criteria: 1. **Simple hover states or micro-interactions** — shorthands are acceptable; the convenience outweighs minimal overhead 2. **Draggable elements, drawers, or modals** — always use full `transform` strings or WAAPI 3. **Scroll-linked or gesture-driven animations** — require hardware acceleration; main thread execution will feel unresponsive 4. **Interruptible physics-based motion** — leverage WAAPI's native support for spring and decay simulations ## Summary - **`x`/`y`/`scale` shorthands** execute on the main thread via `requestAnimationFrame` and can drop frames under load, as documented in [`skills/review-animations/STANDARDS.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md) and [`skills/emil-design-eng/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/emil-design-eng/SKILL.md) - **Full `transform` strings** are handled by the compositor thread, enabling GPU-accelerated, smooth animations independent of JavaScript execution - **Web Animations API** provides the best of both worlds: programmatic control with native browser optimization - Reserve shorthands for low-impact, infrequent animations; use hardware-accelerated approaches for any motion that must remain fluid under stress ## Frequently Asked Questions ### Why do Framer Motion shorthands run on the main thread? Framer Motion's `x`, `y`, and `scale` properties are implemented as JavaScript-driven animations using `requestAnimationFrame` to calculate and apply values each frame. This design provides maximum flexibility for the library's spring physics and gesture systems, but it prevents the browser from offloading the work to the GPU compositor. The `emilkowalski/skills` repository explicitly notes this architectural trade-off in its animation standards documentation. ### Can I mix shorthands and full transform strings in the same animation? Avoid combining both approaches on the same element. Framer Motion treats shorthand properties and the `transform` string as separate animation targets, which can lead to conflicting transforms and unexpected visual results. Choose one strategy per animated element: use shorthands for simple cases where convenience matters, or commit to full `transform` strings when hardware acceleration is required. ### Does using `will-change: transform` help with shorthand performance? The `will-change` CSS property hints to the browser that a property will animate, but it does not change Framer Motion's internal implementation. Since shorthands are calculated in JavaScript and applied via inline styles each frame, `will-change` provides minimal benefit. For true hardware acceleration, you must animate the complete `transform` property as a string value rather than individual transform components. ### When should I choose WAAPI over Framer Motion entirely? Consider WAAPI for standalone animations that don't need Framer Motion's gesture integration or layout projection features. The native API excels at simple translations, fades, and scaling operations with minimum overhead. However, for React-driven state animations, shared layout transitions, or complex gesture orchestration, Framer Motion with hardware-accelerated `transform` strings remains the more maintainable choice.