Not Just Colors and Sizes: Understanding How the Browser Actually Renders CSS

When you write CSS, it feels immediate.

You change a color.

Adjust a margin.

Add a transform.

And the page updates.

It’s easy to think of CSS as something the browser simply “applies” to HTML.

But that’s not quite what’s happening.

Because the browser doesn’t decorate the page.

It constructs it—step by step.

Two Separate Worlds

At the beginning, the browser doesn’t see a “styled page.”

It sees two independent sources of truth.

From HTML, it builds structure:

A tree of elements—what exists, how things are nested.

From CSS, it builds rules:

Selectors and declarations—what could apply, and how.

At this stage, nothing is styled yet.

Just two separate models:

• the DOM (structure)
• the CSSOM (styles)

They don’t mean anything visually until they meet.

Where Style Meets Structure

The browser then asks a simple but expensive question:

Which styles apply to which elements?

It walks through the DOM.

For each element, it checks matching selectors.

Class selectors.

Tag selectors.

Complex combinations.

Once matched, styles are attached.

Now the browser finally knows:

What each element should look like

But still not where.

Building What Will Actually Be Drawn

Next, the browser creates something new:

The render tree.

This is not the DOM.

It’s a filtered version of it.

Only visible elements remain.

Things like:

display: none

simply disappear from this stage.

Because if something won’t be seen, it won’t be rendered.

From Meaning to Position

Now comes layout.

The browser calculates:

• positions
• sizes
• spacing
• relationships between elements

This is where abstract structure becomes physical.

Where does this element sit?

How wide is it?

How does it affect others around it?

At this point, the browser knows where everything goes.

Turning Data Into Pixels

Then comes painting.

Now the browser draws:

• backgrounds
• text
• borders
• shadows

This is where the page becomes visible.

Not conceptually—but literally, as pixels on the screen.

The Final Assembly

Modern browsers don’t draw everything at once.

They split rendering into layers.

Then combine them efficiently in a final step called compositing.

This allows:

• smoother animations
• GPU acceleration
• partial updates instead of full redraws

Why Some Changes Feel “Heavy”

Not all CSS changes are equal.

Some affect only the final stage.

Others ripple backward through the entire pipeline.

Changing something like:

transform: translateX(100px)

often skips layout and painting.

It only affects compositing.

But changing:

width: 200px

forces layout again.

Which may affect many elements—not just one.

A Subtle Shift

At this point, CSS stops looking like “styling.”

And starts looking like:

Instructions for a rendering engine

Each property you write participates in a process:

• structure
• matching
• layout
• paint
• composition

And depending on what you change, you might restart that process at different stages.

Not Everything Is Immediate

When you update styles with JavaScript, the browser doesn’t always act instantly.

It batches work.

Schedules recalculations.

Optimizes what can be delayed.

Because rendering is expensive.

And doing less of it is the difference between smooth and janky.

A Final Thought

It’s easy to think of CSS as a layer on top of HTML.

But it’s not a layer.

It’s part of a pipeline.

A process that turns abstract rules into geometry—

and geometry into pixels.

And once you see that process,

you stop asking:

“Why did this change affect performance?”

And start asking:

“Which part of the pipeline did I just trigger?”