DEV Community: koushikmaya

Also added my Handwritten notes at the end .please do check it out.

koushikmaya — Mon, 10 Aug 2026 09:52:42 +0000

koushikmaya

Aug 10

Understanding the Browser Rendering Pipeline: DOM, CSSOM, Layout, Paint, Compositing & Layout Thrashing

#webdev #css #performance #frontend

7 min read

Understanding the Browser Rendering Pipeline: DOM, CSSOM, Layout, Paint, Compositing & Layout Thrashing

koushikmaya — Mon, 10 Aug 2026 09:39:27 +0000

Understanding the Browser Rendering Pipeline: From DOM to Pixels 🚀

A beginner-friendly look at DOM, CSSOM, Render Tree, Layout, Paint, Compositing, Critical Rendering Path, and Layout Thrashing.

Introduction

While working on my Week 2 frontend tasks in my training, I wanted to understand what actually happens inside the browser when we load a webpage.
I had heard terms like DOM, CSSOM, reflow, repaint, and compositing, but I didn't fully understand how they were connected.
So I decided to learn the browser rendering pipeline and use Chrome DevTools Performance to see some of these concepts in practice.

This post covers what I learned and the small experiment I performed on layout thrashing.

📌 What I Learned

In this learning session, I covered:

DOM Construction

CSSOM Construction

Render Tree

Style Calculation

Layout / Reflow

Paint / Repaint

Compositing

Critical Rendering Path

Layout Thrashing

Batching DOM Reads and Writes

- Chrome DevTools Performance

🔄 Browser Rendering Pipeline

At a high level, the browser goes through something like this:

HTML
  ↓
DOM
  ↓
CSS
  ↓
CSSOM
  ↓
Style Calculation
  ↓
Render Tree
  ↓
Layout
  ↓
Paint
  ↓
Compositing
  ↓
Screen

Let's understand each stage.

1️⃣ DOM Construction

DOM stands for Document Object Model.
When the browser receives HTML, it parses it and creates a tree-like structure.
For example:

<body>
    <h1>Hello</h1>
    <p>Welcome</p>
</body>

The browser creates something conceptually like:

Document
└── html
    └── body
        ├── h1
        └── p

This is the DOM tree.

Simple way to remember

DOM = What elements exist?

2️⃣ CSSOM Construction

CSSOM stands for CSS Object Model.
The browser also parses CSS and creates a representation of the CSS rules.
For example:

h1 {
    color: blue;
    font-size: 32px;
}
p {
    color: gray;
}

The CSSOM helps the browser understand how the elements should be styled.

Simple way to remember

DOM   → What exists?
CSSOM → How should it look?

3️⃣ Style Calculation

Now the browser needs to figure out which styles actually apply to each element.
It considers things such as:

CSS selectors
Cascade
Specificity
Inheritance
Browser default styles
Media queries
CSS variables For example:

p {
    color: red;
}
.article p {
    color: blue;
}

4️⃣ Render Tree

The browser combines the DOM and CSSOM to determine what actually needs to be rendered.

DOM + CSSOM
     ↓
Style Calculation
     ↓
Render Tree

The Render Tree isn't exactly the same as the DOM.
For example:

.hidden {
    display: none;
}

The element still exists in the DOM, but it doesn't participate in the normal rendered layout.

Simple way to remember

Render Tree = What actually participates in rendering?

5️⃣ Layout / Reflow

Once the browser knows what needs to be rendered, it needs to calculate the size and position of the elements.
This is the Layout stage.
It calculates things like:

Width

Height

Position

Margin

Padding

Text positioning For example:

.card {
    width: 300px;
    height: 200px;
}

The browser needs to calculate where the card is and how much space it occupies.

Simple way to remember

Layout = Where is everything and how big is it?

Layout is also commonly referred to as reflow.

6️⃣ Paint / Repaint

After calculating the layout, the browser needs to draw the page.
This is the Paint stage.
Paint deals with things such as:

Text

Backgrounds

Borders

Images

Shadows

Gradients For example:

.card {
    background: white;
    border: 1px solid #ddd;
    box-shadow: 0 4px 10px gray;
}

These visual details need to be painted.

Simple way to remember

Paint = Draw what the user should see.

If something visual changes, the browser may need to paint that area again. This is commonly called a repaint.

7️⃣ Compositing

After painting, the browser may have different painted surfaces or layers that need to be combined.
That's where Compositing comes in.

Layer 1
   +
Layer 2
   +
Layer 3
   ↓
Compositing
   ↓
Screen

Properties such as:

transform
opacity

can often be handled efficiently by the compositor.
This is one reason these properties are commonly used for animations.
For example:

.box {
    transform: translateX(100px);
}

