Render Tree, Layout, Paint, and Reflow: What Causes Jank

The problem

Some interfaces feel slow even when “nothing fully freezes.”

Scroll feels odd. Animation feels heavy. The click responds, but the screen stutters.

This kind of visual discomfort often gets a practical name:

jank

And it is tricky because many people try to explain it in the shortest possible way:

• “React re-rendered”
• “the CSS is heavy”
• “JavaScript blocked”

All three phrases may touch the problem.

But they still do not explain the full path.

Mental model

To design or debug UI in the browser, it helps to think in four layers:

1. the browser understands the relevant visual structure
2. it calculates sizes and positions
3. it paints pixels
4. it composes the result on screen

In more common language:

• render tree
• layout
• paint
• composition

Jank appears when that work becomes too expensive for the expected interaction pace.

Breaking the problem down

Render tree is not the full DOM in the abstract

The browser starts from structure and styles to understand what needs to participate in rendering.

Not every node enters in the same way.

What matters here is not memorizing exact implementation details.

It is understanding that there is a visual structure derived from what needs to appear.

Layout calculates geometry

Layout answers questions like:

• how big is this element?
• where does it sit?
• what changes around it when it grows?

When you change properties that affect geometry, the browser may need to recalculate that map.

That can cost a little or a lot.

It depends on how many elements and relationships enter the domino effect.

Paint draws the appearance

After geometry, the browser may need to repaint.

That includes things like:

• color
• shadow
• border
• text
• image

Not every repaint is terrible.

But frequent repainting over large areas also costs.

Reflow is the nickname for layout pain

In practical discussion, many people use reflow to talk about layout recalculation triggered by geometry changes.

Examples of changes that tend to be more sensitive:

• changing width
• changing height
• inserting content that pushes other elements
• reading a DOM measure after repeatedly writing styles

When you mix reading and writing layout without care, you can force the browser to recalculate more times than needed.

Simple example

Imagine an animated list.

A more expensive version:

• on every frame you change top and height
• then read offsetHeight
• then write again

That cycle tends to force repeated layout work.

A cheaper version in many cases:

• move with transform
• avoid reading measures all the time
• group reads and writes

It is not that transform solves everything.

But it usually avoids some of the heaviest geometry work.

Common mistakes

• Blaming the framework without looking at the kind of visual change.
• Treating every repaint like the same catastrophe.
• Reading DOM measurements right after several writes without noticing the cost.
• Assuming only animation causes jank.
• Ignoring that JavaScript, layout, and paint all compete for the same smoothness window.

How a senior thinks about it

People with more experience usually look at jank and ask:

Is the bottleneck in JavaScript, in layout, in paint, or in the combination of them?

That question is strong because it avoids guessing.

Instead of optimizing in the dark, it pushes the investigation toward the expensive stage that actually matters.

What the interviewer wants to see

In interviews, this topic appears to test whether you understand the browser beyond the framework.

The evaluator wants to see whether you:

• distinguish layout from paint
• understand why some changes cost more
• connect jank to the main thread and rendering
• avoid simplifications like “rerender equals bug”

A strong answer often sounds like this:

Jank appears when the browser has to do too much visual work for the time window of the interaction. I would try to discover whether the cost is in JavaScript, in layout recalculation, in paint, or in a combination of them.

Smooth interfaces do not come from memorizing terms. They come from understanding that not every visual change charges the same bill.