Eliminating Jank: Optimizing React mousemove Handlers for Buttery-Smooth UX

If you've ever built an interactive slider, drag-and-drop interface, or before/after comparison tool in React, you've probably encountered the dreaded jank—that stuttery, unresponsive feeling when moving your mouse rapidly across the screen. Today, we'll dissect why this happens and how to fix it with practical, production-ready techniques.

The Problem: A Janky Before/After Slider

Let's start with a common UX pattern: a horizontal slider that reveals a "before" and "after" design by dragging a vertical divider left and right. Here's the unoptimized code:

const handleMouseMove = (e: React.MouseEvent<HTMLDivElement>) => {
  if (!containerRef.current || !userLayerRef.current) return;

  const rect = containerRef.current.getBoundingClientRect();
  let x = e.clientX - rect.left;
  x = Math.max(0, Math.min(x, rect.width));
  
  setSliderX(x);
  userLayerRef.current.style.clipPath = `inset(0 ${rect.width - x}px 0 0)`;
};

On the surface, this looks reasonable. But move your mouse quickly across the slider, and you'll notice visible stutter—especially on lower-end devices or when the browser is doing other work.

Why does this happen? Let's break it down frame by frame.

Why This Code Causes Jank

The jank comes from three compounding issues that create a perfect storm of main-thread congestion:

Issue 1: getBoundingClientRect() on Every mousemove

The mousemove event can fire 30-60+ times per second during rapid mouse movements. Each time our handler runs, we call:

const rect = containerRef.current.getBoundingClientRect();

The problem: getBoundingClientRect() is a layout read. When you read layout properties (dimensions, positions, etc.), the browser must ensure its layout calculations are up-to-date. If there were any pending layout-affecting changes earlier in the frame (DOM mutations, style changes), the browser is forced to recalculate layout synchronously.

This is expensive. Doing it 60 times per second creates a bottleneck that can easily cause dropped frames.

Issue 2: Triggering React State Updates on Every Event

Every mousemove event calls:

setSliderX(x);

This schedules a React render. Even with React's automatic batching in React 18+, we're still asking React to:

• Schedule a state update
• Reconcile the component tree
• Potentially re-render child components
• Update the DOM

In our case, sliderX is used to:

• Position the vertical slider line via inline style
• Update a badge showing the current position (e.g., 150px)

If your component tree includes iframes, complex child components, or heavy computations, these constant re-renders add significant overhead. The React reconciler is fast, but it's not free—and running it 60 times per second is wasteful.

Issue 3: Direct DOM Mutation in the Event Handler

We're also directly mutating the DOM:

userLayerRef.current.style.clipPath = `inset(0 ${rect.width - x}px 0 0)`;

Direct DOM writes aren't inherently bad, but when combined with:

• Layout reads (getBoundingClientRect())
• Frequent React state updates
• Tight mousemove loops

...they all compete on the main thread and amplify jank. The browser's rendering pipeline gets overwhelmed trying to keep up with:

mousemove → layout read → compute → React update → DOM write → more layout → repeat 60x/sec

This creates layout thrashing—a cycle of reading and writing layout properties that forces the browser to recalculate layout multiple times per frame instead of once.

What We Want Instead: Frame-Friendly Updates

Our goals are clear:

• ✅ Avoid expensive layout reads on every mousemove
• ✅ Avoid setState on every raw pointer event
• ✅ Coordinate DOM writes with the browser's rendering pipeline
• ✅ Keep the UX identical: slider still tracks the mouse smoothly

To achieve this, we'll use three key techniques:

Technique 1: Cache Layout Data

Instead of calling getBoundingClientRect() on every event, we'll cache the container's bounding rect in a ref and only update it when necessary (on mount and resize).

Technique 2: Use requestAnimationFrame to Batch Updates

Rather than doing work immediately in the event handler, we'll schedule it for the next animation frame. This ensures we update at most once per frame (typically 60fps), no matter how many mousemove events fire.

Technique 3: Use Refs for High-Frequency Values

