DEV Community: rashid ks

Building Performant Scroll-Driven Animations with GSAP ScrollTrigger

rashid ks — Wed, 15 Jul 2026 14:14:55 +0000

Scroll-driven animation looks great in a portfolio site, and it's also one of the easiest places to accidentally tank your Core Web Vitals if you build it wrong. Here's the actual pattern I use to get smooth scroll effects without the jank — and the specific mistakes that cause it.

The one rule that matters more than any other

Only animate transform and opacity. Never animate width, height, top, left, margin, or box-shadow directly in a scroll-driven animation. Those properties trigger layout recalculation on every scroll tick, and at 60fps that recalculation is what causes visible stutter on anything but a high-end device.

// Bad — triggers layout on every scroll frame
gsap.to(".card", {
  scrollTrigger: { trigger: ".card", scrub: true },
  width: "300px",
  top: "50px"
});

// Good — GPU-accelerated, no layout thrashing
gsap.to(".card", {
  scrollTrigger: { trigger: ".card", scrub: true },
  scale: 1.2,
  y: 50
});

Basic scrub animation

scrub: true ties the animation's progress directly to scroll position instead of playing on a timer — this is what makes it feel "attached" to the scrollbar rather than just triggered once.

gsap.registerPlugin(ScrollTrigger);

gsap.to(".hero-image", {
  scrollTrigger: {
    trigger: ".hero-section",
    start: "top top",
    end: "bottom top",
    scrub: 1 // smoothing — higher = more lag/smoothness
  },
  scale: 1.3,
  opacity: 0.4
});

The scrub: 1 (instead of scrub: true) adds a small smoothing delay between scroll position and animation progress — it's the difference between animation that feels mechanically tied to the scrollbar versus one that feels like it has actual weight to it.

Pinning a section

Pinning locks an element in place while the user keeps scrolling — the classic "text changes while the image stays fixed" effect:

ScrollTrigger.create({
  trigger: ".pin-section",
  start: "top top",
  end: "+=800", // pin for 800px of scroll
  pin: true,
  pinSpacing: true // keeps document flow correct after unpin
});

The most common bug here is forgetting pinSpacing, which leaves a layout gap or overlap once the pin releases — easy to miss in development since it often only shows up after content below the pinned section is added.

Batching triggers for content-visibility gains

If you have many similar elements (a grid of cards animating in on scroll), don't create one ScrollTrigger per element — use ScrollTrigger.batch() instead. It groups elements entering the viewport together instead of running individual calculations for each one:

ScrollTrigger.batch(".fade-in-card", {
  onEnter: batch => gsap.to(batch, {
    opacity: 1,
    y: 0,
    stagger: 0.15,
    overwrite: true
  }),
  start: "top 85%"
});

Killing triggers on route change or resize

If this is part of an SPA or any dynamically re-rendered layout, stale ScrollTriggers pointing at removed DOM nodes are a real memory leak and a real source of "why is this animation firing on the wrong element" bugs:

function cleanupScrollTriggers() {
  ScrollTrigger.getAll().forEach(trigger => trigger.kill());
}

Call this before re-initializing animations on route/content change, then re-run your setup function afterward.

The performance check that actually matters

Chrome DevTools → Performance tab → record a scroll pass. Look at the Rendering section specifically for Layout Shift and Paint events firing during scroll — if you see repeated layout/paint blocks stacked up during the scrub, something in your animation is touching a non-GPU-accelerated property, even if it's not obvious from the code which one.

I build this kind of animated, performance-conscious front-end work for client sites — more at capareach.com.

Setting Up GTM + GA4 on a Static HTML Site (No CMS, No Plugins)

rashid ks — Wed, 15 Jul 2026 14:13:22 +0000

Most GTM/GA4 tutorials assume you're on WordPress with a plugin doing the heavy lifting. When you've migrated to static HTML/CSS/JS — no CMS, no plugin ecosystem — you're wiring everything by hand. Here's the actual setup, including the parts most tutorials skip: custom event tracking for things a plugin would normally handle for you.

1. The base GTM snippet

Drop this in <head>, as high as possible, on every page:

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->

And the noscript fallback right after the opening <body> tag:

<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-XXXXXXX"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>

That's it for the container. GA4 itself gets configured inside GTM as a tag, not hardcoded on the page — this is the part people skip when coming from a plugin-based setup, where the plugin often injects the GA4 script directly instead of routing through GTM.

2. Firing custom events without a plugin

On WordPress, a plugin usually auto-tracks outbound clicks, file downloads, form submits. On static HTML, you push these to dataLayer manually:

document.querySelectorAll('a[href^="https://wa.me"]').forEach(link => {
  link.addEventListener('click', () => {
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
      event: 'whatsapp_click',
      link_url: link.href
    });
  });
});

Then in GTM: create a Custom Event trigger listening for whatsapp_click, attach it to a GA4 Event tag, and map link_url as an event parameter via a Data Layer Variable. No plugin, same result.

3. Form submission tracking (Web3Forms example)

If you're using Web3Forms (or any fetch-based form handler) instead of a native <form action> submit, the page never actually navigates — so a simple "Thank You page visited" GA4 trigger won't fire. You need to push the event manually on the fetch success callback:

fetch('https://api.web3forms.com/submit', {
  method: 'POST',
  body: formData
})
.then(response => response.json())
.then(data => {
  if (data.success) {
    window.dataLayer.push({ event: 'form_submit_success' });
    // redirect or show thank-you state
  }
});

This is the single most common tracking gap I see on migrated static sites — the form works fine, but the conversion event silently never fires because nobody wired it to the actual async response.

4. Validating before you trust any of it

Don't assume it's working because the container published. Use GTM's Preview mode and actually click through every tracked interaction — WhatsApp link, form submit, phone tap — watching the tag fire in real time. Then cross-check in GA4's DebugView that the event lands with the parameters you expect attached.

Skipping this step is how sites end up with months of "working" analytics that were quietly firing wrong the whole time.

I do this kind of GTM/GA4 implementation work regularly for client migrations off WordPress — more at capareach.com if it's useful.