Website Animation Performance: Motion Without Lag

Animation can guide attention, explain a product and make a brand feel alive. It can also make a site feel slow. Website animation performance usually comes down to a few technical choices made early: which properties move, when the animation starts, and how much JavaScript runs while it plays.

This guide covers those choices in plain terms, for business owners briefing a designer or developer and for the developers themselves.

Why some animations stutter

Every time something on a page changes, the browser may have to do up to three kinds of work:

1. Layout: work out where everything sits and how big it is.
2. Paint: fill in the pixels: text, colors, shadows, images.
3. Composite: stack the painted layers together on screen.

Layout is the most expensive, because changing one element's size or position can move everything around it. Paint is next. Compositing is the cheapest. A smooth animation does as little layout and paint as possible on each frame.

The rule: animate transform and opacity

web.dev's animation guide says to avoid animating any property "other than transform and opacity" without first checking its cost, and to "avoid any property that triggers layout or paint unless it's absolutely necessary." In practice:

• To move something, use transform: translate() instead of changing top, left, margin or position.
• To resize something, use transform: scale() instead of changing width or height.
• To fade something, use opacity.
• To rotate or skew, use transform.

web.dev shows the difference with a pair of demos: a box animated with top and left "causes 50% of frames to be dropped," while the same movement with transform "causes only 1% of frames to be dropped." The movement looks the same on screen; only the cost differs.

Some effects are expensive by nature. web.dev notes that "anything that involves a blur (like a shadow, for example) takes longer to paint." Animated shadows, blurs and filters on large areas are worth testing on a mid-range phone before you commit to them.

How animation affects Core Web Vitals

Animation touches all three Core Web Vitals. Our explainer on Core Web Vitals covers the metrics; here is where motion fits.

Cumulative Layout Shift (CLS). web.dev's CLS guide says changing top and left properties "cause layout shifts, even when the element being moved is on its own layer," while "composited animations using translate can't impact other elements, and so don't count toward CLS." Expanding accordions, sliding banners and growing cards should use transform where they can.

Largest Contentful Paint (LCP). This is the trap we see most often. A hero headline or image that fades in from opacity 0 looks elegant, but web.dev lists "elements with an opacity of 0, that are invisible to the user" among those Chrome excludes from LCP. If the hero waits for a script, then fades in over a second, your LCP waits too. Two fixes:

• Show the main headline and hero image immediately, and animate secondary elements around them.
• If the hero must animate, start it visible and animate transform, or keep the fade very short and run it in CSS rather than after a script loads.

Interaction to Next Paint (INP). Heavy JavaScript animation libraries, scroll listeners that run on every pixel of scroll, and large animations starting at the same moment as a tap all compete for the main thread. If a button feels slow to respond while something is moving, INP will show it.

Use will-change carefully

The will-change property tells the browser an element is about to change, so it can prepare a separate layer. web.dev cautions that "layer creation can cause other performance issues" and recommends using it "only if you notice graphics issues." It also suggests that for elements that change only occasionally, you add will-change with JavaScript just before the change and remove it afterwards. Applying it to everything uses memory and can make things worse.

Test before you ship

You do not need guesswork. web.dev describes two quick checks in Chrome DevTools:

1. Does it trigger layout? Open the Performance panel and record while the animation runs. A non-zero Rendering value in the Summary tab suggests the animation is doing layout work.
2. Is it dropping frames? Open the Rendering tab and enable the FPS meter. A high percentage of frames rendered means the animation is smooth; a low one means it is dropping frames.

Run both on a throttled CPU or a real mid-range Android phone. A fast laptop hides problems a customer's phone will show.

A rule for reading the result: if the Rendering value is zero and the frame percentage stays in the high nineties on the phone, ship it. If either check fails, look at which property is moving before you look at anything else.

Respect people who want less motion

Some visitors find movement distracting or physically uncomfortable. Two rules cover most sites:

• Honor the reduced-motion setting. The prefers-reduced-motion media query, documented on MDN and widely supported, lets you swap large movements for simple fades or no movement at all.
• Give long animations a pause control. WCAG 2.2 requires a way to pause, stop or hide moving content that starts automatically, "lasts more than five seconds," and plays alongside other content.

A website animation performance checklist

Use this when you brief a designer or review a build:

• Every animation has a purpose: guide attention, explain a change of state, or show the product.
• Movement uses transform and opacity unless there is a tested reason not to.
• The hero headline and image are visible at first paint.
• No layout shift from banners, cookie bars or cards expanding.
• Scroll-driven effects are tested on a mid-range phone.
• Large libraries are loaded only on the pages that use them.
• Reduced-motion users get a calmer version.
• Anything that loops for more than five seconds can be paused.

When rich motion is worth it

Some sites need more than fades: product reveals, scrollytelling, 3D. These can still be fast if they are built with a budget from the start and loaded only where they are used. The work is in deciding which moments deserve the motion and keeping everything else light.

How Pinn.Media builds motion

We design and build animated sites with performance checked as we go, using the tools listed on our stack page and testing on real phones before launch. If your site looks great in the demo and feels heavy on a phone, book a discovery call and we will show you where the motion is costing you.