We'll store sliderX in a ref for fast, non-rendering updates, and only sync it back to React state once per frame.

Step-by-Step Optimization

Let's transform our janky code into buttery-smooth perfection.

Step 1: Cache the Container Rect

First, create a ref to store the cached rect:

const rectRef = useRef<DOMRect | null>(null);

Then, cache it on mount and update it on window resize:

useEffect(() => {
  if (containerRef.current) {
    rectRef.current = containerRef.current.getBoundingClientRect();
  }

  const handleResize = () => {
    if (containerRef.current) {
      rectRef.current = containerRef.current.getBoundingClientRect();
    }
  };

  window.addEventListener('resize', handleResize);
  return () => window.removeEventListener('resize', handleResize);
}, []);

Now update handleMouseMove to use the cached rect:

const handleMouseMove = (e: React.MouseEvent<HTMLDivElement>) => {
  if (!rectRef.current || !userLayerRef.current) return;

  const rect = rectRef.current; // ✅ No layout read!
  let x = e.clientX - rect.left;
  x = Math.max(0, Math.min(x, rect.width));

  // ... rest of the code
};

Impact: We've eliminated the layout read from the hot path. The rect is computed once on mount and only when the window resizes—not 60 times per second.

Step 2: Introduce requestAnimationFrame and a Ref for sliderX

Create refs to track the slider position and animation frame ID:

const sliderXRef = useRef(sliderX);
const rafIdRef = useRef<number | null>(null);

useEffect(() => {
  sliderXRef.current = sliderX;
}, [sliderX]);

Now, the optimized handleMouseMove:

const handleMouseMove = (e: React.MouseEvent<HTMLDivElement>) => {
  if (!rectRef.current || !userLayerRef.current) return;

  const rect = rectRef.current;
  let x = e.clientX - rect.left;
  x = Math.max(0, Math.min(x, rect.width));

  // ✅ Update ref immediately (no re-render)
  sliderXRef.current = x;

  // ✅ Schedule update for next animation frame
  if (rafIdRef.current === null) {
    rafIdRef.current = requestAnimationFrame(() => {
      rafIdRef.current = null;

      const currentX = sliderXRef.current;

      // Direct DOM update: clipPath
      if (userLayerRef.current && rectRef.current) {
        const r = rectRef.current;
        userLayerRef.current.style.clipPath = `inset(0 ${r.width - currentX}px 0 0)`;
      }

      // React state update (for slider line + badge)
      setSliderX(currentX);
    });
  }
};

What's happening here?

• Immediate ref update: sliderXRef.current = x captures the latest mouse position instantly (no re-render)
• Frame-based batching: requestAnimationFrame ensures we only update the DOM and React state once per frame
• Coalescing: If multiple mousemove events fire between frames, only the latest value is used

Impact: We've capped our work at 60 updates per second maximum (aligned with the display refresh rate), regardless of how many mousemove events fire. The visual behavior remains responsive because we're still updating every frame.

Step 3: Keep Initial Clip-Path in Sync

Finally, ensure the clip-path is initialized correctly on mount and when sliderX changes:

useEffect(() => {
  if (containerRef.current && userLayerRef.current) {
    const rect = containerRef.current.getBoundingClientRect();
    rectRef.current = rect;
    userLayerRef.current.style.clipPath = `inset(0 ${rect.width - sliderX}px 0 0)`;
  }
}, [sliderX]);

This ensures consistency between the first render and subsequent mouse moves.

Interactive Demo: Feel the Difference

Try it yourself! Move your mouse rapidly across the sliders below. We have two scenarios to demonstrate the performance impact:

What to notice:

Scenario 1 (Simple DOM): The difference is subtle but present. The unoptimized version has slight stutter during rapid movements.

Scenario 2 (Complex iframes): This is where the optimization really shines! The unoptimized version with iframes will feel significantly janky - the slider struggles to keep up, frames drop, and the experience feels sluggish. The optimized version, despite having the same complex iframes, remains smooth and responsive.

