I open DevTools → Layers on our landing page. Sort by memory. First in the list — a text section. 680×1491. 4.1 MB.

I check the block's CSS. No will-change. No transform. No filter. No position: fixed. Just position: relative, display: flex, a white background.

Then I open Compositing Reasons:

Overlaps other composited content.

That's the trail. Something below this block promoted itself onto a GPU layer, and our innocent wrapper got dragged along by z-order rules.

In my previous article I covered the mechanics of implicit compositing: element B becomes a layer → element A above it in z-order has to become a layer too. Basic compositor physics.

But in code reviews, in PRs, in conversations with the team, I keep seeing the same hole in mental models. This article is about that hole.

What people miss

will-change reads like a local hint. Put it on an element — that element becomes a layer. End of story.

The mental model looks like this:

[ figure: will-change: transform ]   → becomes a layer
[ wrapper next to it ]               → untouched, fine

Reality looks like this:

[ figure: will-change: transform ]   → becomes a layer (trigger)
[ wrapper next to it ]               → ALSO a layer (overlap victim)

will-change affects more than the component you put it on. It affects everything that sits above it in z-order and physically overlaps with it.

And that leads to the part nobody talks about.

The cost is paid by the victim, not the trigger

Here are the numbers from my case:

Two small parallax effects cost 1.2 MB combined — that's a budget I took knowingly.

The 4.1 MB wrapper, I did not take. Overlap took it. Total: 5.3 MB of GPU memory for two images that drift slightly on scroll.

The texture memory formula:

width × height × DPR² × 4 bytes

Memory scales quadratically with dimensions. Small trigger × big victim = big bill. And the bill is not visible in the trigger's CSS — it shows up only in DevTools → Layers, in the Memory estimate of the neighbor.

Direction matters

Overlap is one-directional in z-order. Composited layers paint bottom-up: everything that sits above the trigger gets promoted; everything below is fine.

Practical debugging trick: when you see "Overlaps other composited content," look down the DOM and z-stack to find the trigger, not up. The trigger sits below you in paint order.

Who actually set will-change

It was not in my CSS. Grep said no. The <figure> component said no.

Then I opened the Elements panel — and there it was. style="will-change: transform", inline. Set by a library — a popular parallax package we use in the project.

I dug into its source. The shape was something like this:

// inside the library
class ParallaxElement {
  constructor(options) {
    this.el = options.el;
    // ...
    this.el.style.willChange = 'transform';
  }
}

In the constructor. The moment the instance is created. Unconditionally. No IntersectionObserver. No visibility check. Once set, the hint stays until the element unmounts.

This is not unique to one library. Parallax packages, reveal-on-scroll animations, sticky-effect helpers, intersection-based UI kits — many of them set will-change inline at initialization and never remove it. From the library author's perspective it is a reasonable optimization: they don't know when the user will scroll to your element, so they promote the layer ahead of time.

With one parallax image, you won't notice. With dozens of sections (as we have across our landing pages), it is tens of megabytes of GPU memory. And every one of them drags its biggest neighbor into compositing through overlap.

This is not a bug in any specific library. It's a pattern category worth checking for in any third-party animation library you pull in.

What to do

will-change is a short-term hint. The spec is explicit:

Authors should switch off will-change when the element stops being actively changed.

Wrong:

.figure {
  will-change: transform; /* forever */
}

Memory is allocated from CSS parse until page unload. Even when the element is far below the viewport.

Right:

const io = new IntersectionObserver(
  ([entry]) => {
    entry.target.style.willChange = entry.isIntersecting ? 'transform' : 'auto';
  },
  { rootMargin: '200px' }
);
io.observe(figure);

Element enters the viewport — hint turns on. Scroll past — hint turns off, layer collapses, victim stops being a layer. rootMargin: '200px' prewarms the layer a bit before the element enters so the first animated frame doesn't jank on layer creation.

One caveat if the offending will-change was injected by a third-party library: this only works if the library sets the hint once (most do — in the constructor) and never re-asserts it on scroll. If it re-asserts, you're racing the library, and the fix is to either fork it or skip ahead to the scroll-timeline approach below.

