Blanche
Blanche Agency

Blanche · Studio

© 2026

Native CSS Scroll Animations Are Here — It's Time to Fire Your JavaScript Library
←Back to blog
Web DevelopmentPerformance OptimizationMotion DesignJune 30, 2026·8 min read

Native CSS Scroll Animations Are Here — It's Time to Fire Your JavaScript Library

Scroll-driven animations are now a first-class CSS feature in modern browsers — and most teams are still bundling 40kb of JavaScript out of pure habit. Here's why that needs to stop, and exactly how to make the switch.

The Library Habit We Can't Seem to Break

Be honest: the last time a designer handed you a scroll-triggered reveal animation, how long did it take before you typed npm install gsap? For most frontend teams, that reflex is so deeply baked in that nobody even questions it. GSAP is great. Framer Motion is great. But we've been reaching for power tools to hammer in thumbtacks, and the browser has been quietly building a better hammer.

As of 2025, scroll-driven animations are a fully ratified part of the CSS spec — and browser support has crossed a threshold that makes production use not just feasible, but arguably irresponsible to ignore. This isn't another "CSS can do X now" curiosity post. This is a direct challenge: audit what you're shipping, because a significant chunk of your animation JavaScript can be deleted today.

What CSS Scroll-Driven Animations Actually Give You Now

The Scroll-driven Animations specification introduces two core mechanisms: scroll timelines and view timelines. These let you bind any CSS @keyframes animation to scroll progress rather than time — no event listeners, no requestAnimationFrame loops, no layout thrashing.

@keyframes fade-in-up {
  from { opacity: 0; transform: translateY(40px); }
  to   { opacity: 1; transform: translateY(0); }
}

.card {
  animation: fade-in-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 40%;
}

That's it. That .card element will now animate in as it enters the viewport — no IntersectionObserver, no scroll handler, no library. The browser handles everything at the compositor level.

The Two Timeline Types You Need to Know

  • scroll() — ties animation progress to a scroll container's total scrollable distance. Perfect for progress bars and parallax offsets.
  • view() — ties animation progress to an element's position within the viewport. Perfect for entrance/exit animations and reveal effects.

You can also name timelines using scroll-timeline-name and view-timeline-name for cross-element orchestration — a capability that previously required JavaScript to coordinate at all.

Browser Support in 2025: What the Gaps Actually Mean

Chrome and Edge have had full support since version 115. Firefox shipped full support in version 110. Safari is the outlier — partial support landed in Safari 18.2 (late 2024), but animation-range and named timelines are still inconsistent.

Global support sits around 84-87% of users depending on how you slice the data. In most agency contexts — particularly B2B SaaS, developer tools, or creative portfolio work — your browser distribution likely skews toward Chrome and Firefox heavily enough that this number is even higher in practice.

The critical point: a lack of support in Safari does not mean your animations break. It means they don't play. With proper progressive enhancement (covered below), that's an entirely acceptable fallback.

Performance Benchmarks: Native vs. the Big JS Players

This is where the conversation gets uncomfortable for library advocates.

GSAP's ScrollTrigger works by listening to scroll events on the main thread and updating element styles via JavaScript. Even with GSAP's exceptional optimization, you're still running logic on the main thread, triggering style recalculations, and — if you're animating transform or opacity — bouncing between thread boundaries.

Native CSS scroll-driven animations run entirely on the compositor thread for transform and opacity properties. The main thread is never involved. This is not a marginal improvement.

"Compositor-thread animations can't be janked by heavy JavaScript execution on the main thread. When your app is doing real work — parsing data, rendering components — native scroll animations keep playing smoothly. JS-driven scroll animations do not."

In real-world profiling using Chrome DevTools, a page with 12 scroll-triggered card reveals using view() timelines shows zero main-thread scroll animation work. The equivalent GSAP implementation shows consistent 2–4ms main-thread hits per scroll frame — not catastrophic, but cumulative, and it scales poorly with complexity.

Framer Motion's whileInView is even heavier. It runs through React's reconciliation cycle and uses IntersectionObserver callbacks to trigger state changes. On low-end Android devices, this pattern is visibly janky in ways that native CSS simply isn't.

Bundle size comparison:

  • GSAP core + ScrollTrigger: ~45kb minified + gzipped
  • Framer Motion (full): ~170kb
  • Native CSS scroll animations: 0kb

That's not rhetorical. Zero bytes. No import, no initialization, no dependency to audit.

Five Practical Patterns You Can Ship This Week

1. Scroll Progress Indicator

