Locomotive Scroll vs GSAP ScrollTrigger

Locomotive Scroll is the better starting point for a design-led page where smooth scrolling, parallax, viewport detection, and a small API are the main concerns. Its current v5 release is built on Lenis and weighs 9.4kB gzipped, according to the official Locomotive Scroll documentation, checked October 13, 2026.

GSAP ScrollTrigger is the better starting point when animation control is the hard part. Its API covers triggers, scrub, pinning, snapping, callbacks, horizontal movement, responsive conditions, and custom scrollers in one animation system. ScrollTrigger does not provide a separate smooth-scroll engine by itself. For native-scroll smoothing inside GSAP, the relevant tool is ScrollSmoother.

The biggest difference is where the motion comes from. Locomotive Scroll presents smooth scrolling as part of the library's core job. Its v5 docs say smooth scrolling is enabled by default through Lenis, and its scroll callback exposes position, velocity, direction, and progress.

That model works well when you want the whole page to have a shared rhythm. You can attach data-scroll-speed to create parallax, listen for native custom events, or expose progress as a CSS variable. The library also supports a custom wrapper and content element when the page needs a contained scroller.

ScrollTrigger starts from a different assumption. It watches the browser's scroll position and calculates when a trigger should start and end. Its scrub option links animation progress to that position. A numeric value, such as scrub: 0.5, makes the playhead take 0.5 seconds to catch up, as shown in the ScrollTrigger configuration documentation, checked October 13, 2026.

That gives you fine control over each animation, but it does not make the entire page feel smooth by default. If you want a page-wide smoothing layer, use ScrollSmoother or connect ScrollTrigger to a third-party scroller through scrollerProxy().

Locomotive Scroll and GSAP can work together, but the integration has a cost: one system must become the source of truth for scroll position. If Locomotive Scroll drives the page, ScrollTrigger needs the current scroller and an update path. If GSAP drives the page through ScrollSmoother, you should let ScrollTrigger manage the animation and smoothing lifecycle.

The safe pattern is simple:

1. Pick one library to own the scroll position.
2. Register the integration before creating triggers.
3. Refresh trigger measurements after images, fonts, and dynamic content have settled.
4. Destroy both instances when a route or component unmounts.
5. Test keyboard focus, reduced motion, touch scrolling, and fixed-position elements.

ScrollTrigger's refresh() method recalculates start and end positions. That matters when layout changes after the triggers are created. The GSAP integration guidance also makes clear that measurements are based on the document flow, not a continuously remeasured layout.

Avoid running two independent smoothing loops. You can end up with delayed triggers, incorrect pin positions, or a page that feels disconnected from the scrollbar. The cleanest combination is usually Locomotive Scroll for scroll input and detection, with GSAP for the timelines that need more control.

Smooth scrolling is a visual effect, so it needs an escape hatch. Locomotive Scroll v5 documents a native scrollbar, keyboard navigation, ARIA support, and automatic disabling of parallax on touch devices. Its migration guide explains that v5 removed custom scrollbar behavior and uses native scrolling on touch by default, checked October 13, 2026.

That is a useful default for mobile. You can still opt into touch parallax with data-scroll-enable-touch-speed, but you should have a reason to do it. A device that has to track a finger directly should not feel like it is being pulled by a delayed desktop effect.

GSAP ScrollTrigger also starts from native scrolling. That avoids the fake scrollbar problem when you use ScrollTrigger alone. The risk appears when you add a transform-based smoothing layer. GSAP's ScrollSmoother documentation says that content is moved with transforms and that fixed elements should sit outside the wrapper, because transforms create a new containing block.

For either setup, respect prefers-reduced-motion. Reduce or remove parallax, scrub, and long easing when a visitor requests less motion. Keep the content and keyboard order meaningful without the effect. Motion should add atmosphere, not become the only way to understand a page.

Neither library gives you a performance score by installing it. The page still pays for images, fonts, JavaScript, layout work, paint, and every animation you attach to scroll.

Locomotive Scroll v5 reduces its own footprint to 9.4kB gzipped. Its docs describe a dual Intersection Observer strategy: one path handles simple in-view detection and another handles continuous effects, with elements joining the animation loop only when they are visible and need updates. That is a sensible fit for pages with many small parallax effects.

The same migration guide compares v5's 9.4kB gzipped bundle with about 12.1kB for v4. Those figures describe the library bundle, not the performance of your finished page. Treat them as implementation context, not as a promise about frame rate.

ScrollTrigger is efficient when you keep the work focused. Its docs describe debounced scroll events, synchronized updates, throttled resize calculations, and precomputed trigger positions. It also gives you tools to limit work: once, matchMedia(), batch(), visibility checks, and kill() for cleanup.

The real performance test is a representative page on a mid-range phone. Record scroll smoothness while a pinned section, a large image, a text split, and a video or WebGL scene run together. Then repeat with reduced motion and a slow network. A library comparison cannot replace that test.

ScrollTrigger wins when the animation itself is the product. Its pinning model keeps a section in place while the rest of the page moves. Its snap option can settle a timeline on labels or progress values. Its callbacks expose enter, leave, update, refresh, direction, and velocity states. You can also connect one timeline to a horizontal container animation.

Locomotive Scroll is more direct when the effect is attached to an element. Data attributes make common parallax and in-view work readable in HTML. Progress events and CSS variables are useful when CSS should respond to scroll without a large animation graph.

The trade-off is depth versus surface area. ScrollTrigger gives you more control and more configuration to manage. Locomotive Scroll gives you a smaller vocabulary for common scroll effects and asks you to bring another tool when a sequence becomes highly choreographed.

Choose Locomotive Scroll when:

• The page needs a consistent smooth-scroll feel across sections.
• Parallax and viewport detection cover most of the interaction brief.
• The team prefers a small, typed API and HTML data attributes.
• Touch behavior and native scrolling are central requirements.

Choose GSAP ScrollTrigger when:

• The concept depends on pinned chapters or a timeline tied tightly to progress.
• You need scrub, snap, velocity, callbacks, or horizontal container animation.
• The team already uses GSAP for other animation work.
• Native scrolling is acceptable, or you plan to add ScrollSmoother deliberately.

Choose both when the project needs Locomotive Scroll's scroll feel and GSAP's timeline control. In that case, decide which library owns scrolling before you write the first trigger. That one decision prevents most integration problems.

• Locomotive Scroll documentation: v5 architecture, 9.4kB bundle, accessibility, and core features.
• Locomotive Scroll migration guide: v4 to v5 changes, Lenis integration, touch behavior, and the 12.1kB v4 comparison.
• GSAP ScrollTrigger documentation: triggers, scrub, pinning, snapping, callbacks, and custom scrollers.
• GSAP ScrollSmoother documentation: native scrolling, smoothing, effects, and transformed-content caveats.