4 ms·
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
by jimrandomh 1y ago
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.
- MountDoom 1y agoThis article is almost certainly AI-generated.
- hdjdndndba 1y ago[dead]
- tux3 1y agoSame experience here. Both consumed a lot of CPU, but they looked very similar on the perf graph, and neither missed any frames.
- b_e_n_t_o_n 1y agoYep. At one point it was probably the case that it always caused reflows but browsers have had so much investment into optimizations that it probably realizes those layout changes don't require reflows and skips them.
- pharrington 1y agoMoving an absolutely positioned element never caused a reflow, by design. The AI slop is just wrong.
- luciodale 1y agoThanks for the input! Indeed, the reflows were incredibly fast because I was using position: absolute, which meant the squares were not affecting anything else in the dom, but just their position (so cheap operation). I will add a note on the article on that... also I am improving the 'bad' example so the shuffle button triggers reflow in a significant way.