Loading tutorials…
Loading tutorials…
Framer is famous for animations — and just as famous for the sites that go from 90 PageSpeed score to 30 after a marketing team gets enthusiastic with motion. This walks the animation patterns that look great AND keep your site fast.
Who this is forFramer site owners adding animations who care about Core Web Vitals. If you've added 3-5 motion effects and your mobile PageSpeed score dropped 20+ points, this is the corrective playbook.
What you'll need
Step 1
Run PageSpeed Insights on every key page. Record the mobile + desktop scores. You can't measure damage if you don't measure baseline.
Open pagespeed.web.dev. Paste your live URL. Run for both mobile and desktop.
Record: Performance score, LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), TBT (Total Blocking Time).
Aim for: Performance 80+, LCP under 2.5s, CLS under 0.1, TBT under 200ms. These are the Core Web Vitals "Good" thresholds.
Save these numbers in a doc. After every batch of animation additions, re-run and compare. If any metric drops more than 10 points, you broke something.
Step 2
Framer offers: Hover, Press, Scroll, Page Load, Variant transitions. Each has a performance profile.
Hover and Press: low cost. Always GPU-accelerated. Use freely.
Page Load (initial animation when page renders): medium cost. Each element animating in adds 50-100ms to "perceived TTI." 3-5 page load animations max.
Scroll-linked (parallax, opacity-fade-on-scroll): high cost. Browser has to recalculate styles on every scroll event. Use sparingly — 1-2 elements per page.
Variant transitions (state changes triggered by clicks): low cost if animating transform/opacity, high cost if animating size/position.
Marquee (continuous scrolling text/logos): medium cost. Keep to 1 per page, pause on hover.
Step 3
GPU-accelerated properties: transform (translate, scale, rotate) and opacity. Everything else triggers layout.
When designing an animation, ask: what property am I changing?
Good: translate (translateX, translateY), scale, rotate, opacity. These run on the GPU — basically free.
Bad: top, left, right, bottom, width, height, margin, padding. These force the browser to recalculate layout for every frame. 30-60% performance hit per animation.
Framer's "Move" animation can use either translate or position depending on how you set it up. Use the Transform → X/Y settings, not the absolute Position settings.
For a slide-in effect: animate translateX from -100 to 0 (good). Not "position left from -100px to 0" (bad).
Step 4
Scroll-linked animations are expensive. Use them once or twice on the hero, never on every section.
Common pattern: hero text fades in + parallax background image. This is fine — both above the fold.
Bad pattern: every section has its own scroll-triggered animation. The browser is constantly re-calculating styles. Mobile scroll feels janky.
For "fade in on scroll" patterns: use a single trigger that animates once, then disconnects. Framer's "Appear" animation does this correctly.
Avoid pinning sections to the viewport (sticky positioning + scroll animation). Performance cliff on mobile.
Step 5
Lottie animations (.json files) and background videos add real KB. Compress aggressively or replace.
Lottie files: aim for under 100KB per file. Compress at lottiefiles.com/compress.
Background videos: keep under 3MB. Use MP4 (H.264) for compatibility, WebM for size. Always provide both as fallback.
For autoplay background video: muted, looping, playsinline. Otherwise iOS blocks autoplay.
Alternative to background video: animated GIF (good for under 5 seconds), CSS gradient animation (good for abstract effects), or static image with subtle scroll effect.
Always set width/height on video and Lottie containers to prevent CLS (Cumulative Layout Shift) when they load.
Step 6
Run PageSpeed Insights after each batch of animations. Compare to baseline. If any metric dropped 10+ points, revert the last change.
After adding 2-3 animations, re-run PageSpeed.
Compare each metric to baseline. Performance score, LCP, CLS, TBT.
If Performance dropped 10+ points: identify which animation caused it (often the scroll-linked one). Replace with a simpler version (e.g., fade instead of parallax).
If CLS spiked: an animation is moving an element that affects layout. Add explicit width/height to the element's container.
Don't batch animations without checkpoints. Adding 8 animations at once means you don't know which one broke speed.
Common mistakes
Animating width, height, top, left (instead of transform)
What goes wrong: Browser repaints on every frame. Mobile scroll stutters. PageSpeed Performance drops 20-40 points. LCP slips past 4 seconds.
How to avoid: Refactor every animation to use Transform → translateX/Y or scale. Animate opacity for fades. Never animate size/position directly.
Too many scroll-linked animations
What goes wrong: Browser recalculates styles on every scroll event. Mobile scroll feels janky. Users perceive the site as broken. Bounce rate climbs 15-30%.
How to avoid: Limit scroll-linked animations to 1-2 per page, both above the fold. Below-the-fold elements should use "Appear" (one-shot) animations, not scroll-linked.
Background video without compression
What goes wrong: Hero loads a 12MB MP4. Mobile LCP hits 6+ seconds. PageSpeed score crashes to 30. Users on slower connections never see the hero.
How to avoid: Compress video to under 3MB. Use H.264 MP4. Set poster image so something shows while video loads. Consider replacing with animated CSS or Lottie under 100KB.
Lottie animations not lazy-loaded
What goes wrong: All Lottie animations on the page load on initial render, including ones below the fold. Page weight balloons. Lottie player JS blocks rendering.
How to avoid: Use Framer's "Appear" animation to trigger Lottie load only when element enters viewport. Compress Lotties to under 100KB. Replace decorative Lotties with static SVG.
Animating the LCP element (hero image, hero text)
What goes wrong: Largest Contentful Paint can't measure correctly because the LCP element is animating. PageSpeed reports LCP as 4-5s even when it visually loads in 1s. Google still penalizes.
How to avoid: Don't animate the LCP element on page load. Let it render first, animate everything ELSE around it. Use Framer's preview to see which element is the LCP target.
No reduced-motion fallback
What goes wrong: Users with prefers-reduced-motion (motion sensitivity, vestibular disorders) still see every animation. Accessibility audit fails. Some users physically can't use the site.
How to avoid: Framer's newer animations respect prefers-reduced-motion automatically. For Custom Code animations, wrap in @media (prefers-reduced-motion: reduce) media query and disable transitions.
Recap
Done — what's next
How to set up a Framer site end-to-end
Read the next tutorial
Hand it off
Animation discipline is one of the highest-skill areas in Framer work — easy to over-do, hard to clean up. A specialist who's shipped 20+ Framer sites knows which patterns work and which kill performance. Typically $200-500/mo for ongoing site optimization at $14-16/hr.
See specialist rates
Rule of thumb: 5-10 distinct animations on a homepage, 2-4 per inner page. Distinct = different motion patterns, not different elements doing the same motion. A 10-logo marquee counts as 1 animation. 4 fade-ins on different sections count as 1 animation type. The number of TRIGGERS matters more than the number of elements.
Not directly — Google sees the HTML, not the motion. But animations that hurt LCP, CLS, or INP (Core Web Vitals) hurt rankings. Indirect effect: an animation that slows mobile loading from 2s to 4s drops you 10-20 positions on mobile-first ranking.
Page Load = element animates in when the page first renders. Appear = element animates in when it enters the viewport (scroll-triggered). Page Load is fine in moderation (3-5 elements). Appear is the right choice for below-the-fold elements you want to animate without scroll-linked cost.
Almost always: heavy images, unoptimized video, or too many animations. Mobile CPU is 4-10x slower than desktop. Mobile network is often slower. If desktop is 90 and mobile is 50, optimize for mobile by: compressing images further, replacing video with image, removing 2-3 animations, lazy-loading below-the-fold.
Yes, but you usually shouldn't. Framer's native motion (under the hood, it's a fork of Framer Motion) is optimized for Framer sites. Adding GSAP via Custom Code adds 50-100KB and bypasses Framer's optimizations. Use native first — only add third-party libraries when you've hit a wall Framer can't clear.
Framer
Framer feels like Figma until you hit publish — then it suddenly behaves like a real CMS. This walks the path from empty project to a live custom domain, including the breakpoint and domain-connect steps that trip up most first-time builders.
Framer
Framer ships fast HTML out of the box. Then a marketing team adds images, animations, fonts, and pixels — and the mobile PageSpeed score collapses. This is the diagnostic sequence specialists run when a Framer site loses speed.
Framer
Framer's killer feature for power users: write real React, paste it in, and use it like any native component. But this is also where most Framer sites turn into maintenance nightmares. This walks the right way to set up code components.
Framer
Framer is gorgeous and accessible — until you hit the wall where every change costs you a day. This is the honest framework: when the time cost of DIY exceeds the cost of hiring, and how to tell which side you're on.
Webflow
Webflow doesn't have a native GA4 field anymore — every install goes through Custom Code. Most DIY setups end up double-counting from the webflow.io staging subdomain or missing events from form submits. This walks the install + the filters that fix both.