This demonstrates a crucial point: the more complex your UI, the more important these optimizations become. Simple DOM elements might hide the performance issues, but real-world applications with iframes, heavy components, or complex rendering will expose them immediately.

The optimized version feels native—like it's part of the browser's rendering pipeline rather than fighting against it, even with heavy content.

Advanced Optimizations for Complex Content (iframes)

The iframe-based demo in Scenario 2 implements 11 advanced optimization techniques that go beyond the basic optimizations. These are crucial when dealing with heavy content like iframes, complex components, or expensive rendering operations.

The 11 Optimization Techniques

1. Eliminated React state for slider position

Instead of useState(sliderX) which triggers a full React re-render (including both iframes) on every mouse move, we use useRef(sliderXRef). The slider position lives in a ref, resulting in zero re-renders during sliding.

2. Direct DOM manipulation instead of React reconciliation

Rather than letting React re-render JSX to update style.left, clipPath, and badge text, we use updateSliderDOM() to directly mutate element.style and element.textContent via refs (sliderLineRef, userLayerRef, badgeRef), bypassing React entirely.

3. requestAnimationFrame throttling

Coalesces multiple mousemove events into one update per display frame (~60fps). Skips redundant work if a frame is already scheduled with if (animationFrameRef.current) return.

4. Synchronous clientX capture

We capture const clientX = e.clientX immediately before the RAF callback. This prevents reading a recycled or stale synthetic event inside the RAF callback.

5. Invisible mouse-capture overlay

A transparent <div> with z-30 on top captures all mouse events. This prevents iframes from processing pointer events, eliminating expensive iframe hit-testing.

6. pointer-events: none on both iframe layers

Both target and user iframe wrappers have pointer-events: none, ensuring iframes can't intercept or interfere with mouse tracking.

7. translate3d instead of left for the slider line

Changing left triggers layout recalculation. Using transform: translate3d(${x}px, 0, 0) is GPU-composited, skipping layout and paint phases entirely. will-change: transform ensures its own compositing layer.

8. clip-path + GPU layer promotion via translate3d(0,0,0)

Adding translate3d(0,0,0) on both iframe wrapper divs forces them onto their own GPU compositor layers. With GPU-promoted layers, clip-path: inset(...) changes only trigger recompositing (the cheapest operation), not layout or repaint.

Without GPU promotion, clip-path would cause full repaints (expensive). This is why translate3d(0,0,0) is critical—it makes clip-path compositor-only updates.

9. Cached getBoundingClientRect()

Instead of potentially calling getBoundingClientRect() every frame, we store it in rectRef and only refresh on mouseenter via handleMouseEnter.

10. RAF cleanup on unmount

cancelAnimationFrame in the useEffect cleanup prevents stale callbacks from firing after the component unmounts.

11. Replaced Badge component with span

Using a plain <span ref={badgeRef}> instead of a component avoids potential overhead from components that may not forward refs properly or add unnecessary rendering cost. Direct textContent updates are instant.

Trade-offs: Optimization Techniques Comparison

Rejected Approaches and Why

While building this optimization, we considered several approaches that seemed promising but ultimately proved inferior:

❌ Manual throttling (e.g., setTimeout with 16ms delay)

Why considered: To limit how often the slider updates.

Why rejected: requestAnimationFrame is already the optimal throttle—it's synced to the browser's paint cycle (~60fps). A manual setTimeout throttle is not synced to vsync, causes inconsistent frame timing, and makes the slider feel sluggish. While normal throttling does work, RAF is always superior for visual updates.

❌ CSS transition / animation on the slider

Why considered: To make the slider movement appear smoother.

Why rejected: The slider is user-input-driven (follows the mouse). Adding any transition/easing creates interpolation delay—the slider visually "chases" the cursor instead of being locked to it, making it feel laggy. Animations are only useful for autonomous motion, not direct manipulation.

❌ overflow: hidden + width for clipping (initially accepted, later replaced)

Why considered: clip-path without GPU promotion causes full iframe repaints every frame. Changing width on a wrapper div with overflow: hidden seemed cheaper.