Better still — in 2026 this works in Chrome, Edge, and Safari 26:

@keyframes parallax {
  from { translate: 0 30px; }
  to   { translate: 0 -30px; }
}

.figure {
  animation-name: parallax;
  animation-timing-function: linear;
  animation-timeline: view();
}

A note on translate instead of transform: translateY(...): the individual transform properties (translate, rotate, scale) have shipped everywhere since 2022 and ride the exact same compositor fast-path as the transform shorthand. Same performance, less typing, no risk of clobbering an existing transform on the element from a sibling rule.

Two footguns worth calling out. First, the animation shorthand resets animation-timeline back to auto, so if you do use it, the shorthand has to come before animation-timeline: view(). Second, Firefox refuses to play a scroll-driven animation without an explicit animation-duration — Chrome and Safari infer the full timeline range, Firefox does not. The longhand form above sidesteps both.

This is not a time-based animation. With animation-timeline: view(), animation progress is bound to the element's position in the scrollport — not to wall-clock time. The element does not move on its own. It moves only when you scroll, and the browser recomputes the translate on every frame from the current scroll position.

The boundaries are precise. view() 0% is the moment the subject's leading edge first crosses into the scrollport — when an element scrolling up from below first touches the viewport's bottom edge. view() 100% is the moment the trailing edge last leaves — when the element's bottom touches the viewport's top edge. The full scroll window during which the animation runs is therefore viewport height + element height pixels.

Between those two points, the translate is a continuous linear function of scroll position:

progress = (currentScrollY − scrollAtEntry) / (viewportHeight + elementHeight)
y        = 30px + (−60px) × progress         // applied as `translate: 0 <y>`

So for a 400 px tall image in an 800 px viewport with speed: 3:

Stop scrolling — the value freezes at the current progress. Scroll back — it reverses smoothly. This is exactly how a JS parallax library updates transform on every scroll event. The math is identical. The only difference: view() runs on the compositor instead of a scroll handler, so the main thread stays free.

The displacement values are not arbitrary either. Most JS parallax libraries expose a speed parameter that maps to a symmetric range like from translateY(speed × 10 px) to translateY(speed × -10 px). The 30px above corresponds to speed: 3. Pick the magnitude directly in CSS, no library required.

No main thread work. No will-change — the browser already knows the element animates a compositor-friendly property.

I kept writing this same six-line block every time I needed scroll-driven motion in a React app, so I packaged it: @ouvarov/scroll-parallax — 349 B of JS gzipped, no scroll listener, no useEffect, no IntersectionObserver. Just a typed wrapper around animation-timeline: view().

import { Parallax } from "@ouvarov/scroll-parallax";

<Parallax amplitude={30}>
  <img src="/hero.jpg" alt="" />
</Parallax>

Same compositor path as the raw CSS above — the component generates the keyframes and animation-timeline declaration for you, scoped per instance so sibling parallaxes don't bleed values into each other. Browsers without view() support render the element normally: no animation, no JS fallback, nothing to ship.

A diagnostic recipe

When you see a layer in DevTools you're not sure about:

1. DevTools → Layers (More tools → Layers if not enabled)
2. Sort by Memory estimate — biggest at the top
3. Click each layer, read Compositing Reasons
4. If the reason is Overlaps other composited content — this is a victim, not the trigger
5. Look at neighbor layers in z-order (below in DOM, above in z)
6. Find the one with an explicit reason — will-change, transform, filter, fixed, animation
7. That's the trigger. Ask: does this layer actually need to exist?

Half the time the answer is no. Someone added will-change: transform to optimize a hover effect that runs twice a session. Or a library injected the hint without asking.

If you find will-change as an inline style that is not in your CSS — it's almost certainly third-party. Open Sources, grep node_modules for willChange. That's where it lives.

Closing

will-change is not free. And the cost is not measured at the element you touched. It is measured at the element that overlap dragged in.

Before you add a promoter, look at what sits next to it on screen. The biggest neighbor is paying the bill.

will-change is a wish. Overlap is a law.