Animated Websites: What Each Technique Costs You in Performance

Animation on the web is a performance budget, and the biggest single factor in whether it feels smooth is which CSS properties you animate. Two visually identical effects can differ by an order of magnitude in cost, purely because one triggers layout on every frame and the other does not.

The inspiration galleries show you what is possible without mentioning that many of those sites weigh several megabytes and stutter on a mid-range phone. This is the other half: what each technique actually costs, in an order you can act on.

Table of contents

• The rendering pipeline, and why it decides everything
• Making an element move without touching layout
• The weight problem, which is usually bigger
• Accessibility is not optional here
• Measuring rather than guessing
• How this fits the rest of the stack
• FAQ

The rendering pipeline, and why it decides everything

The browser turns your page into pixels in stages, and where an animation enters that pipeline determines its cost.

1. Style — work out which rules apply.
2. Layout — calculate where everything goes and how big it is.
3. Paint — fill in pixels for each element.
4. Composite — assemble the painted layers into the final image.

An animation that changes geometry forces the browser back to layout, which means recalculating positions for potentially the entire page, then repainting, then compositing — sixty times a second. An animation that only moves or fades an already-painted layer skips straight to composite, which the GPU handles cheaply.

That gives a rule you can apply without measuring anything:

• Cheap — composite only: transform (translate, scale, rotate) and opacity. These are the two properties to build animation around.
• Expensive — triggers layout: width, height, top, left, margin, padding, font-size. Anything that changes size or position in the document flow.
• In between — triggers paint: background-color, box-shadow, border-radius. Cheaper than layout, not free.

So a menu that slides in should use transform: translateX(), not an animated left. Visually identical, and one of them stutters on a phone while the other does not.

Making an element move without touching layout

The practical translation of the above.

/* Expensive: recalculates layout every frame */
.panel { left: -300px; transition: left 300ms ease; }
.panel.open { left: 0; }

/* Cheap: composited, GPU-friendly */
.panel { transform: translateX(-300px); transition: transform 300ms ease; }
.panel.open { transform: translateX(0); }

The same substitution applies broadly. Growing a card on hover uses transform: scale() rather than animating width and height. A progress bar animates transform: scaleX() rather than width. A fade uses opacity rather than adjusting a colour’s alpha channel on a background.

One more property worth knowing, used sparingly: will-change tells the browser to promote an element to its own layer in advance, avoiding a hitch on the first frame.

.panel { will-change: transform; }

Apply it only to elements that are genuinely about to animate, and remove it afterwards where you can. Each promoted layer consumes memory, and a page that promotes everything can end up slower than one that promotes nothing — this is a common way to make things worse while trying to make them faster.

The weight problem, which is usually bigger

Frame cost is one half. The other is what you downloaded to achieve the effect, and this is where animation-heavy sites usually lose.

• Animation libraries are convenient and are JavaScript that must be parsed and executed before anything animates. Check the size of what you are adding, and whether CSS could do it.
• Scroll-driven effects historically needed a library and a scroll listener. Modern CSS scroll-driven animations and the Intersection Observer API cover most cases without one.
• Video backgrounds are the heaviest thing on this list by a wide margin, frequently several megabytes for a decorative loop. If you use one, it should be short, muted, compressed hard, and never the largest-contentful-paint element.
• Animated SVG is usually excellent — small files, vector-crisp, and animatable in CSS.
• Lottie and JSON-driven animation sits in between: smaller than video, and it needs a runtime library.

The question worth asking for each effect is what it earns. An entrance animation that delays content by 400ms costs every visitor 400ms forever, and its benefit is a first impression that returning visitors have already had. Animation that communicates something — a state change, a relationship between two screens, feedback on an action — earns its place. Decoration on the critical path usually does not.

Accessibility is not optional here

A meaningful number of people experience motion sickness, vertigo or migraine from parallax and large motion. The platform gives you a signal and honouring it is a few lines.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

That blunt version is a reasonable default and better than nothing. The considered version keeps small functional transitions — a button state, a fade — and removes the large motion: parallax, sliding panels, zooming, anything that moves a lot of the screen.

Two other things worth doing: never convey information by motion alone, since someone with reduced motion enabled will miss it entirely; and avoid anything that flashes more than three times a second, which is a seizure risk and a hard accessibility failure rather than a preference.

Also worth remembering that autoplaying video needs muted to autoplay at all in most browsers, and that a decorative background video should carry aria-hidden so screen readers ignore it.

Measuring rather than guessing

A short workflow that catches nearly everything.

1. Throttle the CPU in developer tools to 4x or 6x slowdown. Your development machine is not representative of the phone your visitors hold, and this single setting reveals most jank.
2. Record a performance profile while the animation runs and look for long frames. Purple layout blocks appearing every frame mean you are animating a geometry property.
3. Check the layer count. Excessive layer promotion shows up as memory pressure and, on lower-end devices, as slowdown.
4. Run a Lighthouse pass and watch Cumulative Layout Shift in particular — entrance animations that move content after it renders are a common and avoidable CLS source.
5. Test on a real mid-range phone. Not the newest flagship, and not a desktop with the window resized.

The most common finding from doing this honestly: the animation is fine and the images are the problem. Animation gets blamed for slowness that is actually a 4MB hero image, because the stutter is visible and the download is not.

How this fits the rest of the stack

Animation cost is mostly bytes and frames rather than server load, but the bytes are bandwidth and the build is where they get optimised. The RunxBuild hosting calculator shows transfer beside the build and anything dynamic so the heavier effects are a priced decision. RunxBuild builds static sites from a repository — the right place for compressing media and generating image variants — with response headers as configuration so animation assets get cached properly, and 120GB of bandwidth included.

Useful related references:

• Python for Websites: Where It Fits and Where It Does Not
• Photography Hosting: What Image-Heavy Sites Actually Need
• Dynamic Websites vs Static Sites: The Server, the Cache, the Data, and the Right Choice for 2026
• Services on RunxBuild

FAQ

Which CSS properties are cheapest to animate?

transform and opacity. Both are handled at the compositing stage, so the GPU can move an already-painted layer without recalculating anything. Properties that change geometry — width, height, top, left, margin — force the browser back through layout on every frame, which is where stutter comes from.

Why does my animation stutter on mobile but not desktop?

Usually because it animates a layout-triggering property, and a phone has far less headroom to absorb the cost. Throttle the CPU to 4x or 6x in developer tools and the same stutter appears on desktop. Switching from left to transform: translateX is often the entire fix.

Should I use will-change?

Sparingly, on elements that are genuinely about to animate, and remove it afterwards where practical. It promotes an element to its own layer to avoid a first-frame hitch. Applying it broadly consumes memory and can make a page slower than not using it at all.

Do I need to support prefers-reduced-motion?

Yes. A meaningful number of people experience motion sickness or migraine from large motion effects, and honouring the signal is a few lines of CSS. Keep small functional transitions and remove parallax, sliding and zooming. Never convey information by motion alone.

Are animation libraries bad for performance?

Not inherently, but they are JavaScript that must download, parse and execute before anything animates. Check whether CSS transitions or modern scroll-driven animations cover the case first. The heaviest offender on most animated sites is not the library — it is a multi-megabyte background video.