Why rejected: Changing width triggers layout recalculation every frame. While the layout is only on a simple div (not the iframe), it still forces the browser through Layout → Paint → Composite. Once we added translate3d(0,0,0) for GPU layer promotion, clip-path became compositor-only (skipping both layout and paint), making it the superior choice.

❌ clip-path WITHOUT GPU layer promotion

Why considered: Simpler code—just use clip-path: inset(...) directly.

Why rejected: Without translate3d(0,0,0) forcing the element onto its own GPU compositor layer, clip-path changes trigger full repaints of the iframe content every frame, which is extremely expensive.

❌ translateX() instead of translate3d()

Why considered: Simpler syntax, same visual result.

Why rejected: translate3d() explicitly forces GPU layer promotion (the browser must create a compositing layer for 3D transforms). translateX() may be GPU-composited but the browser can choose not to. translate3d(0,0,0) is the canonical hack to guarantee a GPU layer.

❌ Spring/physics-based easing for slider

Why considered: Could make the slider feel "premium."

Why rejected: Same problem as CSS transitions—any interpolation between current position and target position adds perceived input lag for direct-manipulation UI. The slider must be 1:1 with the cursor.

The Architecture Trade-off

The most important lesson from the iframe demo: even with perfect optimizations, iframes have inherent performance costs. The optimized iframe version is significantly better than the unoptimized one, but it will never match the smoothness of simple DOM elements.

When to use these advanced techniques:

• Complex content (iframes, heavy components, canvas)
• Performance-critical interactions (drag-and-drop, drawing tools)
• Real-time collaborative features
• High-frequency updates (60+ events per second)

When simpler optimizations suffice:

• Simple DOM elements
• Infrequent updates
• Non-interactive animations
• Static content

The key is measuring first, optimizing second. Use Chrome DevTools Performance profiler to identify actual bottlenecks before applying these advanced techniques.

Performance Metrics

Let's quantify the improvement. Using Chrome DevTools Performance profiler during rapid mouse movement:

Simple DOM Elements

Complex Content (iframes)

The fully optimized iframe version maintains 60fps even with complex content, while the unoptimized version frequently drops to 15-25fps. The basic optimized version (RAF + cached rect) improves to 40-50fps, but only the fully optimized version with all 11 techniques achieves consistent 60fps.

Key Takeaways

When optimizing high-frequency event handlers like mousemove, scroll, or touchmove:

Cache layout reads: Don't call getBoundingClientRect() or similar methods on every event. Cache the values and update only when necessary.

Use requestAnimationFrame: Batch your updates to align with the browser's rendering pipeline. This caps work at 60fps and prevents wasted computation.

Refs for high-frequency values: Use refs to store rapidly-changing values that don't need to trigger re-renders immediately. Sync back to state only when needed.

Avoid layout thrashing: Separate layout reads and writes. Read all layout properties first, then perform all writes together.

Profile, don't guess: Use Chrome DevTools Performance profiler to identify actual bottlenecks. Sometimes the issue isn't where you think it is.

Beyond This Example

These techniques apply to many scenarios:

• Drag-and-drop interfaces: Track mouse position without re-rendering on every pixel
• Canvas drawing apps: Update cursor position smoothly
• Infinite scroll: Throttle scroll event handling
• Resize handles: Smooth window/panel resizing
• Custom range sliders: Buttery-smooth value updates

The pattern is always the same: minimize work in the event handler, batch updates with requestAnimationFrame, and cache expensive computations.

Conclusion

Performance optimization isn't about making things faster—it's about making them feel faster. A janky interface breaks user trust and makes your app feel unpolished, even if the underlying functionality is solid.

By understanding how the browser's rendering pipeline works and respecting its constraints, we can build interfaces that feel native, responsive, and delightful to use.

The next time you're building an interactive feature, remember: smooth UX isn't magic—it's just good engineering.

Want to dive deeper? Check out these resources:

• MDN: requestAnimationFrame
• Paul Irish: What Forces Layout/Reflow
• Google Web Fundamentals: Rendering Performance

Have questions or optimizations to share? Let me know in the comments below!