Performance-Fresser ■ Episode 04
Flexbox is a genuinely excellent layout model. It handles single-axis distribution with a clarity that CSS had lacked for decades. It is also, by a comfortable margin, the most overused property in modern front-end development. Not because developers are lazy, but because it works. It works for navigation bars. It works for card layouts. It works for centering. It works for page scaffolding. It works for everything, in the same way that a Swiss army knife works for surgery. Technically functional. Architecturally questionable.
The problem is not Flexbox. The problem is display: flex as a
default. The moment every container in a component tree becomes a flex
container, the browser stops doing simple layout and starts doing algebra.
The Calculation Problem
Flexbox computes intrinsic sizes for every child on every layout pass. It measures content, applies flex-grow and flex-shrink ratios, resolves flex-basis against available space, and distributes remaining pixels. This is not a simple lookup. It is a constraint-solving algorithm, and it runs every time the layout is invalidated.
For a single container with a handful of children, the cost is negligible. The browser is very good at this. The trouble begins when flex containers nest inside flex containers inside flex containers. Three levels deep means three calculation passes per frame during scroll or resize. Five levels deep, and the browser is solving a system of equations that would make a university mathematics department reach for the coffee.
LinkedIn, for example, nests Flexbox five to eight levels deep in its feed elements. Every post card is a flex container containing flex containers containing flex containers. Each scroll frame requires the browser to recalculate the intrinsic sizes of every element in the nesting chain. This is why scrolling LinkedIn on a mid-range phone feels like wading through treacle. It is not the network. It is not the images. It is the layout engine doing redundant arithmetic on every frame.
The Numbers
Layout cost is not theoretical. Chrome DevTools will show it to you, frame by frame, in the Performance panel. The numbers tell a story that no amount of architectural hand-waving can refute.
Nested Flexbox thrashing consumes 3 to 15 milliseconds per frame. At 60 frames per second, each frame has a budget of 16.6 milliseconds for everything: JavaScript, layout, paint, composite. Spending up to 15 of those milliseconds purely on layout arithmetic leaves almost nothing for the rest of the rendering pipeline.
CSS Grid, by contrast, resolves layout in under one millisecond. It calculates the grid template once, places items according to explicit coordinates, and is finished. There is no intrinsic-size negotiation between parent and children, no recursive constraint solving, no repeated passes through the nesting hierarchy. One calculation. Done.
Inline-block is faster still, at under half a millisecond. It does not negotiate sizes at all. Elements take their intrinsic width, line up horizontally, and wrap when space runs out. No flex algorithm. No grid algorithm. Just the oldest, simplest layout mode doing what it has done since the late 1990s.
The Mobile Bill
On a desktop workstation, 15 milliseconds of layout thrashing is an annoyance. On a mobile device, it is a visible problem. Low-end phones have slower CPUs, less memory bandwidth, and thermal constraints that throttle performance under sustained load. A layout that consumes 90% of the frame budget on a Snapdragon 8 Gen 3 will simply drop frames on a Snapdragon 680.
But the cost is not only visual. Every millisecond the CPU spends on layout is a millisecond it draws power. Nested Flexbox thrashing during scroll is a battery drain. The user does not see it in the frame rate alone. They see it in the battery percentage at the end of the day. The electricity bill for a layout choice they never made.
When Flexbox Is Right
Flexbox is the correct tool for single-axis layouts with dynamic sizes. A navigation bar where items need to distribute evenly. A toolbar with items that grow and shrink based on available space. A row of tags where the content determines the width. These are one-dimensional problems, and Flexbox solves them with elegance and precision.
It is also the correct tool for space distribution patterns that
the simpler models cannot handle. justify-content: space-between,
flex-wrap with variable-width items, and alignment of items
with unknown sizes are genuine Flexbox territory. These problems exist.
Flexbox was designed for them. It handles them beautifully.
When Grid Is Right
The moment your layout has two dimensions, Grid is not merely better. It is categorically different. A page layout with header, sidebar, content, and footer. A card grid. A dashboard with panels. These are two-dimensional structures, and expressing them in Flexbox requires nesting: a flex row containing flex columns containing flex rows. Each level adds a calculation pass. Grid expresses the same structure in a single declaration and resolves it in a single pass.
When Simpler Is Right
Not every layout problem requires a layout algorithm at all. Centering
a block of text does not need Flexbox. Since 2024, align-content: center
works on block-level elements in all major browsers. No flex container.
No grid container. Just a single property on a plain div.
A horizontal list of inline elements does not need Flexbox either.
display: inline-block has been placing elements in a row
since before some front-end developers were born. It involves no intrinsic
size calculation, no constraint solving, and no recursive layout passes.
It is the layout equivalent of a bicycle: it gets you there with zero
fuel consumption, provided you are not trying to cross an ocean.
The Decision Framework
The question is not whether to use Flexbox. Flexbox is a fine tool. The question is a single diagnostic: is this layout one-dimensional or two-dimensional?
One axis, dynamic sizes, space distribution: Flexbox. Or, if the pattern is simple enough, something even lighter. Two axes, explicit placement, structured areas: Grid. No exceptions. No "but I know Flexbox better." Familiarity is not an engineering argument. The browser does not care which API you prefer. It cares how many constraint passes it must execute per frame.
The right layout model is the one that solves the problem with the fewest calculations. Not the one you happen to type from muscle memory.
Flexbox is a scalpel. It was designed for precise, single-axis work, and it does that work superbly. But when the scalpel becomes the default tool for every task, including the ones that need a set square, the cost compounds silently. Frame by frame. Scroll by scroll. Battery percent by battery percent. The tax is invisible until someone opens the Performance panel and watches the browser do arithmetic it was never asked to avoid.