Why Width Animations Trigger Layout & the 273ms Benchmark
This article explains what the 273.4 ms benchmark for width animations actually measures, why animating the width property forces the browser to recalculate layout on every frame, and how to interpret that number in real-world performance work. In short, the benchmark shows that a single width transition on a typical element takes about a quarter of a second of main-thread work, which is why it can cause jank, but the number is only meaningful when you understand what layout, paint, and compositing each involve.
What the 273.4 ms Benchmark Really Shows
The 273.4 ms figure comes from a widely shared performance test that measures how long it takes the browser to complete a single width transition on a simple element (like a div) using CSS transition: width 0.3s or a JavaScript-driven animation. The test records the total time spent on the main thread, including style recalculation, layout, and paint, for one frame of that animation. The number is often quoted as “proof� that width animations are slow, but it is actually a worst-case synthetic measurement: it uses a large element, a slow device, and no GPU acceleration, so it represents the upper bound of what you might see, not the typical experience on modern hardware.
What the benchmark does not show: it does not measure the full animation duration (0.3 seconds), it does not include compositing time (which happens on the GPU), and it does not account for the fact that many width changes are small or infrequent. The real takeaway is that width animations trigger layout, and layout is one of the most expensive operations in the rendering pipeline, so even a single frame can take tens of milliseconds on low-end devices.
How the Browser Renders a Page: The Pipeline
To understand why width is slow, you need to know the five main steps the browser takes to display a frame:
- JavaScript – runs any scripts that modify the DOM or styles.
- Style calculation – figures out which CSS rules apply to which elements.
- Layout (reflow) – computes the geometry (position and size) of every element. This is where width changes land.
- Paint – fills in pixels for text, colors, images, shadows, etc.
- Compositing – layers are drawn on the GPU and combined into the final screen image.
When you animate width, the browser must run steps 2–4 on every frame (usually 60 times per second). If any of those steps takes longer than 16.7 ms (the budget for 60 fps), the frame is dropped, causing visible jank. The 273.4 ms benchmark is essentially measuring the time for one such frame on a slow device, which is why it is so high.
Why Width Specifically Triggers Layout
Layout is the process of calculating the position and size of every element in the document. The width of an element directly affects its own size, and also the size of its parent, its siblings (in a flex or grid container), and any elements that depend on it via percentage widths, margins, or absolute positioning. When you change width, the browser cannot just repaint that one element; it must recalculate the geometry of the entire affected subtree. This is called a layout thrash if it happens repeatedly.
In contrast, properties like transform and opacity do not affect layout. They are handled in the compositing step, which runs on the GPU and does not require the main thread to recalculate geometry. That is why animating transform: scaleX() is so much smoother: it only triggers paint and compositing, not layout.
How to Measure the Real Cost on Your Page
The 273.4 ms number is a synthetic benchmark, not a universal constant. To know how much a width animation costs on your site, you need to measure it in your own environment. The Chrome DevTools Performance panel (and similar tools in Firefox and Safari) lets you record a profile while the animation runs. Look for the “Layout� and “Style� rows: if they show long purple and yellow blocks, that is your real cost.
Here is a simple way to test:
- Open DevTools and go to the Performance tab.
- Click “Record� and start the animation.
- Stop recording and look at the “Summary� tab: it will show the percentage of time spent in scripting, rendering, and painting.
- If “Rendering� is high, layout is the culprit.
Also check the FPS meter: if it drops below 30 during the animation, you have a problem. The 273.4 ms benchmark would cause a frame drop on almost any device, but a real-world width change on a small element might only take 5–10 ms, which is fine.
Common Misconceptions and Mistakes
One common misconception is that using will-change: width or transition: width automatically fixes performance. It does not. will-change only hints the browser to prepare a compositor layer, but it cannot skip layout if the property itself requires it. Another mistake is assuming that all width animations are equally bad: animating the width of a fixed-position element with no descendants is much cheaper than animating a flex item that causes its siblings to move.
Another error is measuring only the first frame. The 273.4 ms benchmark measures one frame, but the total cost of a 0.3-second animation is the sum of all frames. If each frame takes 20 ms, the animation will run at 50 fps, which is acceptable for some content but not for UI elements that need to feel snappy.
Alternatives to Width Animations
If you need a smooth size animation, the standard solution is to use transform: scaleX() or scaleY() instead of width. For example, to expand a horizontal bar from 0 to 100% width, you can set the element’s width to 100% and animate transform: scaleX(0) to scaleX(1). This only triggers compositing, which is GPU-accelerated and typically runs at 60 fps.
However, transform does not change the element’s layout space: it visually scales the element but does not push other elements out of the way. If you need the content below to reflow (like an accordion), you have two options: animate max-height (which is cheaper than width but still triggers layout) or use the Web Animations API with a manual layout calculation that only updates once at the end. The latter is more complex but gives the best performance.
When a Width Animation Is Acceptable
Not every width animation is a performance disaster. If the element is small, the page is simple, or the animation is short and infrequent, the cost may be negligible. For example, a progress bar that grows once per second on a page with few elements will not cause noticeable jank. The 273.4 ms benchmark is a worst-case scenario; real-world cost depends on:
- The number of elements affected by the layout change.
- The device’s CPU speed.
- The current load on the main thread.
- Whether the animation is triggered by scroll or by a user click.
If you must animate width, keep the affected subtree small, avoid animating large containers, and consider using requestAnimationFrame to batch layout changes. But for most UI animations, transform is the safer choice.
Frequently Asked Questions
Is 273.4 ms the time for the whole animation?
No, it is the time for a single frame of the animation. A full 0.3-second animation would take many frames, so the total time is much higher. The number is meant to show how expensive one frame is, not the duration of the animation.
Does using transition: width make it faster?
No, CSS transitions do not change the rendering pipeline. They only smooth the value changes over time. The browser still has to run layout for each intermediate value, so the cost per frame is the same as if you set the width directly.
Why does transform: scaleX() not trigger layout?
Because transform is a compositor-only property. The browser creates a new layer for the element and applies the transform on the GPU, without recalculating the document’s layout. This is why it is so much faster.
Can I use width: auto animations?
Animating to or from width: auto is not possible with CSS transitions because the browser cannot interpolate between a length and auto. You would need to use JavaScript to calculate the target width and set it explicitly, which still triggers layout.
Is the 273.4 ms benchmark from a real browser?
The number is often cited from a synthetic test on a low-end mobile device, but the exact source is unclear. It is not an official benchmark from any browser vendor. Treat it as an illustration of worst-case cost, not a universal measurement.
What is the best way to animate an accordion?
For a smooth accordion, animate max-height from 0 to a large value (like 1000px) with a transition. This triggers layout but only on the element itself, not its siblings. For even better performance, use the Web Animations API to animate height with a fixed value, but that requires JavaScript to measure the content height.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.