Why We Dropped Framer Motion from Client Projects

This article is a cross post from the Clear Horizon Digital Blog

Motivation:

Framer Motion is a big library that does lots of things. At the time of writing (v7.6.12), Framer will cost your bundle size 51.6kB minified & gzipped. Thats a pretty large number for a package which most teams are just using for basic animations.

A comparison with other libraries:

Let put that 51.6kb in perspective by looking at some related animation libraries:

• react-spring: 20.8kB
• react-move: 4.4kB
• react-transition-group: 4kB
• react-in-viewport: 2.2kB

Why should we care?

User Experience

The first and maybe most obvious reason - user experience. Any additions to your bundle size will have an adverse effect on load times, especially for users that are on slow networks or have reduced computing power (either via underpowered devices, or battery saving modes).

Adding to this - once under load, animation libraries like Framer are more liable to drop frames than when utilising a vanilla css transition animation.

Cost

Regardless of your chosen hosting provider, you (or your client) is going to be charged for bandwidth. Some providers have fairly generous free tiers while some have near-linear rates. Either way, sending an extra 50kB with every bundle fetch is going to be eating into your cloud budget.

Lets have a quick look at how it adds up for a fairly modest use-case, A website thats using Framer Motion and serving 5 unique users per minute:

5         *  51.6kB  =  258kB       per minute258kb     *  60      =  15480kB     per hour15480kb   *  24      =  371520kB    per day371520kb  *  30      =  11145600kB  per month

Thats over 10 Gigabytes of data transfer out to users per month for Framer alone. And thats assuming its been minified and gzipped. If it's not been gzipped, you're looking at closer to 35 Gigabytes

SEO

It used to be that getting tangible numbers on how a change will affect SEO was difficult, but these days we can just run a Lighthouse Report to get a quick analysis directly from Google.

Heres a before & after of one of our clients sites that was using Framer Motion for basic animation. Not dragging, gestures, path morphing - just simple fade ins & transforms.

It's worth noting that all of the same animations were recreated using react-transition-group and react-in-viewport for 6.4kB total bundle size.

The Alternatives:

Before looking at the alternatives its probably important to mention that Framer Motion solves some problems really well. Its incredible how easy the team at Framer have made it to accomplish complicated animation tasks with a simple declarative API.

Shared layouts, dragging components & path morphing to name but a few. The alternatives out there are often won't have the same developer experience when building complicated animations.

Having said that - 99% of frontends dont need complicated animations, they need a soft touch and smooth performance. Weve found that a combination of react-transition-group (4kB) and react-in-viewport (2.2kB) cover all of our requirements.

Lets have a look at a staggered fade-in animation - something that Framer really excels at, recreated with styled-components, react-transition-group and react-in-viewport.

// MyStaggeredContent.js{[1, 2, 3, 4, 5, 6].map((number, index) => (  <FadeIn key={`my-key-${number}`} delay={(index * 0.1).toFixed(1)}>    My Staggered Content  </FadeIn>))}// FadeIn.jsconst Wrapper = styled.div`  transition: ${props => props.duration}s;  transition-delay: ${props => props.delay}s;  opacity: ${props => props.inViewport ? '1' : '0.01' };`export const FadeIn = ({ delay = 0.5, duration = 0.4, children }) => {  const fadeComponentRef = useRef()  const { inViewport } = useInViewport(fadeComponentRef, {}, {disconnectOnLeave: true})  return (    <Wrapper      delay={delay}      duration={duration}      ref={fadeComponentRef}      inViewport={inViewport}    >      {children}    </Wrapper>  )}

Wrapping Up:

Theres a handful of problems that Framer Motion solves really well, but it is often used as a sledgehammer to a nail. For performance, SEO & cost - its often worth investigating simpler avenues.

Were excited to hear your take on React animation libraries - if you have a different take on it, leave a comment below!