Web Animations and Speed: Smooth Motion Without Jank

Short answer: Animations slow a website when they force the browser to recalculate layout or repaint large areas on every frame, when they hide content until a script runs, or when they rely on heavy JavaScript libraries. Animate transform and opacity instead of width, height, top or margin, never keep the main content invisible waiting for a “reveal” effect, trigger scroll effects efficiently, and respect the reduced-motion setting. Done this way, motion can be smooth even on modest phones.

Why animations can make a page feel slow

For motion to look smooth, the browser has to produce a new frame about 60 times a second on a typical screen, which leaves roughly 16 milliseconds per frame for all the work involved. On faster screens the budget is even smaller. When an animation needs more than that, frames are dropped and the movement stutters, which developers call “jank”.

The browser also has other work to do in the same time: running scripts, responding to taps and clicks, loading images. An expensive animation competes with all of it. On a powerful laptop the difference may be invisible. On a mid-range phone, which is what many visitors use, the same effect can make scrolling rough and taps feel unresponsive.

Animations can also affect Core Web Vitals directly. They can delay the moment the main content becomes visible, cause elements to move in ways counted as layout shift, and keep the main thread busy when a visitor tries to interact.

How the browser draws a frame

Understanding the rendering steps makes it clear why some animations are cheap and others are expensive. For each frame, the browser may need to:

1. Style: work out which CSS rules apply to each element.
2. Layout: calculate the size and position of every affected element.
3. Paint: fill in pixels: text, colours, borders, shadows, images.
4. Composite: put the painted layers together on screen in the right order.

An animation that changes a property affecting layout forces all four steps, often for much of the page, on every frame. An animation that changes only compositing properties can skip layout and paint, and modern browsers can often run it on a separate compositor thread, so it stays smooth even while the main thread is busy.

Which properties are cheap and which are expensive

The rule of thumb is simple: if you can express the motion as moving, scaling, rotating or fading, do it with transform and opacity.

A few everyday examples show how this works in practice. A dropdown menu that slides down can be built with transform: translateY() and a fade, instead of animating its height. A card that “lifts” on hover can use a small scale and fade in a pre-drawn shadow layer, instead of animating box-shadow directly. A side menu that opens from the left can move with translateX rather than changing left. The visual result is the same, but the browser does a fraction of the work.

Animations and Cumulative Layout Shift

Layout shift measures unexpected movement of content. Animations built with layout properties can move surrounding content, and those movements may be counted in CLS. A banner that slides in by animating its height from zero, for example, pushes everything below it down a little on every frame.

Movements made with transform do not change the position of other elements and are not counted as layout shifts in the same way. That is another reason to prefer transforms. If an element must change size, reserve its final space first, then animate its contents within that space. Our guide to fixing Cumulative Layout Shift covers reserving space in more detail.

Reveal-on-scroll effects and LCP

A popular design pattern makes sections fade or slide in as the visitor scrolls. It often starts with the content set to opacity: 0 and a script that makes it visible when it enters the viewport.

The problem appears when this pattern is applied to content at the top of the page. The heading or hero image stays invisible until the animation script has downloaded, run and triggered. Content that is invisible is not treated as painted for Largest Contentful Paint, so the LCP time becomes the moment the animation finishes, which can be a second or more later than necessary. If the script fails to load, the content may never appear.

• Never apply reveal animations to the first screen of the page. Show the hero content immediately.
• For content further down, make sure it is visible by default and only animated when the script is available, so it degrades gracefully.
• Keep reveal durations short. Long, slow fades make pages feel sluggish even when they are fast.

See how to improve Largest Contentful Paint for other causes of late main content.

Scroll and JavaScript-driven animations

JavaScript animations are not bad in themselves, but some patterns are costly:

• Scroll event handlers that do heavy work. Listening to every scroll event and changing styles directly can run dozens of times per frame. Use the Intersection Observer API to detect when elements enter the viewport, or CSS scroll-driven animations where supported.
• Reading and writing layout in a loop. Code that reads an element’s size and then changes a style, repeatedly, forces the browser to recalculate layout again and again. Batch reads, then writes, and schedule visual changes with requestAnimationFrame.
• Heavy animation libraries for small effects. Loading a large library to fade in three boxes adds download and parsing time. CSS transitions often do the same job with no script at all.
• Animations running during interactions. If a click starts a long animation on the main thread, the next frame is delayed. That shows up in Interaction to Next Paint; our guide to fixing INP explains how to find such delays.

Autoplaying carousels are a common combination of all these problems. The article on hero sliders and carousels explains their costs.

Use will-change carefully. The will-change property tells the browser that an element is about to be animated, so it can prepare a separate layer in advance. Used on one or two elements just before an animation, it can make motion smoother. Applied to many elements permanently, it increases memory use and can make performance worse, especially on phones. Treat it as a targeted fix for a measured problem, not a default setting.

Respect reduced motion and page builders’ defaults

Many operating systems let people ask for less motion, for example because animation causes them discomfort or dizziness. Websites can honour this with the prefers-reduced-motion media query: disable or simplify non-essential animations when it is set. It is an accessibility improvement first, but it also reduces work on devices where the user has chosen it.

Page builders and themes often add entrance animations to every section by default. Review those settings. Turning off decorative entrance effects site-wide, or at least on the first screen, is one of the quickest speed wins on builder-based sites. Our article on page builders and performance lists other settings worth checking.

How to find animation problems

1. Open Chrome developer tools, go to the Performance panel, enable CPU throttling to simulate a slower phone and record while scrolling and interacting.
2. Look for long purple (layout) and green (paint) blocks during animations, and for dropped frames.
3. In the Rendering panel, turn on paint flashing and layout shift regions to see what is repainted or moved.
4. Check which element is reported as LCP and whether it starts invisible.
5. Test on a real mid-range phone; your own device is probably faster than your visitors’ average.

How Site AI Audit helps

Site AI Audit includes a Google PageSpeed measurement of your mobile speed and Core Web Vitals, LCP, CLS and INP, in its website check, together with SEO, SSL, security headers and e-mail authentication. Findings are explained in plain words and ranked by impact, so you can see whether visual effects are worth reviewing. Re-checks after changes are part of the plans on the pricing page.

Related reading

• Total Blocking Time Explained: What It Means and How to Cut It
• How to Reduce Unused JavaScript and Speed Up Your Pages
• Why Your Website Is Slow on Mobile and How to Fix It

The bottom line

Motion can make a website feel polished, or make it feel slow. Animate transform and opacity, keep the first screen visible without waiting for effects, handle scroll effects efficiently, use will-change sparingly and respect reduced-motion preferences. Then test on a real phone, because that is where your visitors decide whether the site feels fast.

FAQ

Which CSS properties are best for animations?

Transform and opacity. Browsers can usually animate them without recalculating layout or repainting, often on a separate compositor thread, so they stay smooth on slower devices.

Do animations affect Core Web Vitals?

They can. Reveal effects can delay LCP, layout-based animations can add to CLS, and heavy script-driven animations can slow responses to clicks and hurt INP.

Are fade-in on scroll effects bad for SEO?

They are a problem when applied to the main content at the top of the page, because hidden content delays LCP. Lower on the page, short effects on content that is visible by default are fine.

Should I use will-change on animated elements?

Only where you have measured a problem, and on few elements. Overusing will-change increases memory use and can reduce performance, especially on phones.

What is prefers-reduced-motion?

It is a CSS media query that detects when a user has asked their device for less motion. Websites should disable or simplify non-essential animations when it is set.