8️⃣ Critical Rendering Path

Now we can put everything together.
The simplified Critical Rendering Path looks like this:

HTML
  ↓
DOM

CSS
  ↓
CSSOM

DOM + CSSOM
  ↓
Style Calculation
  ↓
Render Tree
  ↓
Layout
  ↓
Paint
  ↓
Compositing
  ↓
Screen

JavaScript can modify the DOM or CSS, which may cause parts of this process to run again.

This is where frontend performance becomes important.

🧪 Practical Experiment With Chrome DevTools

Learning the theory was useful, but I wanted to actually see what was happening.
So I used my Week 2 responsive landing page and opened:

Chrome DevTools
→ Performance

I recorded the page load and inspected the Main thread.
I found rendering-related activities such as:

Recalculate Style
Layout
Paint
Composite / Commit

This helped me connect the theory with what the browser was actually doing.
Instead of just reading:

"The browser performs layout and paint."

I could actually see rendering activity in DevTools.

🔥 Layout Thrashing Experiment

The most interesting part of the experiment was layout thrashing.
I created a simple page with multiple boxes and used JavaScript to change their height and immediately read their height.

for (const box of boxes) {
    box.style.height = "100px";
    console.log(box.offsetHeight);
}

Here:

box.style.height = "100px";

is a write because I'm changing the style.
And:

box.offsetHeight

is a layout read because I'm asking the browser for the current height.
So the pattern becomes:

WRITE
  ↓
READ
  ↓
WRITE
  ↓
READ

When layout has been invalidated, reading layout information such as offsetHeight can require the browser to synchronously update layout.

Doing this repeatedly can lead to layout thrashing.

🤔 Why Is `offsetHeight` Important?

Some properties require the browser to provide up-to-date layout information.
Examples include:

element.offsetWidth
element.offsetHeight
element.clientWidth
element.clientHeight
element.getBoundingClientRect()

If we've just changed something that affects layout and then immediately request one of these values, the browser may need to perform layout work before returning the result.

❌ The Problem: Layout Thrashing

The problematic pattern is:

for (const box of boxes) {
    box.style.height = "100px";
    console.log(box.offsetHeight);
}

Conceptually:

WRITE → READ
WRITE → READ
WRITE → READ

This can cause unnecessary synchronous layout work

✅ Fixing Layout Thrashing

The basic solution is to separate reads and writes.
Instead of:

WRITE → READ
WRITE → READ
WRITE → READ

we can do:

READ
READ
READ
  ↓
WRITE
WRITE
WRITE

The optimized version:

// READ
for (const box of boxes) {
    console.log(box.offsetHeight);
}
// WRITE
for (const box of boxes) {
    box.style.height = "100px";
}

This gives the browser a better opportunity to batch the rendering work.

📊 Before vs After

❌ Before

for (const box of boxes) {
    box.style.height = "100px";
    console.log(box.offsetHeight);
}

Pattern:

WRITE → READ
WRITE → READ
WRITE → READ

✅ After

for (const box of boxes) {
    console.log(box.offsetHeight);
}
for (const box of boxes) {
   box.style.height = "100px";
}

Pattern:

READ
READ
READ
   ↓
WRITE
WRITE
WRITE

🔍 What I Observed in DevTools

I recorded both versions using the Performance panel.
I was able to inspect:

JavaScript execution
Recalculate Style
Layout activity
Paint
Compositing / Commit One thing I learned during the experiment is that Chrome is heavily optimized, so we shouldn't expect to see one separate Layout event for every single operation. The important part was understanding why alternating layout writes and reads can cause synchronous rendering work. --- # 💡 Key Takeaways | Concept | What I learned | | --- | --- | | DOM | Represents the structure of the HTML document. | | CSSOM | Represents the CSS rules. | | Render Tree | Determines what participates in rendering. | | Layout | Calculates the size and position of elements. | | Paint | Draws the visual appearance. | | Compositing | Combines painted surfaces/layers into the final frame. | | Layout Thrashing | Can happen when layout-affecting writes and layout reads are repeatedly mixed. | | Performance Optimization | Batch DOM/layout reads and writes when possible. | | DevTools | Performance tools are useful for understanding what the browser is actually doing instead of simply guessing. | --- # 🎯 What I Learned From This Before doing this experiment, I mostly thought about HTML, CSS, and JavaScript as separate parts of frontend development. Now I have a better understanding of how they connect:

HTML
 ↓
DOM
 ↓
CSSOM
 ↓
Render Tree
 ↓
Layout
 ↓
Paint
 ↓
Compositing
 ↓
Screen

I also learned that the way JavaScript interacts with the DOM can affect browser rendering performance.