@keyframes grow-bar {
  from { transform: scaleX(0); }
  to   { transform: scaleX(1); }
}

.progress-bar {
  position: fixed;
  top: 0; left: 0;
  width: 100%; height: 4px;
  background: #6c63ff;
  transform-origin: left;
  animation: grow-bar linear;
  animation-timeline: scroll(root);
}

This one used to require ~20 lines of JavaScript. Now it's six CSS declarations.

2. Staggered Section Reveals

Use animation-delay with view() timelines to create staggered entrance effects without JavaScript orchestration:

.feature-card {
  animation: fade-in-up linear both;
  animation-timeline: view();
  animation-range: entry 10% entry 50%;
}
.feature-card:nth-child(2) { animation-delay: 0.1s; }
.feature-card:nth-child(3) { animation-delay: 0.2s; }

3. Parallax Background Offset

.hero {
  animation: parallax-shift linear;
  animation-timeline: scroll(root);
}
@keyframes parallax-shift {
  from { background-position: 50% 0%; }
  to   { background-position: 50% 40%; }
}

4. Sticky Section Counter

Named view timelines let a parent element drive child animations — ideal for sticky sidebars that react to their section's scroll progress:

.section {
  view-timeline-name: --section-progress;
  view-timeline-axis: block;
}

.sticky-label {
  animation: label-fade linear both;
  animation-timeline: --section-progress;
  animation-range: contain;
}

5. Exit Animations

Most JS libraries handle exit animations. So does view():

.card {
  animation: reveal-and-fade linear both;
  animation-timeline: view();
  animation-range: entry 0% exit 100%;
}
@keyframes reveal-and-fade {
  0%   { opacity: 0; transform: scale(0.9); }
  20%  { opacity: 1; transform: scale(1); }
  80%  { opacity: 1; }
  100% { opacity: 0; }
}

Edge Cases Where JS Libraries Still Win

Honesty matters here. There are genuine scenarios where the native approach falls short:

  • Physics-based animations: Spring simulations, momentum curves, and velocity-based interactions have no CSS equivalent. GSAP and libraries like react-spring own this space.
  • Complex sequencing with conditional logic: If your scroll animation needs to branch based on user state, data, or device capability — that's JavaScript territory.
  • Scroll-jacking and custom scroll mechanics: Virtual scroll engines (Lenis, Locomotive) that hijack native scroll to create smooth, controlled experiences can't be replicated in CSS.
  • Safari parity requirements: If your contract demands pixel-perfect consistency across all browsers including Safari ≤ 18.1, you'll need a polyfill or a JS fallback strategy. The official scroll-timeline polyfill from Google works, but adds weight back.
  • Intricate timeline scrubbing: If designers need to scrub animations backward and forward with precise control (think award-winning interactive storytelling sites), GSAP's timeline API is genuinely more expressive.

Notably absent from that list: basic scroll reveals, parallax, progress indicators, and entrance animations — which represent the vast majority of scroll animation work on a typical agency project.

Progressive Enhancement: Shipping Native Scroll Animations Safely Today

The right approach is not "wait for 100% browser support." The right approach is a clean feature query:

/* Base state: visible, no animation */
.card {
  opacity: 1;
  transform: none;
}

/* Enhanced: only animate when supported */
@supports (animation-timeline: view()) {
  .card {
    opacity: 0;
    animation: fade-in-up linear both;
    animation-timeline: view();
    animation-range: entry 0% entry 40%;
  }
}

Unsupported browsers see the final state immediately — content is always accessible. Supported browsers get the enhanced experience. No polyfill weight, no detection library, no JavaScript required.

This is progressive enhancement as it was always meant to work: a single codebase, layered capability, zero compromise on baseline accessibility.

Writing Less Code Is a Feature, Not a Compromise

There's a psychological trap in frontend development where complexity signals competence. Shipping a custom GSAP timeline with custom easing curves feels more professional than six lines of CSS. It isn't.

The best code is the code you don't have to write, maintain, update, audit for security vulnerabilities, or explain to the next developer on the project. Native browser features come with free documentation, free performance optimization, and free longevity.

The scroll-driven animations spec is stable, the browser support is production-viable right now, and the performance advantages are real. The only remaining argument for defaulting to a JavaScript library for scroll animation is inertia — and that's not an argument.

Audit your next project. List every scroll-triggered animation. Ask which ones genuinely need JavaScript. That list will be shorter than you think — and getting it to zero should be the goal.

The library habit is hard to break. Break it anyway.

←Back to blog