A 16.67 Millisecond Frame

This article says that using `transform` is faster than using `left` and `top` because `transform` is handled on-GPU, while `left` and `top` are not. This is a myth. I tried the demo page in the Firefox profiler; neither the optimized nor the unoptimized version missed frames. I tried it in the Chrome profiler; the unoptimized version missed frames, but the time was clearly labelled by the profiler as being GPU time, not reflow. Neither browser did reflows (or, all reflows were fast enough to not have any profiler-samples associated.)

The reality is that browsers contain large piles of heuristic optimizations which defy simple explanation. You simply have to profile and experiment, every time, separately.

The "demo" is kind of bologna.

1) The code that is running is not what's presented; it executes (non-transpiled) vanilla JS.* Why not just show that?

2) Removing the box shadow massively makes the two closer in performance.

3) The page could just be one sentence: "Reflowing the layout of a page is slower than moving a single item." GPU un-related.

---

*Code that actually is running:

```js

        , u = t => {
        h && clearTimeout(h),
        l.forEach( (e, s) => {
            const {top: o, left: n} = m[r[s]];
            t ? (e.style.transform = "translate(0px, 0px)",
            e.style.opacity = "0.7",
            e.offsetHeight,
            e.style.transform = `translate(${n}px, ${o}px)`) : e.style.transform = `translate(${n}px, ${o}px)`,
            e.style.top = "",
            e.style.left = ""
        }
        ),
        t && (h = window.setTimeout( () => {
            l.forEach(e => e.style.opacity = "1")
        }
        , 500))
    }
        , d = t => {
        y && clearTimeout(y),
        l.forEach( (e, s) => {
            const {top: o, left: n} = m[r[s]];
            e.style.top = `${o}px`,
            e.style.left = `${n}px`,
            e.style.transform = "",
            t && (e.style.boxShadow = "0 14px 28px rgba(239,68,68,0.45)") // REMOVING THIS LINE = BIG DIFFERENCE
        }
        ),
        t && (y = window.setTimeout( () => {
            l.forEach(e => {
                e.style.boxShadow = "none"
            }
            )
        }
        , 500))
    }
           

```

This is both informative and kind of amazing that anything works at all. Talk to anyone who did graphics at the turn of the century and you'll hear about "racing the beam" which you had only 16.67 mS before vertical retrace took you back to 0,0. Why double and triple buffering was invented, and how "animation time" is skewed by "frame time" and if you want to keep your animations from jumping or jittering you really needed to know how many milliseconds between the last frame and the one your rendering will take so that all your assets are rendered where they should be at that time.

There is a lot of fun programming to be had in that space.

How do we even see anything on a browser? How do pixels turn into shapes, color, and movement?

Every time we scroll, hover, or trigger an animation, the browser goes through a whole routine. It calculates styles, figures out layout, paints pixels, and puts everything together on screen. All of that happens in just a few milliseconds.

It’s kind of wild how much is happening behind what feels instant. And the way we write code can make that process either smooth and fluid or heavy and janky.

I wrote an article that walks through this step by step, with a small demo showing exactly how these browser processes work and how a few CSS choices can make a big difference.

For everyone reading, I made some tweaks to the article after reading some key feedback. In fact, thanks to all commenting :)

Correction: an 8.33 ms frame. Screens are 120 Hz now :)

As an early 2000’s game dev - I weep.

Scrolling? Animations? LOL.