By Mehdi HassanWe ship all three on client projects, sometimes on the same site, so this isn't a fan comparison. Each tool is the best answer for a different kind of motion. The real mistake is picking one for everything, usually the heaviest. This comparison sits inside our website animation guide.
GSAP vs Framer Motion vs CSS: what's the difference?
CSS animation is built into the browser, Motion is a JavaScript animation library designed around React components, and GSAP is a framework-agnostic JavaScript library built around timelines. Motion was called Framer Motion until it became an independent project and widened beyond React. GSAP is maintained by the GreenSock team, now part of Webflow, and its plugins, including ScrollTrigger, are free to use.
CSS | Motion | GSAP | |
|---|---|---|---|
What it is | Native transitions, keyframes, scroll timelines | Declarative animation library, React-first | Imperative timeline library, any framework |
JavaScript cost | None | Moderate, tree-shakable | Moderate, plus plugins |
Best at | Hover, focus, simple reveals | State changes, exit and layout animation | Sequenced timelines, scroll choreography |
Scroll effects | animation-timeline, IntersectionObserver | useScroll and scroll-linked values | ScrollTrigger, pinning, scrubbing |
Learning curve | Low | Low for React developers | Medium |
Works without React | Yes | Yes, with its vanilla API | Yes |
Ideal team | Anyone | React or Next.js teams | Motion-heavy builds, any stack |
When is CSS the best web animation tool?
CSS is the best tool for hover states, focus styles, toggles, simple reveals and any effect that only needs a start and an end. It costs no JavaScript, runs well on the compositor when you animate transform and opacity, and is easy for any developer to maintain. Most of what makes a site feel polished lives here.
CSS also covers more than it used to. Scroll-driven animations with animation-timeline handle progress bars and scroll-linked reveals without a scroll listener, and the View Transitions API handles some page and state transitions natively. Where browser support isn't universal, treat these as enhancements with static fallbacks.
Where CSS gets painful is sequencing. Coordinating ten elements with staggered delays, reversing mid-way, or reacting to complex state quickly turns into a tangle of custom properties and class toggles. That's the point to reach for a library. The details of keeping CSS scroll effects cheap are in scroll animation performance.
When should you use Motion (formerly Framer Motion)?
Use Motion when animation follows React state: elements entering and leaving, layout changes, shared elements and gestures. Its declarative props make 'animate when this changes' natural, and its exit and layout animations handle things that are genuinely hard in CSS, like animating an element as it's removed or smoothly reflowing a list.
Pros
- Declarative API that reads like the rest of a React component
- Exit animations and layout transitions handled for you
- Gesture support for drag, hover and tap
- Spring physics that make UI feel responsive
Cons
- Most natural inside React, less so elsewhere
- Long, choreographed scroll stories are easier in GSAP
- Many animated components at once can add up on the main thread
- Layout animations need care to avoid surprise reflows
Motion is our default for product-style UI on marketing sites built in Next.js: tabbed feature explorers, expanding cards, animated pricing toggles and micro-interactions that depend on state.
When should you use GSAP?
Use GSAP for long, precisely sequenced timelines and scroll-driven storytelling, especially with pinned or scrubbed sections. Its timeline model lets you sequence dozens of tweens, control them as one unit, and tie them to scroll with ScrollTrigger. It's also framework-agnostic, which helps when you work across Next.js, Webflow and plain HTML.
Pros
- Timelines make complex sequences readable and controllable
- ScrollTrigger handles pinning, scrubbing and snapping
- Works in any framework or none
- Mature, well-documented and widely used
Cons
- Imperative style needs careful cleanup in React
- Easy to overuse pinning, which hurts mobile scrolling
- Adds weight if loaded globally for one effect
- Animating layout properties with it is still expensive
GSAP is also a common choice in Webflow builds through custom code, which matters if you're moving a site between platforms. Interactions rarely translate one to one; we cover that in Webflow interactions to Framer.
Which should you use for website animation, by use case?
Pick by the effect, not by preference. The table below is how we decide on real projects. If a page needs effects from more than one row, use CSS for the simple ones and one library for the complex ones, rather than mixing both libraries.
Use case | Our pick | Why |
|---|---|---|
Button, link and card hovers | CSS | No JavaScript needed, easy to maintain |
Reveal sections on scroll | CSS with IntersectionObserver or animation-timeline | Cheap, progressive enhancement |
Tabs, accordions, toggles in React | Motion | Follows state, handles exit animations |
Shared element and layout transitions | Motion | Layout animation is its strength |
Pinned, scrubbed scroll story | GSAP with ScrollTrigger | Timeline control and pinning |
Hero sequence with many steps | GSAP | Precise sequencing and easing |
Animated product explainer in Next.js | Motion or GSAP | Motion for state-driven, GSAP for timeline-driven |
Page transitions | View Transitions API first | Native, lighter, see below |
For page transitions specifically, the browser's View Transitions API is now often the lightest option, with libraries as a fallback. We weigh that in page transitions on marketing sites.
For example, suppose one landing page needs three kinds of motion
For example, suppose a landing page has hover states on every card, a tabbed feature explorer, and a pinned 'how it works' section where four steps animate as you scroll.
The hovers are plain CSS. The tabbed explorer uses Motion, because each tab change is a React state change with content entering and exiting. The pinned section could use GSAP, but since Motion is already loaded, we'd first try Motion's scroll utilities; only if the choreography needs precise pinning and scrubbing would we add GSAP, scoped to that one component. The result is one library on the page, not two, and zero JavaScript for the most common interactions.
What about performance and accessibility?
All three can be fast and accessible, and all three can be slow and inaccessible; the property you animate and the reduced-motion handling matter more than the library. Animate transform and opacity, avoid layout properties, scope libraries to the components that use them, and kill animations on unmount in React.
- Reduced motion: CSS uses the prefers-reduced-motion media query; Motion and GSAP can read the same preference and skip or simplify animation. See accessible animation.
- Core Web Vitals: heavy JavaScript on the main thread hurts INP. Platform-specific fixes are in Core Web Vitals for Framer, Webflow and Next.js.
- Focus: animated components still need visible focus states. See accessible design basics.
