GSAP in Webflow: Animations That Don't Kill Performance

GSAP in Webflow: where things stand

Webflow acquired GSAP (the GreenSock Animation Platform) in 2024. Webflow then announced that GSAP is free for everyone, whether they are Webflow customers or not.

Webflow also released a new version of its Interactions that is powered by GSAP. It brings features GSAP users know well, such as staggers, ScrollTrigger-style scroll animations and text splitting, into the visual interface. Webflow states it is available on all plans.

That changes the question. It used to be "do I need custom code?". Now it is "is the visual interaction enough, or do I need hand-written GSAP?". Licence terms and plugin availability can change, so check gsap.com and Webflow's documentation for the current position before you promise something to a client.

In practice, if you only need smooth content reveals, start with the native interactions. Add custom code when you reach their limits. The client then gets a site that is easier to edit, and you get fewer places where something can break.

Native interactions or custom GSAP code

I recommend choosing the simplest tool that does the job.

• Native Webflow interactions for fades, slides, staggers, hover and click states, and standard scroll reveals. They are visible to the client in the Designer and need no maintenance.
• Custom GSAP for sequences driven by logic or state, complex scroll-linked storytelling, pinned sections with several steps, canvas or SVG-heavy work, and anything that needs to read data or react to other scripts.

Custom code is more flexible and also more expensive to maintain. For anything beyond Webflow's native interactions I use GSAP, and I flag the heavy pages early because it changes how I structure the layout.

Animate only what the browser can animate cheaply

The most important performance rule is also the simplest. Browsers can animate transform (move, scale, rotate) and opacity on the compositor, usually without recalculating layout or repainting. Animating properties such as width, height, top, left, margin or box-shadow is far more expensive. See web.dev on compositor-only properties for the details.

• Move with x and y, not top and left. GSAP's x and y use transforms.
• Fake size changes with scale where the design allows it.
• Avoid animating blur, shadows and large filters on big elements. They are heavy, especially on phones.
• Use will-change sparingly. Applying it everywhere creates too many layers and uses memory.
• Avoid animating things that reflow the page, such as an accordion that changes height in a long list. Where you must, keep it local and short.

ScrollTrigger hygiene

Scroll-linked animation is where most slow Webflow sites get into trouble. The ScrollTrigger documentation is good. These are the habits I follow.

• Fewer triggers. Animate a group with one trigger and a stagger instead of one trigger per card.
• Prefer scrub on light things. Scrubbing a heavy element to the scroll position costs work on every scroll event.
• Be careful with pinning. Pinned sections add spacers and change the page height. Stacked or nested pins are a common source of bugs.
• Refresh at the right moment. Images, fonts and late-loading content change the layout. Trigger positions then drift. Call a refresh after the layout settles.
• Clean up. Kill triggers and tweens you no longer need, especially if you build them on interaction or resize.
• Use once: true or toggle actions for reveals that should only run the first time.

Also remember that in Webflow the Designer's preview and the published site can behave differently. Always test on the published or staging link.

Reduced motion and mobile

Some visitors get dizzy or distracted by motion. The prefers-reduced-motion setting lets them say so, and a good site listens.

• Check the setting and skip or shorten parallax, large movement and auto-playing sequences when it is on.
• Keep content visible. Reduced motion should mean fewer animations, not hidden text.
• Use gsap.matchMedia() to define one set of animations for motion-friendly users, another for reduced motion, and another for mobile. GSAP documents it in its matchMedia reference, and it cleans up automatically when the condition changes.

On mobile, assume less CPU and less patience. I usually simplify or remove pinned sections and heavy parallax on touch devices, and shorten durations. This is also a design question, so I like to agree it with the designer in the handoff. See my Figma to Webflow handoff checklist.

Lazy init: load and start animations only when needed

Animations below the fold do not need to be set up while the page is still loading.

• Load GSAP and plugins once, from a single place, with defer, and only on the pages that use them.
• Use IntersectionObserver to create timelines when a section is about to enter the viewport, instead of creating them all on load.
• Avoid layout work on load. Do not read and write layout properties in a loop while the page renders.
• Keep the first screen simple. A hero animation that delays the largest element hurts perceived speed and the LCP metric.

How to measure: Lighthouse, INP and a real phone

Do not guess. Measure before and after.

1. Run Lighthouse on the published page, in mobile mode, and look at Total Blocking Time and LCP.
2. Check INP, the metric that measures how quickly the page responds to clicks and taps. See web.dev on INP. Long scripts during an animation can make interactions feel stuck.
3. Record a Performance trace in Chrome DevTools while scrolling. Look for long tasks, layout recalculations and dropped frames.
4. Test on a real mid-range Android phone. It will show problems your laptop hides.
5. Compare with the animations disabled to see exactly what they cost.

Field data in Search Console's Core Web Vitals report shows how real visitors experience the site over time. For a wider checklist, see my Webflow SEO checklist.

Write the results down. If TBT or INP improves after you simplify the animations, you have an argument for the client and for the next project, and a baseline to compare against when something changes later.

Common mistakes that make Webflow animations slow

These are the problems I see most often when I take over a site with heavy motion.

1. Animating layout properties. Width, height and margin animations look fine on a desktop and stutter on a phone. Switch to transform and opacity.
2. Too many scroll triggers. Thirty separate triggers on one page add up. Group elements and stagger them.
3. Everything animates. When every element moves, nothing stands out. Choose the three or four moments that matter.
4. Large unoptimised media inside animated sections. A 4 MB image that fades in is still a 4 MB image. Compress and size it first.
5. No fallback. If the script fails or the user prefers reduced motion, the content must still be visible and readable. Never leave text at opacity 0 as the only state in the stylesheet without a plan for that case.
6. Testing only in the Designer. Preview does not reflect real loading, caching or a slower device.
7. Loading several animation libraries. One animation system per site is easier to keep fast and to hand over.

None of these are exotic. A short review against this list usually finds most of the problems on a slow page, and fixing them costs far less than rebuilding the animations.

My take: motion that supports the brand

I have been designing and building in Webflow since 2018 and I use GSAP for work that goes beyond native interactions. The pattern I trust is restraint. On Stone Hedge Capital, an investor site designed by Boldhuman, the brief called for a conservative, mature feel, so I built it with restrained, purposeful animation. On Big Moe Watches, a catalogue of more than 1,100 luxury watches, motion and typography were there to match a premium product while the catalogue stayed easy to browse.

The point is that animation is part of the brand, not decoration on top of it. A calm brand needs calm motion. A premium catalogue needs motion that never gets between the buyer and the product. If you want to plan the motion for a project, write one sentence per animation and tell me what should happen on mobile. Send me the design and I will tell you which parts should be native and which need GSAP.

FAQ

Written byPeter CekanakDesigner & Webflow developer · white-label partner for agencies

I design and build Webflow sites for agencies and startups since 2018 — Client-First, GSAP, CMS and AI automations. Sites I built helped a client to a $10M exit and tripled demo requests for a SaaS.

Webflow Certified ExpertRelume ExpertClient-First