gsap.quickTo()
gsap.quickTo() is GSAP's high-frequency-event optimizer. It returns a setter function that calls `gsap.to()` under the hood but reuses a single internal tween instance, so firing it 60+ times per second (mousemove, scroll, wheel) doesn't create garbage. The pattern enables smooth follower animations - magnetic buttons, custom cursors, hover-tracked highlights - without per-frame allocation.
Updated June 2, 2026
How quickTo works
Calling gsap.to() on every mousemove creates a fresh tween, kills the previous one, and allocates per-event. At 60+ events per second that's measurable GC pressure. gsap.quickTo() returns a setter that reuses the same tween instance internally - calling it just updates the target value and lets GSAP's interpolator catch up smoothly.
The cursor's x and y catch up to the pointer over 0.4 seconds with a power3 ease - smooth, no jitter, no GC pressure. Compare to calling gsap.to('.cursor', { x, y, duration: 0.4 }) on every mousemove, which creates a new tween 60+ times per second.
Use quickTo for
- Custom cursors that follow the pointer with smoothing
- Magnetic buttons where the button center tracks the pointer with elastic catch-up
- Image-follow lists where a thumbnail tracks pointer position
- Image trails where a sequence of thumbnails follows pointer position
- Scroll-position-driven indicators where the indicator catches up smoothly
- Any high-frequency-event-driven motion where allocation matters
Use something else when
- One-shot animations on a discrete event (click, intersection) - regular
gsap.to()is simpler - Multiple properties on the same element where you want them coordinated - one quickTo per property is verbose; use a per-frame
gsap.set()driven by a ScrollTrigger / rAF loop - Scroll-scrubbed animations - that's
scrub: trueon a ScrollTrigger, not quickTo - Animations that change duration or ease per event - quickTo's config is fixed at setup time
Used in these Annnimate components
- The Magnetic Button uses two quickTo setters (xTo, yTo) so the button's transform tracks pointer position with elastic smoothing
- The Custom Cursor uses quickTo on the cursor's x and y for the smooth-follow behaviour - no jitter on fast pointer moves
- The Image Follow List uses quickTo on the floating thumbnail's x and y so it tracks pointer position while a hover-target intersects the cursor
- The Image Trail uses an array of quickTo setters (one per trail node) for the chained follower effect
See it running in production
Common questions
- What's the difference between quickTo and quickSetter?
- quickSetter is INSTANT - no easing, no duration. The setter writes the value directly each call. quickTo has a smoothing layer: the setter updates a target, and GSAP eases toward it over the configured duration. Use quickSetter for raw passthrough; use quickTo when you want the catch-up smoothing.
- Can I change the duration after creating a quickTo?
- No - the duration and ease are fixed at setup time. If you need dynamic timing, either create the quickTo again on the change event, or use a regular
gsap.to()withoverwrite: 'auto'per call (less performant but more flexible). - Does quickTo work with multiple properties on one element?
- One quickTo handles one property. For multi-property tracking (x + y + rotation), create one quickTo per property. The pattern is verbose but performant - each setter has its own internal tween, all coordinated by the same ease.
- Should I use quickTo inside useGSAP for React?
- Yes - create the quickTo inside the useGSAP callback (so it scopes to the component's lifecycle), and pin the setter on a ref so the event handler can read it. Wrap the event handler in
contextSafeso it gets cleaned up properly. - Why does my quickTo feel laggy?
- Duration too high. quickTo's smoothing IS lag - it eases toward the target over the duration. For tight cursor following, drop to 0.3 or 0.2 seconds. For atmospheric drift, 0.6-0.8 reads as 'cinematic'. Match the duration to the feel you want.
