EUR/USD 1.0921 ▲
GBP/USD 1.2734 ▼
USD/JPY 149.82 ▲
```
```css
.ticker {
overflow: hidden;
}
.ticker__track {
display: inline-flex;
gap: 2rem;
white-space: nowrap;
/* We only move transform: the compositor's "cheap" property */
}
```
And the scrolling logic, in JavaScript with `requestAnimationFrame` to move the track frame by frame:
```js
// The track scrolls by mutating transform every frame.
// Since it's a JS-driven animation, Chrome won't promote it on its own.
const track = document.querySelector(".ticker__track");
let x = 0;
function tick() {
x -= 0.6;
if (-x >= track.scrollWidth / 2) x += track.scrollWidth / 2;
track.style.transform = `translateX(${x}px)`;
requestAnimationFrame(tick);
}
requestAnimationFrame(tick);
```
On paper it's a textbook example: we only move `transform`, we don't touch properties that trigger layout. And yet Paint flashing paints the ticker's area green every frame, and the `#document` repaints nonstop while the ticker scrolls.
The problem isn't **which** properties we animate, but **where** the moving pixels live.
## The explanation: two threads, one layer
To understand why `transform` isn't enough, we have to separate two things that happen on different threads.
- **Main Thread:** runs JavaScript, computes styles (_Recalculate Style_), computes geometry (_Layout_) and rasterizes pixels (_Paint_). Everything expensive lives here.
- **Compositor Thread:** takes the already-rasterized layers and combines them on screen. It can move them, scale them and change their opacity **without repainting them**, because it works with already-generated bitmaps.
The promise of `transform` and `opacity` is this: if a layer is already rasterized, the compositor can move or fade it on its own, without bothering the main thread and without repainting. Free animation on the GPU.
But that promise comes with **a condition almost nobody mentions**: the element that moves has to be on **its own composited layer**. If the ticker shares a layer with the `#document`, the compositor can't move it in isolation, because moving that piece would leave a hole in the bitmap of the whole page. The browser's only way out is to **re-rasterize the entire document layer** on every frame of the animation.
That's the trap: using `transform` doesn't give you compositing by magic. It gives you compositing **only if the element already has its own layer**. Without promotion, `transform` rasterizes like anything else, and drags the whole layer that contains it.
> **An honest caveat:** a declarative animation with `@keyframes` of `transform`/`opacity` usually does get promoted automatically, Chrome detects the animation and gives it its own layer. The case that repaints is precisely this one: an animation **driven by JavaScript** (changing inline styles frame by frame, or kicking off transitions from code). The browser doesn't know in advance that it's a continuous animation, so it won't promote the element on its own. That's why real-time data _tickers_ are repeat offenders for this problem.
## The fix: promote the element to its own layer
The fix is to tell the browser explicitly that this element is going to change its `transform`, so it reserves a composited layer before the movement starts.
```css
.ticker__track {
display: inline-flex;
gap: 2rem;
/* Promote the element to its own composited layer */
will-change: transform;
}
```
Flip the toggle in the demo to see the change live: the `#document`'s repaint counter freezes and the ticker gets its own composited layer.
