Add it where it explains something, and cut it everywhere else. Animation that shows a state change or guides attention helps people understand your interface. Animation added for polish usually costs you speed, accessibility, and attention, and returns nothing measurable.
This is one of the most common disagreements we referee on a project. A designer wants motion because it makes the work feel alive. A founder wants speed because the last site was slow. Both are right, and the argument only resolves when you decide what each animation is for.
Our position is simple and we will defend it. Every animation on a page should be doing a job you can name in one sentence. If you cannot name the job, delete it. That single rule settles most of these debates in about a minute.
It communicates change. Nielsen Norman Group describes animation in interfaces as drawing attention to and explaining changes on the page, such as a change in the state of an element, content being revealed or hidden, or a transition to another area of content. Those are jobs, not decoration.
Nielsen Norman Group is also specific about the character of good animation, describing it as needing to be unobtrusive, brief, and subtle, and useful for feedback, state changes, navigation metaphors, and strengthening signifiers. Read that list closely and notice what is missing. There is no entry for making the hero look impressive.
There is a useful detail about how motion grabs attention. NN/g notes that elements which slide in or shift position attract attention faster than elements that slowly fade into place, and that motion in a person's peripheral vision triggers a stronger response than motion where they are already looking. That is a tool with two edges. It means you can direct someone's eye, and it means you can also steal their focus from the thing you wanted them to read.
Shorter than most designers instinctively choose. Nielsen Norman Group recommends that most animations fall between 100 and 500 milliseconds, depending on their complexity and the distance traveled. Simple feedback like a toggle or a checkbox should sit at roughly 100 milliseconds, so the change feels like direct manipulation.
For bigger changes such as a modal appearing, NN/g suggests 200 to 300 milliseconds is appropriate. It also warns that at 500 milliseconds animations start to feel like a real drag and become cumbersome and annoying, and it frames the goal as finding the shortest duration that is not jarring.
One refinement we use constantly is asymmetry. NN/g points out that a popup might take 300 milliseconds to appear but only 200 to 250 milliseconds to disappear. Entrances can afford to be graceful. Exits should get out of the way, because the user has already decided to move on.
If you take one number away, take 100 milliseconds for feedback. NN/g's guidance is that visual feedback confirming an element is interactive needs to appear within about 0.1 seconds to preserve the feeling of an instant response.
When it delays the thing the visitor came for. A hero that reveals its headline over two seconds, a page that will not show content until a scroll sequence finishes, or a form that animates each field into place all add friction to the exact moment you were trying to make smooth.
NN/g is unusually direct on two points here. It says never to include a permanently moving animation on a page, because it makes concentrating on text very hard. It also argues animation rarely has a place on a homepage, since animation demands attention and a homepage already has multiple elements competing for it.
We see the conversion damage most often on long scroll pages where every section fades in on entry. Individually each fade is tasteful. Together they mean that a visitor skimming quickly, which is most visitors, sees blank space where content should be. Scroll faster than the animation and the page appears empty.
Our average conversion lift across projects is 3.5x, and getting there is mostly about removing friction rather than adding delight. When we cut animation from a page, it is almost always because the animation was standing between someone and the information they wanted.
It can, in two specific ways. Animation that runs on the main thread competes with everything else the browser needs to do, which shows up in Interaction to Next Paint. Animation that moves layout rather than pixels shows up in Cumulative Layout Shift.
The INP thresholds are concrete. Google's documentation puts good INP at 200 milliseconds or below, needs improvement between 200 and 500 milliseconds, and poor above 500 milliseconds, assessed at the 75th percentile. It lists long JavaScript tasks and expensive rendering work, including complex layouts and large DOM sizes, as the usual causes.
The 2025 Web Almanac, drawing on HTTP Archive and Chrome UX Report data from July 2025, found 77% of mobile pages achieve good INP while only 48% of mobile origins pass all three Core Web Vitals. Animation-heavy sites tend to be on the wrong side of that split, usually because a large animation library is doing work on every scroll event.
The technical fix is well established. Animate transform and opacity, which the browser can handle without recalculating layout, and avoid animating properties that trigger layout like width, height, top, and left. If your animation changes layout during load, it also risks CLS, and Google's good threshold there is 0.1 or less. We wrote up that metric in detail in our piece on Cumulative Layout Shift.
This is the part teams skip and it is not optional. Motion causes real physical symptoms for people with vestibular disorders. The W3C's guidance for WCAG success criterion 2.3.3 describes triggered reactions including nausea, migraine headaches, and potentially needing bed rest to recover.
There are two relevant criteria. Success criterion 2.2.2, Pause Stop Hide, is Level A, and it requires a way to pause, stop, or hide any moving, blinking, or scrolling content that starts automatically, lasts more than five seconds, and appears alongside other content, unless the movement is essential. That is the baseline conformance level, not an advanced one.
Success criterion 2.3.3, Animation from Interactions, is Level AAA and requires that motion animation triggered by interaction can be disabled unless it is essential. The W3C lists respecting the prefers-reduced-motion CSS media query as a sufficient technique for meeting it.
Supporting prefers-reduced-motion takes a few lines of CSS and removes an entire class of harm. We treat it as a default on every build rather than an accessibility extra, and we cover the wider standard in our guide to WCAG accessibility.
A short list. Hover and focus states so interactive elements announce themselves. Transitions on accordions and dropdowns so opening and closing make spatial sense. Loading and submitting states so people know something happened. And occasionally one deliberate motion moment where the brand genuinely needs personality.
That last category is where we allow ourselves something expressive, and we allow exactly one per page. A single well-built moment on a hero or a key product explanation reads as craft. The same effect on nine sections reads as a template.
Tooling matters less than restraint. Webflow's native interactions cover most of what business sites need without adding a library. GSAP is excellent when you need timeline control, Rive and Lottie are good for lightweight vector motion, and all of them can be abused. We go through the practical setup in our notes on Webflow animations and interactions.
We hold an average PageSpeed score of 98 across our builds, and on Axis Align we shipped a 98 score with a 0.7 second load. Neither of those numbers required a motionless site. They required animation that was cheap to render and short enough not to get in the way.
Mostly they hurt, and this is our least popular opinion. Scroll-triggered reveals became a default rather than a decision, and their most common effect is to hide content from fast scrollers while adding work on every scroll event. They are a cost paid on every visit.
If you keep them, two rules make them survivable. Trigger them early so content is visible before it reaches the middle of the viewport, and keep them fast enough to finish well inside NN/g's 100 to 500 millisecond range. A reveal that takes 800 milliseconds is a reveal your fastest visitors will never see completed.
Also reserve space for whatever is animating in. If the element is not in the layout until it appears, you are shifting the page while someone is reading it, which is both a poor experience and a metric problem.
Remove it and see if anything gets worse. Turn the animation off, run the page in front of someone who has not seen it, and watch whether they misunderstand anything. If comprehension is unchanged, the animation was decoration and the page is now faster.
Measure the performance side properly at the same time. Check INP and CLS in PageSpeed Insights before and after, and profile the page in Chrome DevTools with throttling on to see what your animation costs on a mid-range phone rather than a developer laptop.
For anything genuinely contested, run a real test. A page with a heavy hero animation against the same page with a static hero will answer the question for your specific audience better than any general principle, including ours. We are happy to be proved wrong by data on a specific site, which is different from being talked out of a default.
Audit the animation you already have. Walk your key pages and write down what each animation is communicating. Delete anything you cannot describe in a sentence, shorten anything over 500 milliseconds, switch layout-shifting animations to transform and opacity, and add a prefers-reduced-motion rule if you do not have one.
Then keep one thing that shows craft. We are not arguing for sterile pages, and a site with no motion at all feels cheap in a way that costs trust. The argument is for intent, where every moving thing has a reason and nothing moves while someone is trying to read.
If you have a site that feels slow and you suspect the animation is why, send it over and we will tell you what is costing you and what is worth keeping. Let's talk, over at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.