The following model explains potential layout costs rather than fixed pass counts or complexity. Measure real-page traces because cost depends on content, constraints, caching, and browser implementation.

1. Review of browser rendering process (performance prerequisite)

Whether it is Flex or other layouts, performance cannot bypass the browser rendering process:

1. Parse HTML → DOM
2. Parse CSS → CSSOM
3. DOM + CSSOM → Render Tree
4. Layout（Reflow）
5. Paint
6. Composite

⚠️ The biggest impact on performance is usually:

• Layout (reflow)
• Layout triggers chain calculation
• Frequently force synchronization of layouts

Flex belongs to the Layout stage layout algorithm, so we focus on the analysis:

Flex layout calculation complexity + reflow propagation range + dynamic change cost

2. Cost of the underlying algorithm of Flex layout

Flex is a two-stage layout algorithm (different from Block)

1️⃣ Spindle size calculation (first round)

Core steps:

1. Calculate each flex item:

   • flex-basis
   • min/max
   • Content dimensions (may trigger measurements)

2. Calculate total base dimensions

3. Determine whether it overflows

4. Allocate free space (grow or shrink)

If it involves:

• auto
• content
• Percentage
• Undetermined size

The browser must:

👉 Measure the content size of child elements first

This triggers:

• child element layout
• Possibly recursive calculations

Performance impact:

The complexity is close to:

成本随项目数量、内容测量和缓存命中情况变化

If nesting Flex:

嵌套和重复测量可能增加成本，不能据此给出通用复杂度

2️⃣ Cross-axis alignment (second round)

If present:

• align-items
• align-content
• stretch

Your browser may require:

👉 Run another round of size adjustment

Especially:

• height auto
• multi-line wrap
• Center vertically

This means:

Main-axis and cross-axis work are algorithm steps, not a guarantee of two complete browser layout passes.

3. Why is Flex heavier than Block?

Traditional block flow:

从上到下顺序计算
普通块布局也可能需要内容测量、百分比解析或重新布局，不能视为总是单次计算。

Flex：

必须先算所有子元素 → 再统一分配空间

That is to say:

Block is a "one-way flow" Flex is "whole coordination"

Overall coordination = more calculations

4. In what scenarios does performance bottleneck occur?

❗ 1. A large number of nodes (list)

For example:

• 1000 flex items
• Flex is nested inside each item

May occur:

• Multiple reflows
• Frequent measurements
• High main thread usage

Comparison:

• Simple block flow performance is more stable

❗ 2. Dynamically change the flex attribute

For example:

element.style.flex = "1";

will trigger:

• Parent container recalculation
• All brothers redistributed
• Child elements may be re-layout

This is:

Cascade reflow

❗ 3. Use auto / content / min-content

For example:

flex: 1 1 auto;

auto = need to measure content

Measure content = layout

If you resize frequently:

It will consume a lot of performance

❗ 4. Nested Flex Hell

flex
 └ flex
    └ flex
       └ flex

Each layer requires:

• Calculate subdimensions
• Then pass it back to the parent
• redistribute

Theoretically possible:

Nesting and dependencies can increase layout work; measure the actual cost.

5. Flex vs Grid performance comparison

🔹 Grid

• Requires biaxial calculation
• Track sizing may also require iteration and intrinsic measurement
• Faster when not dependent on content size

🔹 Flex

• More dependent on content size
• Spindle assignment is more complex
• Dynamically adjust more frequently

Summary:

Scenario	Recommendation
Single axis simple layout	Flex
Complex two-dimensional layout	Grid
Huge List	Block + Virtual Scroll
High-frequency dynamic changes	Try to avoid Flex

6. Real browser implementation (taking Chromium as an example)

Chrome uses:

• Blink Layout Engine
• Upgraded to LayoutNG after 2020

Flex in LayoutNG:

• Solve the model using constraints
• Multiple rounds of measurement
• subtree may be visited repeatedly

Performance key points:

• Constraint space calculation
• Fragment tree construction
• Min/max content measurement

7. How to optimize Flex from a performance perspective?

✅ 1. Try to avoid auto

Alternative:

flex: 1 1 0;

instead of:

flex: 1 1 auto;

A zero flex-basis can reduce some base-size measurement, while automatic minimum sizes and other constraints may still require intrinsic measurement.

✅ 2. Fixed size is better than content-driven

width: 200px;

Ratio:

width: auto;

More stable performance

✅ 3. Reduce nesting

Avoid:

Multi-layer flex wrapping

✅ 4. Use will-change (with caution)

Only used when animating:

will-change: transform;

Don't use it indiscriminately, it will increase memory

✅ 5. Use contain

contain: layout;

contain:layout establishes layout containment, but changes to the element’s own size can still affect outer layout; it is not absolute isolation.

very useful

✅ 6. Virtual scrolling

Don't render large lists directly:

• 1000 flex items
• Use virtual list

Both React/Vue have library support

8. How to compare performance

The original millisecond figures lacked a reproducible experiment and have been withdrawn. Compare these scenarios with identical content and viewport conditions:

Layout	Metrics to record
Block	Layout, Paint, and total duration
Simple Flex	Layout, Paint, and total duration
Nested Flex	Layout, Paint, and total duration
Complex Grid	Layout, Paint, and total duration

Record browser version, hardware, node count, CSS, sample count, and traces; layout names alone do not establish a performance ranking.

9. When is Flex performance not an issue?

Actually:

👉 On the normal business page (dozens of nodes)

Flex performance difference is almost negligible

Scenarios that really become a problem:

• Visual large screen
• Data dashboard
• Table rendering
• Low-end Android devices
• high frequency resize

10. Summarize one sentence

Flex performance features:

Sacrifice part of the layout calculation cost in exchange for strong dynamic adaptation capabilities

It's not slow, it's:

• The calculation is more complex
• Depend on content
• Easier to trigger multiple rounds of layout