Animation has become a much bigger part of the websites I build over the last few years.
GSAP is usually at the center of it. I use ScrollTrigger regularly, sometimes pair it with Lenis for smooth scrolling, and occasionally add parallax with GSAP, Rellax or another approach when the design calls for it.
Used well, these tools can completely change how a website feels. Motion can help control the pace of a page, connect sections, add depth and make an interface feel much more deliberate.
But there is another side to it that becomes obvious when you are trying to push mobile PageSpeed Insights and Lighthouse scores into the high 90s.
I have worked on sites that score 98–100 on desktop and then drop into the low 90s or below on mobile. There are usually several reasons for the gap, but animation can be one of them. What makes it interesting is that the animation itself may look completely fine. There may be no visible delay, no stutter and nothing that feels obviously slow.
The performance cost can still be there.
The work behind the animation matters
What we see on screen is only the final result. Before a heading reveals or an image moves into place, the browser may have already done quite a bit of work.
GSAP and ScrollTrigger need to initialize. Elements are found, timelines are created, positions are measured and trigger points are calculated. Text animation can go further by splitting a heading into lines or words, creating additional markup and applying starting states before the content reaches its final position.
None of this means there is anything wrong with GSAP. I use it because it handles complicated animation exceptionally well. The point is that a polished result can still require meaningful work from the browser.
That distinction becomes important with mobile performance testing. An animation can appear at exactly the right time to a person using the site while Lighthouse still sees the JavaScript execution, DOM changes, layout calculations and content states required to produce it.
Text reveals are a good example. A large heading coming in line by line can look great on desktop, especially in a hero where the typography and movement have room to breathe. On mobile, the same effect often adds less visually while carrying the same setup cost.
This becomes especially relevant above the fold. If an important heading starts hidden and depends on JavaScript before reaching its visible state, removing that reveal on mobile can sometimes make a meaningful difference to the performance score even though the original animation never looked slow.
That is the kind of optimization I am interested in. The desktop keeps the full visual treatment, while mobile displays the content immediately. Nothing important has been lost, and the smaller device has less work to do.
Mobile browsers change the equation
Performance testing is only part of the mobile conversation. Scroll-based animation also has to deal with a browser environment that behaves differently from desktop.
On mobile, the usable viewport can change while someone is scrolling as the browser interface expands and collapses. That matters for effects tied closely to viewport size, scroll progress or element position.
A parallax effect that behaves perfectly in a stable desktop viewport can become less predictable when those measurements are changing during the interaction. The same is true of pinned sections, complex ScrollTrigger sequences and other effects that depend heavily on the relationship between the page and the viewport.
Sometimes the result is subtle. A movement may feel slightly disconnected from the scroll. An element may jump or shift when the viewport changes. Multiple scroll effects can also start to compound the problem and make the page feel busier or less stable than intended.
Lenis deserves a separate mention here because I like it a lot on the right desktop project. On a site with significant scroll-based motion, it can help everything feel connected and controlled.
Mobile is different. Native touch scrolling is already deeply integrated with the browser and operating system. If Lenis is not clearly improving the phone experience, I generally see little reason to add another scroll layer simply because the desktop version uses one.
Parallax is often an even easier decision. It can add real depth on a large display, but on a narrow screen there is less room for the movement to register. If the static version looks just as good and avoids the possibility of jitter or strange behavior as the viewport changes, removing the effect is not really a loss.
In many cases, the simpler version actually feels better.
What I tend to simplify on mobile
I do not have a rule that says all animation should disappear below a certain breakpoint. The decision depends on the site, the effect and what testing shows.
There are, however, a few things I look at first:
- Text reveals above the fold when important content begins hidden and depends on JavaScript to reach its final state.
- Repeated fade-ins and fade-ups when nearly every section, card, image and heading has been given an entrance animation.
- Lenis when native touch scrolling already provides the experience the page needs.
- Parallax effects when the movement adds little on a small viewport or becomes less stable as the browser viewport changes.
- Decorative ScrollTriggers that add motion without improving the way the user understands or interacts with the page.
Interaction-based animation is different. Menus opening, accordions expanding, modals appearing and interface states changing all use motion to communicate something useful. Those effects usually have a stronger reason to stay.
The distinction I care about is not animated versus static. It is whether the motion is helping.
Performance and design do not have to fight each other
There is a tendency to treat performance optimization as a process of stripping things away until the site becomes boring. I do not think that is necessary.
I still use GSAP heavily. I still use ScrollTrigger. Lenis and parallax still have a place when they make the experience better.
The difference is that I no longer assume every desktop effect needs to run unchanged on mobile.
Responsive design already means making different decisions for different screens. Layouts change, navigation changes, images crop differently and columns stack. Motion can be treated the same way.
A GSAP text reveal can be part of the desktop experience while mobile shows the heading immediately. Lenis can improve the feel of a desktop site while the phone keeps native scrolling. A parallax image can move on a large screen and remain static on a smaller one.
Those are not compromises. They are decisions based on where the site is actually being used.
PageSpeed Insights and Lighthouse are useful because they can expose costs that are not obvious while developing on powerful hardware. I am not interested in removing useful animation just to turn a 98 into a 100, but when a site is performing beautifully on desktop and significantly worse on mobile, the motion system is worth investigating along with everything else.
Sometimes an effect can be optimized. Sometimes it can be simplified. And sometimes removing it from mobile improves the score and the actual experience at the same time.