The layout-thrashing experiment was especially useful because I could see how a simple operation like reading `offsetHeight` can become important when it is repeatedly mixed with style changes.

🏁 Conclusion

This was one of those topics that made much more sense after actually experimenting with it.
Instead of only reading about reflow, repaint, and compositing, I used Chrome DevTools to observe the browser's rendering work.
The biggest lesson I took from this experiment is:

Don't just learn how the browser works. Use DevTools to see it working.

This experiment gave me a better understanding of what happens behind the scenes when the browser turns our HTML, CSS, and JavaScript into pixels.

🛠️ Practical Work

As part of my Week 2 learning, I worked on:

✅ Responsive landing page

✅ Chrome DevTools Performance analysis

✅ Layout, Paint and Compositing investigation

✅ Layout thrashing experiment

✅ Batched DOM reads and writes

✅ Before/after performance comparison ## Tools Used

HTML

CSS

JavaScript

Chrome DevTools

- VS Code

📚 Final Note

I'm still learning frontend performance, but this experiment helped me understand that writing frontend code isn't only about making the page look correct — it's also about understanding how the browser processes that code.

📝 My Handwritten Notes

I also made handwritten notes while learning these concepts. They helped me understand the browser rendering pipeline and remember the key points.
Here are my notes:
Handwritten notes - Browser Rendering Pipeline

CSS Architecture

koushikmaya — Mon, 10 Aug 2026 06:21:17 +0000

Responsive CSS: From Mobile-First Design to Modern Styling

Responsive design is about creating websites that work well across mobile, tablet, and desktop screens. In this post, I learned some important techniques for building responsive and maintainable CSS.

1. Mobile-First Media Queries

Mobile-first means writing the base CSS for smaller screens first and then enhancing the layout for larger screens.

/* Mobile */
.card {
    width: 100%;
}

/* Tablet */
@media (min-width: 768px) {
    .card {
        width: 70%;
    }
}

/* Desktop */
@media (min-width: 1024px) {
    .card {
        width: 50%;
    }
}

The main idea is:

Mobile → Tablet → Desktop

min-width is commonly used for mobile-first development because styles are progressively added as the screen gets larger.

`min-width` vs `max-width`

min-width: applies styles when the screen is at least the specified width.
max-width: applies styles when the screen is at most the specified width.

For example:

@media (max-width: 768px) {
    h1 {
        font-size: 20px;
    }
}

One important lesson I learned: CSS media queries belong inside `<style>` or a CSS file, not inside `<script>`.

2. Fluid Typography

Fixed font sizes don't always work well across different screen sizes. Fluid typography allows text to adapt to the viewport.

`rem`

rem is relative to the root font size.

h1 {
    font-size: 2rem;
}

If the root size is 16px, 2rem is 32px.

`vw`

vw is relative to the viewport width.

h1 {
    font-size: 5vw;
}

However, using only vw can make text too small or too large.

`clamp()`

clamp() provides a minimum, flexible value, and maximum:

h1 {
    font-size: clamp(1.5rem, 4vw, 3rem);
}

This allows the font size to grow smoothly while keeping it within limits.

3. Responsive Images

Images can consume a lot of bandwidth, so responsive images help browsers choose an appropriate image for the device.

`srcset`

<img
    src="small.jpg"
    srcset="
        small.jpg 400w,
        medium.jpg 800w,
        large.jpg 1200w"
    sizes="100vw"
    alt="Mountain">

srcset provides multiple image sizes, allowing the browser to choose an appropriate resource.

`<picture>`

picture is useful when different images should be displayed at different screen sizes.

<picture>
    <source
        media="(min-width: 1000px)"
        srcset="desktop.jpg">
    <source
        media="(min-width: 600px)"
        srcset="tablet.jpg">
    <img src="mobile.jpg" alt="Nature">
</picture>

4. BEM Naming Convention

BEM stands for:
Block → Element → Modifier
It helps keep CSS class names organized and reduces naming conflicts.

<div class="card card--dark">
    <img class="card__image">
    <h2 class="card__title">
        Product
    </h2>
    <p class="card__text">
        Description
    </p>
</div>

The structure is:

Block
.card
Element
.card__title
Modifier
.card--dark

BEM makes larger CSS projects easier to understand and maintain.

5. Utility-First Styling

Utility-first CSS uses small, reusable classes to build a component.
A popular example is Tailwind CSS:

<button class="bg-blue-500 text-white p-4 rounded">
    Submit
</button>

Each utility generally performs a specific styling job.

Advantages

Fast development
Reusable utility classes
Consistent styling
Less custom CSS ### Disadvantage HTML can become crowded with many classes. --- ## 6. Component-Scoped Styling CSS Modules are an example of component-scoped styling.

