Does animation make a Webflow site slow?

The honest version

A site with real motion will almost always score lower than the same site with none. Anyone who tells you otherwise is selling something. The question worth asking is not whether motion costs anything, it is whether what you get back is worth what you paid.

BIKE is an English language institute in Uruguay, and it is a good test case because it is not a restrained build. It has a custom preloader that draws before the first scroll, GSAP reveals pacing the whole page, and an interactive 3D bicycle sitting on the 404. It scores 81 on Lighthouse performance, 100 on SEO and 90 on accessibility.

81 is a fine score. It is not a 98, and pretending otherwise would be dishonest. But that number buys a site that feels like it is going somewhere, for a business whose whole promise is that you will get better at something over time. A static page would have undersold that.

What actually makes a Webflow site slow

In practice, the animation library is rarely the villain. The things that show up again and again are duller than that:

• Uncompressed images. A single hero photograph exported at full resolution outweighs every script on the page.
• Fonts loaded badly. Four weights when you use two, no preload, no swap.
• Third-party scripts. Chat widgets, heat maps, three analytics tools, a cookie banner from 2019. Each one is someone else's code running on your critical path.
• Everything animating. Not the fact that things animate, but the fact that nothing was left alone.

Notice that only the last one is about motion, and even then the problem is not GSAP. It is the absence of a decision about where motion belongs.

Where the budget goes

Treat motion like any other budget. You have a finite amount to spend and spending it evenly is the same as spending it badly.

On BIKE the spend was concentrated in three places: the preloader, because it sets the tone before anything else can; the reveals down the page, because the brand is about progress and the page should feel like it is moving forward; and the 404, because a dead end was an opportunity to be memorable rather than apologetic.

Everything else is still. Forms do not bounce. Cards do not tilt. The courses section, which is the part people actually came to read, gets out of the way and lets them read it.

Three questions before you animate something

These are the ones I ask on every build, and they kill most animation ideas before they cost anything:

• Does this help someone understand the page? Motion that shows a relationship between two things earns its place. Motion that decorates does not.
• Would a first-time visitor notice it missing? If not, that is a strong argument for cutting it.
• Does it delay the thing they came for? Anything between a visitor and the content they want had better be short and deliberate.

The part nobody mentions

Motion has a maintenance cost that never shows up in a Lighthouse report. Every animated element is something that can break when a client adds a fifth item to a four-item grid, or pastes a paragraph twice as long as the placeholder.

This is the real reason to be selective, and it is why I build motion against the CMS structure rather than against a specific set of content. A reveal that assumes three cards will embarrass you the day someone adds a fourth.

So: does animation make a Webflow site slow?

A bit. Less than your images do. And if the motion is doing real work, carrying a brand, explaining a structure, making a dead end feel intentional, then a few points of Lighthouse is a reasonable price.

What is not reasonable is paying that price for motion nobody asked for on a page nobody can read.