Lenis Smooth Scroll Page — Virtual Scroll With Parallax

Smooth scrolling has a long history of being done badly. The versions that gave it a bad name hijacked the wheel, disabled the scrollbar, broke keyboard navigation, and made the browser's find-on-page jump to nowhere. Lenis is the modern answer, and the reason it works is a specific architectural choice: it keeps the native scroll position authoritative and only changes *how fast the page approaches it*.

The easing, and why it decelerates so naturally

The default easing looks cryptic and is worth understanding:

function (t) { return Math.min(1, 1.001 - Math.pow(2, -10 * t)); }

That is an exponential ease-out. On every frame the page moves a fraction of the *remaining* distance to its target, so movement is fast when far away and slows asymptotically as it arrives. This is why Lenis feels like inertia rather than an animation: a fixed-duration cubic-bezier always takes the same time regardless of distance, whereas an exponential approach naturally takes longer for a long throw and settles quickly for a short one. The 1.001 and Math.min exist to guarantee the function actually reaches exactly 1 rather than approaching it forever.

duration: 1.15 scales the whole feel. Below about 0.8 the effect is barely perceptible; above 1.5 the page starts feeling like it is fighting the user, which is the single most common way this is over-tuned.

You own the animation frame

Lenis deliberately does not start its own loop:

function raf(time) { lenis.raf(time); requestAnimationFrame(raf); } requestAnimationFrame(raf);

This looks like boilerplate but it is the most important design decision in the library. Because you call lenis.raf() yourself, Lenis can share a single animation frame with GSAP's ticker, a Three.js render loop, or a physics simulation. Libraries that run their own internal loop end up with two or three independent rAF callbacks per frame, which is exactly how scroll-linked animation drifts a frame out of sync with the scroll it is supposed to follow.

Parallax from the scroll event

lenis.on('scroll', ...) fires every frame with scroll, velocity, and progress already computed — no getBoundingClientRect() calls, no scroll listener of your own, no throttling to write.

The parallax is markup-driven. Any element can opt in by declaring a multiplier:

<h1 data-parallax="-0.18">

and the handler applies it:

el.style.transform = 'translate3d(0,' + (e.scroll * speed) + 'px,0)'

Negative values move the layer against the scroll so it appears further away; the magnitude is the depth. translate3d rather than translateY forces GPU compositing, so the transform never triggers layout.

Note the deliberate use of a plain for loop over the cached layers array. This runs on every single frame during scrolling, so re-querying the DOM or allocating a new array here is exactly the kind of per-frame waste that turns smooth scroll into jank.

Anchors, and the problem they create

Native anchor links are incompatible with virtual scrolling — the browser teleports to the target instantly, skipping everything Lenis is doing. So they are intercepted:

lenis.scrollTo(link.getAttribute('href'), { offset: -70, duration: 1.4 })

scrollTo() accepts a selector, an element, or a pixel value. The offset: -70 stops the target sliding under the fixed navigation bar — the detail every sticky-header site gets wrong on first attempt. The longer duration here is intentional: a deliberate jump reads better slightly slower than free scrolling.

The CSS that is genuinely required

html.lenis, html.lenis body { height: auto } and .lenis.lenis-smooth { scroll-behavior: auto !important } are not optional styling. Lenis adds those classes to the document itself. The second one matters most: if a stylesheet sets scroll-behavior: smooth, the browser's own smooth scrolling runs *simultaneously* with Lenis, and the two implementations fight over the same scroll position, producing stutter that looks like a performance problem but is a configuration one.

Accessibility, and the off switch

Smooth scrolling can trigger motion sickness, which is why the toggle calling lenis.stop() and lenis.start() exists. In production, that should be driven by prefers-reduced-motion automatically rather than a button — query the media list and never construct Lenis at all when reduction is requested. Because Lenis leaves the native scroll position intact, keyboard scrolling, find-on-page, and screen readers all continue to work normally either way, which is the substantive difference between it and the wheel-hijacking scripts it replaced.

Reusing it

Keep the required CSS, the rAF loop, and the scroll handler; everything else is content. Add data-parallax to anything you want to drift. If you also use GSAP ScrollTrigger, call ScrollTrigger.update from the same Lenis scroll event and drive lenis.raf from GSAP's ticker instead of your own. Compare with a scroll smoother parallax implementation, or scroll progress if all you need is the bar.