The CSS animations killing your INP score

Your site has a nice hover effect on the cards. Maybe a color transition, a box-shadow that grows on focus, or a left/top animation that slides a panel into view. It looks smooth on your M3 MacBook. On a three-year-old Android phone on a busy page with 40 cards, it's a different story.

The difference comes down to which CSS properties you're animating. Some properties can be handled entirely by the GPU compositor, which means the browser's main thread stays free. Others force the browser to recalculate layout or repaint pixels on every single frame, which blocks the main thread and directly hurts your Interaction to Next Paint (INP) score.

Composited vs. non-composited

The browser's rendering pipeline has distinct stages: style calculation, layout, paint, and compositing. Properties like transform and opacity can skip straight to compositing because they don't change the element's geometry or pixel content. The GPU handles them on a separate thread.

Properties like color, background-color, box-shadow, border-radius, width, height, top, left, margin, and padding cannot be composited. Changing any of these forces the browser to either repaint (recalculate pixels) or reflow (recalculate layout), or both. On every frame of the animation. At 60fps, that's 16.6ms per frame to complete the work, and on a budget phone, the browser can't keep up.

Why INP cares

INP measures the delay between a user interaction (click, tap, keypress) and the next visual update. If the main thread is busy repainting a box-shadow animation when the user taps a button, the browser can't process the tap until the paint finishes. The user sees lag. Google measures it. Your INP score drops.

This is particularly insidious because the animation looks fine in isolation. The problem only appears when the animation runs concurrently with user interaction, which is exactly the scenario INP is designed to capture.

What the audit finds

The Non-Composited Animation Audit scans your page's CSS for every transition and animation declaration, identifies which CSS properties are being animated, and flags the ones that trigger layout or paint.

Common findings include:

Hover transitions on color or background-color. These are everywhere. The fix is to use opacity transitions instead, or to animate a pseudo-element's opacity over a pre-colored background.

Box-shadow transitions. A growing box-shadow on hover looks elegant but triggers a full repaint of the element and surrounding area on every frame. The fix is to place the shadow on a pseudo-element and animate its opacity.

Width/height animations for accordions or expandable sections. These trigger layout recalculation. The fix is to animate transform: scaleY() or use max-height with a reasonable upper bound.

Top/left/right/bottom for sliding panels. Any positional animation using these properties triggers layout. The fix is transform: translateX() or translateY(), which composites on the GPU.

The audit ranks findings by estimated performance impact. An animation on a single decorative element is a low-priority fix. An animation on a repeated card component that appears 50 times on a listing page is a high priority.

If you're building pages that need to perform well on real-world devices, not just your development machine, The $97 Launch ($9.99 on Kindle) covers performance budgeting as part of the build process.

Fact-check notes and sources

Google's web.dev documentation on rendering performance explains the compositing pipeline and which properties can be GPU-accelerated. Source: web.dev, "Rendering Performance."
INP replaced FID as a Core Web Vital in March 2024. Source: Google Search Central, "Interaction to Next Paint (INP)."
The CSS will-change property can promote elements to their own compositor layer, but overuse causes memory issues. Source: MDN Web Docs.
Chrome DevTools Performance panel shows "Recalculate Style" and "Paint" events that correspond to non-composited animation work.