- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
Used once or twice it directs the eye; applied to every section it turns reading into a sequence of short waits.
Scroll animation: motion that helps the reader, and motion that delays them
Scroll animations reveal an element as it comes into view — a heading fading up, a column sliding in, a figure counting to its value. Used once or twice on a page they draw attention to something worth attending to. Applied to every section, they turn reading into a sequence of short waits.
The distinction is whether the motion is doing work. An animation that directs the eye to the thing the visitor should read next is helping. An animation applied because the builder offered a dropdown of them is a delay dressed as design.
What to animate, and what to leave alone
| Element | Reasonable | Why |
|---|---|---|
| A single key statistic or claim | Yes, once | Motion earns attention where attention is the point |
| A row of cards | A short stagger at most | Sequential reveal reads as order; a long one reads as waiting |
| Body copy | No | Text that fades in is text that cannot be read yet |
| Navigation and buttons | No | Anything interactive should be available the moment it is visible |
| Form fields | No | Motion during input is disruptive and can cost a tap |
| The first screen | No | Animating what the visitor is waiting for delays the page appearing |
The last row is the one people get wrong most often. A hero that fades in over a second makes the page feel slower than it is, and on a slow connection the animation and the load compete, producing a first screen that arrives twice — once blank, once faded.
Timing, and the reason short is better
Animations that read as responsive are short: a fraction of a second, not a full one. Anything longer is perceived as the interface being slow rather than as an effect, and the effect is not what the visitor came for.
Trigger the animation before the element is fully in view, so it has finished by the time the reader arrives at it. An element that begins animating only once it is centred is an element the reader watches instead of reads. And never animate on every pass — an element that re-plays each time it scrolls back into view is actively irritating on a long page.
The costs
- Weight. Most builders implement this with a general-purpose animation library, loaded whether one element uses it or fifty. That is a real cost against what a page speed score measures, and it is worth checking what a single fade is actually pulling in.
- Jank on modest devices. Animations that move layout rather than transforming an element are expensive to render, and the phones that struggle are the ones your visitors are most likely holding.
- Interaction with deferred images. An animation triggering on visibility and an image loading on visibility can arrive in either order, producing an element that animates before its content exists — worth checking alongside lazy loading funnel images.
- Layout shift. An element that starts offset and moves into place can be recorded as movement, which is precisely what the measurement penalises.
- Compounding. A page with a background video, a stagger on every section and a parallax hero is slow for three reasons at once — see a section background video for the heaviest of them.
Accessibility, which is also a usability point
Some people experience motion as unpleasant or disorienting, and browsers expose a preference for reduced motion. Respecting it is straightforward and it is not only a courtesy: the same setting is commonly used by people on modest hardware who simply want the page to be still.
Where a builder does not respect that preference automatically, it is one of the few things genuinely worth adding through code in the page header — and it is a much better use of that box than most of what ends up in it.
Where it goes wrong across widths
An animation tuned to a desktop layout behaves differently once columns stack. A stagger across three columns becomes a vertical queue on a phone, so a reader scrolling normally meets each item just as it begins to animate — the reordering described in how a phone stacks your columns, with the intermediate case in the tablet width nobody checks.
Fixed elements complicate it further: an animation triggering relative to the viewport can fire while the element sits behind a sticky bar, which is one of the interactions in sticky header behaviour and height. And motion inside a collapsed panel usually plays when the page loads rather than when the panel opens, which is worth testing in the accordion FAQ element.
A workable position
Animate no more than two or three things on a page, keep each under half a second, trigger early, play once, and respect reduced motion. That is sufficient for the effect to register and nowhere near enough for it to be tiring.
Be particularly careful with sections destined for a shared library, since an animation set for one page’s rhythm will be reused in pages with a different one — the caution in saving a section to a library — and with anything that competes for attention with an honest indicator like the progress bar element.
If someone insists the animations are helping, that is a testable claim: with and without, judged on the outcome the page exists for rather than on how it feels in the editor, using the method in testing a funnel step. In most cases the result is no detectable difference, which is itself an argument for the lighter page.
Frequently Asked Questions
Which elements are worth animating on scroll?
A single key statistic or claim, and at most a short stagger across a row of cards. Body copy, navigation, buttons and form fields should not animate — anything interactive should be usable the moment it is visible, and text that fades in is text that cannot yet be read.
Should anything on the first screen animate?
No. Animating what the visitor is waiting for makes the page feel slower than it is, and on a slow connection the animation and the load compete, so the first screen appears to arrive twice — once blank, once faded.
How long should a scroll animation last?
A fraction of a second. Anything longer is perceived as the interface being slow rather than as an effect. Trigger it before the element is fully in view so it has finished by the time the reader arrives, and play it once rather than on every pass.
What do scroll animations cost?
Usually a general-purpose animation library loaded whether one element uses it or fifty, rendering cost on modest phones, and possible layout shift where an element starts offset and moves into place — which is exactly what the measurement penalises.
What about people who dislike motion?
Browsers expose a reduced-motion preference and it should be respected. The same setting is commonly used by people on modest hardware who simply want the page to be still, so honouring it is a performance courtesy as well as an accessibility one.
Why does an animation behave differently on a phone?
Because the layout has changed. A stagger across three columns becomes a vertical queue once they stack, so a reader scrolling normally meets each item exactly as it starts animating. Fixed elements can also trigger an animation while the element sits hidden behind them.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.