By Mehdi HassanMotion is the part of a website that founders notice first and question last. A site that moves feels expensive, so animation gets added everywhere: fading headlines, parallax images, counters that tick up, sections that slide in from the left. Some of it helps buyers understand the product. A lot of it just makes them wait.
This guide is the rulebook we use when we design and build animated marketing sites in Framer, Webflow and Next.js. It covers when motion earns its place, the patterns worth using, how to keep animation fast and accessible, which tools to pick, and how to plan motion so it survives into the build. Each section links to a deeper article if you need detail.
When does website animation help a marketing site?
Website animation helps when it carries information a static layout can't show. That usually means one of four jobs: explaining how a product works, guiding attention to the next step, confirming that an interaction happened, or showing that two states are connected. If you can't name the job, the animation is decoration, and decoration has to pay its own way in speed and attention.
Job | What it does | Good example | Bad version |
|---|---|---|---|
Explain | Shows a process or change over time | A workflow assembling step by step as you scroll | A product screenshot that just floats |
Guide | Directs the eye to what matters next | A subtle highlight on the active pricing plan | Everything pulsing for attention |
Feedback | Confirms an action worked | A button that presses and a form that shows success | A loader that runs longer than the task |
Continuity | Connects two states or pages | A card expanding into its detail view | Random slide-ins between unrelated sections |
The explain job is where motion pays off most for technical products. If your product transforms data, connects tools or automates a sequence, a short animated diagram can show at a glance what a paragraph struggles to explain. That's why motion sits close to the work of designing for complex products: it's a clarity tool first and a style tool second.
When does animation hurt a website?
Animation hurts when it delays content, competes with the message, slows interaction or makes people feel unwell. These are not matters of taste. Each has a measurable or well-documented cost: slower perceived load, worse Core Web Vitals, lower readability and accessibility failures.
- Delayed content. Headlines that fade in after a second make every visitor wait. If the largest element on screen starts invisible, it can also delay Largest Contentful Paint.
- Competing motion. Two or three things moving at once split attention. The eye goes to motion before text, so the headline loses.
- Janky interaction. Scroll handlers and heavy JavaScript animations can make clicks and taps feel slow, which shows up in Interaction to Next Paint (INP).
- Scroll hijacking. Locking or reshaping native scroll breaks expectations, especially on trackpads and phones.
- Vestibular triggers. Large parallax, zooms and spinning elements can cause dizziness or nausea for people with vestibular disorders.
INP is worth taking seriously. Field data for Q2 2026 from the Core Web Vitals technology report at corewebvitals.io shows only about two-thirds of Next.js sites pass INP, with a median around 236ms. Animation is rarely the only cause, but heavy scroll-driven JavaScript is a common contributor, and it's one you control.
Which website animation patterns are worth using?
Five patterns cover nearly everything a marketing site needs: hero motion, scroll-linked reveals, micro-interactions, page transitions and, occasionally, 3D. Each has its own trade-offs, and we've written a dedicated guide for each. Use the table as a map, then read the one that matches your decision.
Pattern | Use it for | Main risk | Read next |
|---|---|---|---|
Hero animation | Showing the product's core idea in the first screen | Delayed headline and LCP | |
Scroll animation | Step-by-step explanations and storytelling | Jank and INP | |
Micro-interactions | Feedback on buttons, forms, toggles and cards | Overdone, sluggish timing | |
Product demo motion | Explaining UI and workflows | Heavy files, unreadable detail | |
Page transitions | Continuity between pages | Complexity, slower navigation | |
Smooth scrolling | A softer scroll feel on long pages | Accessibility and control | |
3D and WebGL | Physical products and memorable brand moments | Cost, weight, battery |
Most startup sites need the first three and maybe the fourth. Page transitions, smooth scrolling and 3D are choices you should make on purpose, for a reason you can write in one sentence, rather than because a reference site had them.
How do you use motion to explain a product?
Motion explains a product when it shows cause and effect in the order a buyer needs to understand it. Start from the words: write the three-sentence explanation of how the product works, then animate exactly those three steps. If the animation shows more than the copy says, it's probably showing too much.
In practice, that means simplified UI rather than full screenshots, one focus point at a time, and a clear end state that holds long enough to read. A workflow tool might show a trigger, an action and a result. A data product might show messy inputs becoming a clean chart. The motion carries the 'then' between each step.
Write the explanation first
Three short sentences: what goes in, what happens, what comes out. This becomes the storyboard.
Simplify the UI
Redraw product screens with only the elements each step needs. Real screenshots are too dense to read in motion.
Storyboard the states
Design the start, middle and end frames as static designs. If the frames don't make sense alone, motion won't save them.
Choose the trigger
Autoplay for short loops, scroll for step-by-step stories, and hover or click for optional detail.
Hold the end state
Give the final frame time to be read, and make sure it works as a static image for reduced-motion users.
Format matters here: video, Lottie and coded animation have very different costs in weight, sharpness and editability. We compare them in GIF, video, Lottie or code for product demos.
How do you keep animation fast?
Keep animation fast by animating only transform and opacity, preferring CSS, loading heavy assets lazily and keeping JavaScript off the main thread during interaction. Browsers can animate transform and opacity on the compositor without recalculating layout. Animating width, height, top, left or box shadows forces layout or paint work on every frame, which is where jank comes from.
- Use CSS first. Transitions, keyframes and, where supported, CSS scroll-driven animations with animation-timeline run without JavaScript scroll listeners.
- Load libraries only where needed. If one section uses a scroll library, load it for that section rather than the whole site.
- Lazy-load heavy assets. Lottie files, videos and 3D scenes below the fold shouldn't compete with the hero for bandwidth.
- Avoid animating the LCP element in. Render the largest visible element immediately.
- Test on a mid-range phone. A MacBook hides problems that a typical Android device shows instantly.
Animation also shares the main thread with everything else on the page. If tag managers, chat widgets and analytics are already heavy, motion will feel worse. Our audit method for third-party scripts is often the first fix before touching any animation.
Why transform and opacity are cheap and everything else isn't
Each frame, the browser can run up to three stages: layout (where things are), paint (what pixels they have) and composite (stacking painted layers). Changing width, height, margin or top triggers layout, which then forces paint and composite for everything affected. Changing a color or shadow skips layout but still triggers paint.
Transform and opacity changes can often skip both and only re-composite an existing layer, which the GPU handles quickly. That's why a card that grows with transform: scale feels smooth while the same card growing with width stutters. The will-change property can promote an element to its own layer ahead of time, but use it sparingly, because every extra layer costs memory.
How do you make website animation accessible?
Make animation accessible by honoring prefers-reduced-motion, giving people a way to pause anything that moves on its own, and never relying on motion alone to convey information. These are WCAG concerns, not nice-to-haves. WCAG's Pause, Stop, Hide criterion covers content that moves automatically for more than five seconds, and Animation from Interactions addresses motion triggered by user actions.
- Reduced motion means a real alternative. Replace slides, zooms and parallax with instant changes or simple fades, rather than just speeding them up.
- Autoplaying loops need a pause control if they run longer than five seconds alongside other content.
- Keep focus visible during and after transitions, so keyboard users don't lose their place.
- Don't hide content until it animates in. If JavaScript fails, content that starts at opacity zero never appears.
The detailed implementation, including CSS media query patterns and how to handle libraries, is in our guide to accessible animation. For the wider basics of contrast, type and focus states, see accessible design basics.
Which tools should you use for website animation?
Use CSS for most motion, a JavaScript library like GSAP or Motion when you need sequencing or scroll choreography, Lottie for illustrated loops, and WebGL only for real 3D. Platform choice shapes this too: Framer has strong built-in interactions, Webflow has its own interaction system, and Next.js gives you the full code toolbox.
Tool | Best for | Watch out for |
|---|---|---|
CSS transitions and keyframes | Hover states, simple reveals, micro-interactions | Complex timelines get hard to manage |
CSS scroll-driven animations | Scroll-linked effects without JavaScript | Check current browser support and provide fallbacks |
GSAP | Complex timelines and scroll choreography | Bundle weight if loaded everywhere |
Motion (formerly Framer Motion) | React component animation, layout transitions | React-only patterns, careful with large lists |
Lottie | Illustrated loops from After Effects | File size and CPU on long, complex files |
Three.js, Spline, WebGL | Real 3D objects and scenes | Weight, battery and mobile fallbacks |
We use all of these and pick per project. The deeper verdict by use case is in GSAP vs Motion vs CSS. If you're moving between platforms, interactions are the part that rarely carries over cleanly, so plan for a rebuild rather than a copy.
How do you plan motion in a website project?
Plan motion during design, not after the build. Motion decided late gets cut, rushed or bolted on with a library that doubles the page weight. Motion decided early becomes part of the layout, the component system and the performance budget.
Start from the message
Decide what each section must say. Only then decide which sections need motion to say it better.
Define a motion system
Agree two or three durations, one or two easing curves and a rule for distance, the way you'd define a type scale.
Prototype the key moments
Prototype the hero and the main explainer in Figma or the target platform before building anything else.
Set a performance budget
Decide what can load on first paint and what waits. Heavy animation assets get lazy-loaded by default.
Design the reduced-motion version
Specify what each animated section looks like with motion off, so it's built, not forgotten.
Review on real devices
Check the build on a mid-range phone and with reduced motion on before launch.
A motion system should come out of the brand, not out of a trend. A calm financial product moves differently from a playful consumer app, and the easing curves should feel like the same company as the typography. We cover that translation in from brand identity to website.
Who maintains animation after launch?
Whoever edits the site after launch needs to be able to add content without breaking the motion. That's the hidden cost of heavy animation. If every new section needs a developer to wire up its scroll timeline, marketing either waits or ships unanimated sections that look out of place.
The fix is to build motion into reusable components: a reveal behavior that comes with every section type, an explainer block with configurable steps, hover states that live in the design system. Editors then pick blocks and get the motion for free. If your team expects to add pages often, plan for that at the start, and decide whether ongoing changes sit with a care plan or a retainer.
Animation libraries also need updates like any dependency. Pin versions, test motion after framework upgrades, and keep a short note of which pages use which library. It saves hours the next time someone asks why a section stopped animating.