/* Button.module.css */
.button {
    background: blue;
    color: white;
    padding: 10px;
}

Then in a component:

import styles from "./Button.module.css";
function Button() {
    return (
        <button className={styles.button}>
            Submit
        </button>
    );
}

The styles are scoped to the component, which helps prevent global CSS conflicts.

Utility-First vs CSS Modules

Feature	Utility-First	CSS Modules
Styling	Utility classes	Component CSS
HTML	More classes	Cleaner
Scope	Utilities	Component-scoped
Development	Very fast	Structured
Best for	Rapid UI development	Component-based applications

Neither approach is universally better. The choice depends on the project's requirements, team preferences, and architecture.

Key Takeaways

From this topic, I learned:

Start responsive designs with a mobile-first approach.
Use min-width to progressively enhance layouts.
Use rem, vw, and especially clamp() for flexible typography.
Use srcset for different image sizes.
Use <picture> when different image sources are needed.
Use BEM to create structured and predictable CSS class names.
Utility-first CSS focuses on composing designs from small utility classes.
CSS Modules provide component-scoped styling.
Media queries are CSS, so they belong in <style> or .css files, not <script>. Responsive CSS is not just about making a website "fit" on different screens. It's about building layouts that adapt, remain accessible, perform well, and are easy to maintain.

DEV Community: koushikmaya

Also added my Handwritten notes at the end .please do check it out.

Understanding the Browser Rendering Pipeline: DOM, CSSOM, Layout, Paint, Compositing & Layout Thrashing

Understanding the Browser Rendering Pipeline: DOM, CSSOM, Layout, Paint, Compositing & Layout Thrashing

Understanding the Browser Rendering Pipeline: From DOM to Pixels 🚀

Introduction

This post covers what I learned and the small experiment I performed on layout thrashing.

📌 What I Learned

- Chrome DevTools Performance

🔄 Browser Rendering Pipeline

Let's understand each stage.

1️⃣ DOM Construction

Simple way to remember

DOM = What elements exist?

2️⃣ CSSOM Construction

Simple way to remember

3️⃣ Style Calculation

4️⃣ Render Tree

Simple way to remember

Render Tree = What actually participates in rendering?

5️⃣ Layout / Reflow

Simple way to remember

Layout is also commonly referred to as reflow.

6️⃣ Paint / Repaint

Simple way to remember

If something visual changes, the browser may need to paint that area again. This is commonly called a repaint.

7️⃣ Compositing

8️⃣ Critical Rendering Path

This is where frontend performance becomes important.

🧪 Practical Experiment With Chrome DevTools

I could actually see rendering activity in DevTools.

🔥 Layout Thrashing Experiment

Doing this repeatedly can lead to layout thrashing.

🤔 Why Is offsetHeight Important?

If we've just changed something that affects layout and then immediately request one of these values, the browser may need to perform layout work before returning the result.

❌ The Problem: Layout Thrashing

This can cause unnecessary synchronous layout work

✅ Fixing Layout Thrashing

This gives the browser a better opportunity to batch the rendering work.

📊 Before vs After

❌ Before

✅ After

🔍 What I Observed in DevTools

The layout-thrashing experiment was especially useful because I could see how a simple operation like reading offsetHeight can become important when it is repeatedly mixed with style changes.

🏁 Conclusion

This experiment gave me a better understanding of what happens behind the scenes when the browser turns our HTML, CSS, and JavaScript into pixels.

🛠️ Practical Work

- VS Code

📚 Final Note

📝 My Handwritten Notes

CSS Architecture

Responsive CSS: From Mobile-First Design to Modern Styling

1. Mobile-First Media Queries

min-width vs max-width

One important lesson I learned: CSS media queries belong inside <style> or a CSS file, not inside <script>.

2. Fluid Typography

rem

vw

clamp()

This allows the font size to grow smoothly while keeping it within limits.

3. Responsive Images

srcset

<picture>

4. BEM Naming Convention

BEM makes larger CSS projects easier to understand and maintain.

5. Utility-First Styling

Advantages

The styles are scoped to the component, which helps prevent global CSS conflicts.

Utility-First vs CSS Modules

Neither approach is universally better. The choice depends on the project's requirements, team preferences, and architecture.

Key Takeaways

🤔 Why Is `offsetHeight` Important?

The layout-thrashing experiment was especially useful because I could see how a simple operation like reading `offsetHeight` can become important when it is repeatedly mixed with style changes.

`min-width` vs `max-width`

One important lesson I learned: CSS media queries belong inside `<style>` or a CSS file, not inside `<script>`.

`rem`

`vw`

`clamp()`

`srcset`

`<picture>`