1. Home
  2. Blog
  3. Animated websites

Do Animations Slow Down Your Website? Motion vs Core Web Vitals

Animation doesn't slow a site down by existing. It hurts LCP, INP and CLS in three specific ways, and each one has a fix.

ASFARI Lab6 min readOctober 2026

A glass stopwatch dissolving into streaks of motion on an ink-black background

Do animations slow down a website? Not by themselves. A well-built fade or scroll reveal costs almost nothing. What slows sites down is how the motion is built: headlines hidden until JavaScript loads, 3D bundles in the critical path, scroll handlers that hog the main thread, and animations that change layout. Each of those hits a different Core Web Vital.

Here is how motion breaks LCP, INP and CLS, and how to keep it in the green.

The three numbers Google measures

Google's Core Web Vitals are measured at the 75th percentile of real page loads, split by mobile and desktop.

Chart of Core Web Vitals thresholds for LCP, INP and CLS
Good, needs-improvement and poor bands for the three Core Web Vitals.
Metric Good Poor What it measures
LCP (Largest Contentful Paint) ≤ 2.5 s > 4 s When the main content appears
INP (Interaction to Next Paint) ≤ 200 ms > 500 ms How fast the page responds to taps, clicks, keys
CLS (Cumulative Layout Shift) ≤ 0.1 > 0.25 How much the layout jumps

Thresholds from web.dev's pages on LCP, INP and CLS. INP replaced First Input Delay as a Core Web Vital in March 2024.

How animation breaks each metric

LCP: the invisible headline

A classic motion mistake: the hero headline starts at opacity: 0 and fades in once GSAP loads. Chrome ignores elements at opacity 0 as LCP candidates, so your LCP is recorded only when the fade finishes. A 1.2-second intro fade can push LCP back by up to 1.2 seconds, on top of the time it takes the script to arrive.

3D heroes are the heavy version. Utsubo notes that on a Three.js hero the canvas is usually the LCP element, and that Three.js core alone is around 600 KB minified, passing 3 MB once helpers and a .glb model are added.

INP: the busy main thread

INP only counts clicks, taps and key presses. Scrolling and hovering are not measured. So a scroll animation doesn't hurt INP directly, but the JavaScript running it does: if your scroll handlers, smooth-scroll library and a WebGL render loop all compete for the main thread, the tap on "Add to cart" waits in line. Hon Tran calls INP the metric animation-heavy sites most often fail.

CLS: animating the wrong property

Animating height, width, top or margin moves other elements and counts as layout shift. Per web.dev's CLS guide, changes made with CSS transform do not. There is a trap here: shifts within 500 ms of a tap or click are excluded, but scrolling does not count as input. A scroll-triggered accordion that pushes content down counts against you in full.

Seven rules for website animation performance

  1. Animate transform and opacity only. Use translate instead of top/left, scale instead of width/height, clip-path for reveals. GSAP's x and y compile to transforms.
  2. Render the hero in HTML first. Headline visible at full opacity in the server HTML; animate secondary elements, or animate from a visible state.
  3. Lazy-load heavy motion. Load Three.js and big timelines after the load event or when they enter the viewport. Show a poster image until then.
  4. Reserve space. Set width/height or aspect-ratio on images, videos and canvases. Never animate height: 0 to auto; reserve a min-height.
  5. Run one animation loop. Drive Lenis and ScrollTrigger from a single requestAnimationFrame tick, and batch DOM reads before writes.
  6. Pause what users can't see. Stop WebGL loops off-screen with an IntersectionObserver. Use will-change only just before an animation, then reset it.
  7. Test on a mid-range Android. Throttle the CPU 4x in DevTools at minimum, and check a real device. Your M-series laptop will lie to you.

Rules 2 and 3 matter for rankings too: see animated website SEO. For scenes with real-time 3D, our guide to 3D website performance covers textures, Draco compression and draw calls.

What a motion audit looks like

When we audit an animated site, we test each animation against the three metrics rather than running one Lighthouse score.

Example motion audit report listing animations, the metric each affects and the fix
An illustrative audit layout: each animation, the metric it risks, severity and fix. Example data, not a client result.

Two measurement notes:

  • Lab vs field. As Hon Tran points out, Lighthouse reports Total Blocking Time, not real INP. Use the Performance panel to find long tasks over 50 ms, then confirm with field data.
  • Field data lags. Google's CrUX data uses the 75th percentile of real users over 28 days, so a fix shows up in Search Console weeks later. Log your own with the web-vitals library (onLCP, onINP, onCLS).

Speed and accessibility overlap

The fixes that make motion fast usually make it kinder. Honoring prefers-reduced-motion with end states instead of animations removes work from the main thread for those users. Our guide to accessible website animation covers the design side.

Questions people ask

Does GSAP hurt Core Web Vitals?

Not on its own. GSAP animating transforms is cheap. Problems come from hiding LCP content until it loads, or from running many scroll-linked timelines on one thread.

Does smooth scrolling slow down a website?

It can hurt INP if it runs its own animation loop alongside others. Use one shared loop and test on mid-range phones.

How do I check if animations are slowing my site?

Record a Performance trace in Chrome DevTools with 4x CPU throttling, look for long tasks over 50 ms, then compare with field data in Search Console.

Sources

LET’S OPEN A NEW TAB

What are you
thinking?

What’s on your mind?

This prepares an email to lab@asfari.studio. You review and send it from your email app.