There is a moment in most projects where somebody says the site feels a bit static. The usual answer is to add movement: things sliding in as you scroll, numbers counting up, a headline assembling itself letter by letter.
Some of that helps. Most of it costs the visitor time and gives nothing back.
The honest test
Motion earns its place when it explains something that would otherwise be a jump cut.
A panel that slides out from the button that opened it tells you where it came from and where it will go back to. A row that fades as it is removed tells you the removal happened, so you do not wonder whether you clicked. A control that shifts slightly under the pointer tells you it is a control.
Compare that with a paragraph that fades in as you scroll past it. It explains nothing. The reader already knows where the text came from — they scrolled to it. The only thing the animation adds is a delay between arriving and being able to read.
Duration is a budget
Anything a person is waiting on should be quick enough not to be noticed: fast enough that it reads as a response rather than a performance. Something happening on its own — a notification arriving, a diagram drawing itself once — can take longer, because nobody is standing still while it finishes.
The mistake is spending the first budget as though it were the second. A menu that takes half a second to open is slow four times a minute for as long as the site exists.
And a stagger multiplies the cost. Six items at a tenth of a second each is over half a second before the last one is readable, every time that section scrolls into view.
Reduced motion is not a niche
Operating systems have a setting for this, people who need it have it switched on, and it is one media query.
Worth knowing: if the base style is the hidden state and only the animation reveals it, disabling animation can leave the content permanently invisible. The base has to be the finished state, with motion as the thing that arrives at it — not the thing that unlocks it.