After Webflow's acquisition of GSAP and the launch of Interactions with GSAP, the real question isn't "which one should I use?", it's "how much GSAP do I need?" Here's my practical decision framework.
April 12, 2026
.webp)
The conversation around GSAP versus Webflow interactions used to be straightforward: Webflow's built-in interactions for simple stuff, custom GSAP code for anything complex. Two separate tools, two separate workflows.
That changed fundamentally in October 2024, when Webflow acquired GreenSock, the company behind GSAP. And it changed again in April 2025, when GSAP version 3.13 dropped and the entire library became 100% free, including all the previously paid Club GSAP plugins like SplitText, MorphSVG, ScrollSmoother, and DrawSVG.
Then in July 2025, Webflow launched Interactions with GSAP, a completely new interaction system powered natively by the GSAP engine.
So the question isn't "GSAP or Webflow?" anymore. Webflow's native interactions ARE GSAP now. The real question is: how much GSAP do you need, and do you need the visual interface or custom code to get there?
The new system is a genuine step up from Classic Interactions. It includes a horizontal visual timeline where you can sequence animations with drag-and-drop control, easing previews, zoom, pan, and playback scrubbing. Built-in SplitText means you can animate individual characters, words, or lines without writing code. Staggers are handled natively. ScrollTrigger is integrated for scroll-based animations.
You get trigger types for click, hover, page load, scroll into view, and scroll position. Targeting works by ID, class, custom attributes, or CSS selectors. You can set conditional playback per breakpoint disabling animations on mobile while keeping them on desktop. Interaction presets let you save and reuse animations across the site. And FOUC (flash of unstyled content) prevention is handled automatically.
For a lot of projects especially marketing sites, landing pages, and content platforms this is all you need. The visual interface makes it fast to build, easy to iterate on, and accessible to team members who don't write JavaScript.
But the visual interface doesn't cover everything GSAP can do. There are scenarios where writing custom GSAP code gives you capabilities that the native Interactions panel can't match.
Complex timeline control is the biggest one. When you need multiple elements animating in precise coordination with play, pause, reverse, and timeScale controls — think interactive product demonstrations or storytelling sequences that respond to user input custom timelines give you the granular control that a visual interface can't replicate.
Advanced ScrollTrigger use cases are another. Pinning sections while content scrolls within them, scrubbing animations tied to scroll position so the user controls playback speed, snap-to-section effects these require more configuration than the native panel currently supports.
SVG morphing with MorphSVG, physics-based motion with the Inertia plugin, draggable elements with the Draggable plugin, and canvas or WebGL animations all require custom code. If you're building something that needs to feel genuinely immersive, animated illustrations, interactive data visualisations, scroll-driven narrative experiences — you need to write GSAP directly.
There's also a practical limitation: Interactions with GSAP doesn't yet work with Shared Libraries. If you're using Shared Libraries to maintain consistency across multiple sites (which I do for multi-brand work), interactions applied to components on a source site won't run on sites that install those components. For cross-site consistency with interactions, Classic Interactions or custom GSAP code are your options.
There's a lot of mythology around animation performance. Here's what's actually true.
The highest-performing animations run on the compositor thread completely off the main JavaScript thread. These are CSS and Web Animations API animations of transform, opacity, filter, and clip-path. They run at 60 or 120fps even when the main thread is blocked.
GSAP animations run on the main thread via requestAnimationFrame. When you're animating transform and opacity (which you should be, almost always), GSAP is smooth and fast. But it's technically vulnerable to jank if the main thread is blocked by heavy JavaScript execution.
In practice, the difference is negligible for most real-world use cases. GSAP's creator has benchmarked it as significantly faster than CSS transitions on certain devices, while Mozilla's documentation notes the performance gap is minimal in typical scenarios.
The practical rule: always animate transform and opacity (they're GPU-accelerated). Avoid animating top, left, width, or height — these trigger layout reflow, which is expensive. Use will-change: transform on elements you know will be animated. And use backface-visibility: hidden to prevent flickering on 3D transforms.
Here's how I decide which approach to use on a project.
I use Webflow's native Interactions with GSAP for hover effects, scroll-into-view reveals, page load animations, basic parallax, navbar and dropdown interactions, staggered text reveals, and quick prototyping. These cover probably 80% of the animation work on a typical client project.
I write custom GSAP code for complex multi-element sequences with precise timeline control, advanced ScrollTrigger with pinning and scrubbing, SVG morphing, draggable elements, canvas or WebGL animations, CMS-driven dynamic animations, and any site that needs Shared Library compatibility.
The hybrid approach works best. Native interactions handle the bulk of the work — the transitions, reveals, and hover states that every site needs. Custom GSAP code handles the 20% that requires advanced control. Both use the same underlying engine, so there's no performance penalty for mixing them.
If you want to use custom GSAP code, you can now enable the library directly from Webflow's project settings — no external CDN hosting needed. Toggle on the core GSAP library and check the boxes for whichever plugins you need (ScrollTrigger, SplitText, etc.). Everything loads from Webflow's own CDN.
For your custom code, add it to the page's Before Body custom code section, wrapped in a script tag and a DOMContentLoaded listener. Webflow auto-registers the plugins for you, so you don't need to call gsap.registerPlugin() manually.
If you want to go the CDN route instead (for example, to use a specific version), add script tags for gsap.min.js and your plugins from jsDelivr. Just make sure your custom code runs after the libraries have loaded.
Webflow is actively developing Interactions with GSAP, and more features are being ported from the GSAP library to the visual interface regularly. At Webflow Conf 2025, they previewed a future where the GSAP Timeline is fully available inside the Designer, with support for premium animations like 3D transforms and advanced scroll effects directly on the canvas.
For Webflow developers, the practical takeaway is this: learn the visual Interactions system for speed and accessibility, but also learn to write GSAP code for the projects that demand it. Having both skills means you can choose the right tool for each situation rather than being limited to one approach.
And since GSAP is now completely free, every plugin, every feature, there's no barrier to experimenting. Go build something that moves.
