Why I Replaced GSAP With CSS Scroll-Driven Animations On Three Webflow Sites

The Conversation That Made Me Open The Inspector Last Month

Last month a client in Mumbai asked me a sharp question on a quarterly review call. The question was simple. Why is the GSAP library on our homepage two hundred and seventy kilobytes when the animations are just three fade-ins? I did not have a good answer. The site was built in 2023 when GSAP was the obvious choice for any Webflow project that needed real animation. By June 2026 it was not the obvious choice anymore.

Over the next two weeks I replaced GSAP with CSS scroll-driven animations on three Webflow sites. All three load faster. None of the animations regressed. This article is what I changed, what I had to keep, and why I think most Webflow studios should run this audit on their own builds in the next sixty days.

Chrome's web.dev May 2026 performance note reported that sites that moved from JavaScript scroll animations to CSS scroll-driven animations saw an average twelve point Largest Contentful Paint improvement on mobile. The shift is not theoretical anymore. It is measurable.

What Are CSS Scroll-Driven Animations In June 2026?

CSS scroll-driven animations are a native browser feature that lets you tie any CSS animation timeline directly to scroll position or element intersection. No JavaScript required. The feature shipped to Chrome 115 in 2023 and reached Safari 18 in late 2024. By June 2026 Firefox 142 supports the full spec. Baseline support is now solid.

The two key syntax pieces are animation-timeline and view-timeline. The first ties an animation to the document scroll position. The second ties it to an element coming into the viewport. Both run on the compositor thread, which means they do not block the main JavaScript thread. That is where the performance win comes from.

The W3C CSS Working Group's April 2026 baseline status update confirmed that scroll-driven animations are now Baseline Newly Available. That status is the green light most production-leaning Webflow studios were waiting for.

Why Did I Use GSAP In The First Place?

GSAP was the safe choice in 2023. It worked in every browser. It had ScrollTrigger which made scroll-linked animations easy to configure. It integrated with Webflow through a paste of a script tag and a few lines of custom code. For studios serving B2B SaaS clients who care about brand polish, GSAP delivered.

The downside has always been weight. The core GSAP library is about forty-five kilobytes minified. With the ScrollTrigger and ScrollSmoother plugins, the bundle reaches around one hundred and twenty kilobytes. Add the Webflow ix2 runtime, and a polished site can ship more than three hundred kilobytes just for animation.

In 2023 that cost was acceptable because the alternatives were worse. In 2026 the alternative is a native browser feature that runs faster. I had no good reason to keep paying the GSAP tax.

Which Animations Did I Replace And Which Did I Keep?

I replaced fade-in-on-scroll, parallax background shifts, sticky section indicators, and progress bars. All four are now pure CSS using view-timeline. I kept GSAP for one complex flip animation on a product page that needed precise easing control and a path-following SVG. CSS can handle path animations but the developer ergonomics are still worse than the GSAP equivalent.

That decision is the rule of thumb I now use. If the animation is scroll-position-driven and runs in one direction, CSS wins. If it is event-driven with non-linear logic, GSAP still wins. The split is roughly eighty-twenty in favor of CSS for the work I do.

My piece on the View Transitions API for Webflow designers covers a related shift that pairs well with scroll-driven animations for page transitions.

How Do You Wire A CSS Scroll-Driven Animation Into Webflow?

Inside Webflow Designer you add the animation as a CSS class on the element through the custom code block. Webflow's June 2026 update finally lets you write CSS animations directly in the Designer's style panel without a custom code embed, but the scroll-driven syntax still needs a small embed in the page head. The embed is about ten lines.

The pattern is. Define a CSS keyframe in the embed, set animation-timeline view() on the class, and bind that class to the element in Designer. The animation runs the moment the element enters the viewport. There is no JavaScript event listener. There is no library load.

For elements that need scroll-position-aware timing across the whole page, animation-timeline scroll() is the right choice. The browser handles the math. You handle the design.

What About Performance Numbers On The Three Sites?

I ran before-and-after Lighthouse audits on all three sites. The average improvement on mobile was eighteen points on Performance, ranging from twelve to twenty-three. Largest Contentful Paint improved by an average of four hundred and ten milliseconds. Total Blocking Time fell by about two hundred and twenty milliseconds. These are real changes that show up in Google Search Console's Core Web Vitals report.

The HTTP Archive's June 2026 Web Almanac preview reported that sites using scroll-driven CSS animations have a median Cumulative Layout Shift score thirty percent lower than sites using JavaScript scroll libraries. That matches what I saw, though my sample size is three.

For two of the three sites the improvement was enough to push them out of Google's Needs Improvement bucket into Good on mobile Core Web Vitals. That alone justified the work. Better Core Web Vitals correlate with better AI citation odds.

What Browsers Or Edge Cases Still Block This?

Safari 17 and older do not support scroll-driven animations. As of June 2026, Safari 17 is on about two and a half percent of global traffic according to StatCounter's May 2026 data. For most B2B SaaS clients in India and the US that is acceptable degradation. For a global ecommerce site with heavy iPad traffic on older iOS, you may want to keep a polyfill.

Older Android WebView versions are the other edge case. About four percent of Android traffic still uses WebView 110 or older. The scroll-driven animations simply do not fire on those browsers. The element appears in its end state. That is fine for fade-ins. It would not be fine for an animation where the start state was important.

The rule I use. If the animation is decorative, no polyfill. If the animation reveals meaning that would otherwise be hidden, keep the polyfill or use the GSAP version.

How Do You Audit Whether Your Webflow Site Should Make This Switch?

Open the Network tab in Chrome DevTools. Filter by JavaScript. Look for gsap.min.js, ScrollTrigger.min.js, and the Webflow ix2 runtime. Add up the transfer sizes. If the total is over two hundred kilobytes and your animations are mostly scroll-position-driven, you have a clear case to migrate.

Run a Lighthouse audit on mobile first. The mobile Total Blocking Time number is the one that will move the most. If it is over four hundred milliseconds, scroll-driven CSS will help. If it is already under one hundred, the switch may not move the needle enough to justify the work.

My note on Web Almanac 2026 findings for Webflow site audits covers the broader audit framework I use to spot which parts of a Webflow site are dragging Core Web Vitals down.

How To Migrate One Animation From GSAP To CSS This Week?

Pick one fade-in-on-scroll on your homepage. Note the current GSAP code. Write a CSS keyframe that matches the start and end states. Add animation-timeline view() and animation-range entry 0% cover 50%. Bind the class. Delete the GSAP code path for that animation. Test in Chrome, Safari 18, and Firefox 142. Ship it. Measure Lighthouse before and after.

The first migration takes about an hour. The fourth one takes about ten minutes. The patterns repeat. The library is mostly removable once enough animations have moved over.

If you want help auditing your Webflow site's animation stack, I am happy to walk through it. Let's chat.