How Browsers Actually Work
From HTTP Request to Painting Pixels — Understanding the Critical Rendering Path and Optimization Techniques
The Journey Overview
When you type a URL and press Enter, a complex sequence of events unfolds. Understanding this journey is crucial for optimizing web performance.
THE BROWSER'S JOURNEY
1. URL ENTERED ↓ 2. DNS LOOKUP (Domain → IP Address) ↓ 3. TCP CONNECTION (3-way handshake) ↓ 4. TLS HANDSHAKE (if HTTPS) ↓ 5. HTTP REQUEST SENT ↓ 6. SERVER PROCESSES & RESPONDS ↓ 7. BROWSER RECEIVES HTML ↓ ┌───────────────────────────────────────────────────────────┐ │ CRITICAL RENDERING PATH BEGINS │ ├───────────────────────────────────────────────────────────┤ │ 8. HTML PARSING → DOM Construction │ │ ↓ │ │ 9. CSS PARSING → CSSOM Construction │ │ ↓ │ │ 10. JavaScript Execution (can block!) │ │ ↓ │ │ 11. RENDER TREE = DOM + CSSOM │ │ ↓ │ │ 12. LAYOUT (Reflow) - Calculate positions & sizes │ │ ↓ │ │ 13. PAINT - Fill in pixels │ │ ↓ │ │ 14. COMPOSITE - Layer management │ └───────────────────────────────────────────────────────────┘ ↓ 15. 🎉 PAGE IS VISIBLE TO USER!
DNS Resolution
When you type https://example.com, the browser needs to find the IP address of that server. This process can take 20-120ms!
DNS RESOLUTION FLOW
Browser: "What's the IP for example.com?" 1. Browser Cache → Check if we visited recently ↓ (miss) 2. OS Cache → Check operating system's cache ↓ (miss) 3. Router Cache → Check your router ↓ (miss) 4. ISP DNS Server → Your Internet Provider's DNS ↓ (miss) 5. Recursive Search: ┌─────────────────────────────────────────────────┐ │ Root DNS (.com, .org, .net servers) │ │ ↓ │ │ TLD Server (Top Level Domain - .com) │ │ ↓ │ │ Authoritative DNS (example.com's own server) │ │ ↓ │ │ IP Address: 93.184.216.34 │ └─────────────────────────────────────────────────┘ ⏱️ This process can take 20-120ms!
DNS Optimization Techniques
| Technique | How it Works |
|---|---|
| DNS Prefetch | <link rel="dns-prefetch" href="//api.example.com"> |
| Preconnect | <link rel="preconnect" href="https://fonts.googleapis.com"> |
| Reduce DNS lookups | Use fewer external domains |
| DNS Caching | Browser/OS cache frequently visited domains |
TCP Handshake
TCP (Transmission Control Protocol) ensures reliable, ordered delivery of data. Before sending anything, both parties must agree to communicate through a 3-way handshake.
TCP 3-WAY HANDSHAKE
CLIENT (Browser) SERVER
│ │
│ │
Step 1: │ ─────────── SYN ──────────────────▶ │
"Hey, │ seq=100 (random number) │
wanna │ "I want to connect!" │
talk?" │ │
│ │
│ │ Step 2:
│ ◀────────── SYN-ACK ─────────────── │ "Sure! I hear you,
│ seq=300, ack=101 │ and I want to
│ "Got it! I also want to connect!" │ connect too!"
│ │
│ │
Step 3: │ ─────────── ACK ──────────────────▶ │
"Great, │ seq=101, ack=301 │
let's │ "Confirmed! Let's go!" │
go!" │ │
│ │
│ ═══════════════════════════════════ │
│ CONNECTION ESTABLISHED! │
⏱️ Time: ~1 RTT (Round Trip Time)
📍 Typical: 20-100ms depending on distance
💡 Why 3 Steps?
Step 1 (SYN): Client proves it can SEND
Step 2 (SYN-ACK): Server proves it can SEND and RECEIVE
Step 3 (ACK): Client proves it can RECEIVE
TLS Handshake
After TCP connection is established, if using HTTPS, we need another handshake to establish encryption.
TLS 1.2 vs TLS 1.3
⏱️ TLS 1.2 (Slower)
2 RTT for handshake
Multiple round trips for key exchange
Time: ~60-100ms
⚡ TLS 1.3 (Faster)
1 RTT for handshake
Key share sent in ClientHello
Time: ~30-50ms
0-RTT for session resumption!
FULL CONNECTION TIMELINE (HTTPS with TLS 1.2)
TIME CLIENT SERVER
│ ──────── DNS Query ────────────────────▶
│ ◀─────── DNS Response ─────────────────
0ms DNS Resolution: ~50ms
├─────────────────────────────────────────────────────────────────
│ ──────── SYN ──────────────────────────▶
│ ◀─────── SYN-ACK ──────────────────────
│ ──────── ACK ──────────────────────────▶
50ms TCP Handshake: ~30ms (1 RTT)
├─────────────────────────────────────────────────────────────────
│ ──────── ClientHello ──────────────────▶
│ ◀─────── ServerHello, Certificate ─────
│ ──────── Key Exchange, Finished ───────▶
│ ◀─────── Finished ─────────────────────
140ms TLS Handshake: ~60ms (2 RTT for TLS 1.2)
├─────────────────────────────────────────────────────────────────
│ ══════════ SECURE CONNECTION ══════════
│ ──────── HTTP Request ─────────────────▶
│ ◀─────── HTTP Response ────────────────
⏱️ Total before first byte: ~200ms minimum!
With TLS 1.3: ~140ms (saves one RTT)
With 0-RTT: ~80ms (connection reuse)
HTML Parsing & DOM Construction
The browser transforms raw bytes into a structured DOM tree through a multi-step pipeline.
1
Bytes → Characters
Raw bytes (3C 68 74 6D 6C...) are decoded using UTF-8 into readable characters (<html>...)
2
Characters → Tokens
Tokenizer reads characters and produces tokens (StartTag, EndTag, Character, etc.)
3
Tokens → Nodes
Tokens are converted into DOM nodes with properties and methods
4
Nodes → DOM Tree
Nodes are connected into a tree structure using a stack-based algorithm
Parser Blocking
PARSER BLOCKING SCENARIOS
<html>
<body>
<h1>Title</h1> ✅ Parsed
<script src="app.js"> 🛑 STOP! Must fetch & execute
</script>
<p>Content below</p> ⏸️ WAITING... (not parsed yet)
</body>
</html>
WHY does script block?
Script might call document.write() which can CHANGE the HTML!
Parser can't continue until it knows what the script will do.
Preload Scanner
🔍 The Preload Scanner
While the main parser is blocked, a secondary scanner keeps looking ahead for resources to fetch in parallel (images, CSS, scripts). This can significantly speed up page load!
CSSOM Construction
Unlike DOM which mirrors HTML structure, CSSOM mirrors CSS structure.
CSSOM OBJECT MODEL
document.styleSheets
│
│ StyleSheetList (array-like)
│
├── [0] CSSStyleSheet (user-agent styles)
│ │
│ └── .cssRules: CSSRuleList
│
├── [1] CSSStyleSheet (your styles.css)
│ │
│ ├── .cssRules: CSSRuleList
│ │ ├── [0] CSSStyleRule
│ │ │ ├── .selectorText: "body"
│ │ │ └── .style: { margin: "0" }
│ │ │
│ │ ├── [1] CSSMediaRule (@media query)
│ │ │ └── .cssRules: (nested rules)
│ │ │
│ │ └── [2] CSSKeyframesRule
│ │
│ └── .href: "https://example.com/styles.css"
│
└── [2] CSSStyleSheet (inline <style>)
CSS is RENDER-BLOCKING
⚠️ The Fundamental Rule
DOM ready ✓ + CSSOM loading ⏳ = NO PAINT 🚫
DOM ready ✓ + CSSOM ready ✓ = CAN PAINT ✅
Why? To prevent FOUC (Flash Of Unstyled Content). The browser will show a blank screen rather than unstyled content.
Multiple CSS Files
If you have 3 CSS files and one loads in 100ms but others take 4 seconds, CSSOM waits for ALL render-blocking CSS files. First paint happens after the SLOWEST file loads.
Async CSS Loading
HTML
<!-- Media trick - load CSS without blocking -->
<link rel="stylesheet" href="styles.css"
media="print" onload="this.media='all'">
<!-- Preload + onload technique -->
<link rel="preload" href="styles.css" as="style"
onload="this.rel='stylesheet'">
<!-- Fallback for browsers without JS -->
<noscript><link rel="stylesheet" href="styles.css"></noscript>
Render Tree
The Render Tree = DOM nodes that are VISIBLE + their COMPUTED STYLES. This is where DOM and CSSOM come together!
RENDER TREE CONSTRUCTION
STEP 1: Start with DOM tree ───────────────────────────── DOM CSSOM html body { margin: 0; } │ h1 { color: blue; } ┌──┴──┐ .hidden { display: none; } head body p::before { content: "→"; } │ ┌────┼────┐ h1 .hidden p STEP 2: Walk DOM, attach computed styles ───────────────────────────────────────── For EACH DOM node: 1. Is it visible? (display: none = skip!) 2. Compute all styles (cascade + inheritance) 3. Create Render Object (attach styles) STEP 3: Result = Render Tree ───────────────────────────── RenderView (viewport) │ RenderBlock (body) styles: { margin: 0 } │ ┌───┴────┐ │ │ RenderBlock RenderBlock (h1) (p) │ │ │ ┌───┴────┐ │ │ │ RenderText RenderInline RenderText "Title" (::before) "Content" content: "→" ❌ .hidden element NOT in Render Tree! (display: none removes it completely)
DOM TREE vs RENDER TREE (Visual Comparison)
DOM TREE (Complete structure): RENDER TREE (Visual only): Document RenderView │ │ <html> RenderBlock │ (viewport) ┌─────┴─────┐ │ │ │ RenderBlock <head> <body> (body) │ │ │ ┌────┴────┐ ... ┌────────┼────────┐ │ │ │ │ │ │ <meta><title><style> RenderBlock RenderBlock RenderBlock ❌ ❌ ❌ (header) (main) (p) │ │ │ (Not in render tree - RenderText │ RenderText non-visual elements) ("Header") │ │ ┌──────┴──────┐ │ │ RenderBlock RenderBlock (p) (hidden-p) │ ❌ ┌────┴────┐ (display:none │ │ NOT in tree!) RenderInline RenderText (::before) ("Visible")
Style Computation (The Cascade)
HOW COMPUTED STYLES ARE CALCULATED
For element: <p class="intro" id="welcome">Hello</p> STEP 1: Find all matching rules ────────────────────────────────── Matches: p { color: black; font-size: 16px; } /* (0,0,0,1) */ .intro { color: blue; line-height: 1.5; } /* (0,0,1,0) */ #welcome { color: green; } /* (0,1,0,0) */ p.intro { font-weight: bold; } /* (0,0,1,1) */ STEP 2: Apply cascade (specificity order) ──────────────────────────────────────────── Specificity = (inline, id, class, element) color: black (0,0,0,1) → overwritten color: blue (0,0,1,0) → overwritten color: green (0,1,0,0) → WINS! (highest specificity) STEP 3: Inherit from parent (for inheritable props) ───────────────────────────────────────────────────── Parent (body): font-family: Arial; Element (p): inherits font-family: Arial STEP 4: Apply defaults for missing properties ───────────────────────────────────────────────── display: not specified → default: inline (for p: block) margin: not specified → default: browser stylesheet FINAL COMPUTED STYLE: ───────────────────── { color: green, // from #welcome (highest specificity) font-size: 16px, // from p line-height: 1.5, // from .intro font-weight: bold, // from p.intro font-family: Arial, // inherited from body display: block, // browser default for p margin: 1em 0, // browser default for p ... // all 300+ CSS properties! }
Specificity Calculator
SPECIFICITY RULES
SPECIFICITY FORMAT: (inline, ID, class, element) ┌─────────────────────────────────────────────────────────────┐ │ │ │ style="" → (1,0,0,0) ← Inline ALWAYS wins! │ │ #id → (0,1,0,0) │ │ .class → (0,0,1,0) │ │ [attr] → (0,0,1,0) ← Same as class │ │ :pseudo-class → (0,0,1,0) ← Same as class │ │ element → (0,0,0,1) │ │ ::pseudo-elem → (0,0,0,1) ← Same as element │ │ * → (0,0,0,0) ← Universal = no specificity │ │ │ └─────────────────────────────────────────────────────────────┘ EXAMPLES: p → (0,0,0,1) p.intro → (0,0,1,1) div p.intro → (0,0,1,2) #header .nav a → (0,1,1,1) #header .nav a:hover → (0,1,2,1) div#main p.text span → (0,1,1,3) COMPARISON (left to right): (0,1,0,0) beats (0,0,99,99) → IDs beat any number of classes!
What's NOT in the Render Tree?
<head>,<meta>,<title>,<script>,<style>— non-visual elements- Elements with
display: none— completely removed <template>elements — content not rendered- Hidden
<input type="hidden">
What IS in the Render Tree (even if not visible)?
- Elements with
visibility: hidden— takes space! - Elements with
opacity: 0— takes space, can be animated! - CSS-generated content (
::before,::after)
display:none vs visibility:hidden vs opacity:0
| Property | In Render Tree | Takes Space | Clickable | Animatable |
|---|---|---|---|---|
display: none |
❌ No | ❌ No | ❌ No | ❌ No |
visibility: hidden |
✅ Yes | ✅ Yes | ❌ No | ⚠️ Jumps |
opacity: 0 |
✅ Yes | ✅ Yes | ✅ Yes | ✅ Smooth |
Layout (Reflow)
Layout calculates exact position (x, y) and size (width, height) for every element, transforming relative values to absolute pixels.
WHAT LAYOUT DOES
Render Tree knows: Layout calculates: RenderBlock (div) RenderBlock (div) styles: { layout: { width: 50%, ← 50% of WHAT? x: 200, ← Exact X position padding: 2em, ← how many pixels? y: 100, ← Exact Y position margin: auto ← what value? width: 600, ← 50% of 1200px = 600px } height: 400, ← Calculated from content padding: 32, ← 2em × 16px = 32px margin-left: 200 ← auto calculated } Layout transforms RELATIVE values → ABSOLUTE pixel values • % → pixels (based on parent) • em → pixels (based on font-size) • auto → pixels (calculated from context) • vw/vh → pixels (based on viewport) • calc()→ pixels (computed result)
THE BOX MODEL
┌─────────────────────────────────────────┐ │ MARGIN │ │ ┌───────────────────────────────────┐ │ │ │ BORDER │ │ │ │ ┌─────────────────────────────┐ │ │ │ │ │ PADDING │ │ │ │ │ │ ┌───────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ CONTENT BOX │ │ │ │ │ │ │ │ (width × height) │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └───────────────────────┘ │ │ │ │ │ └─────────────────────────────┘ │ │ │ └───────────────────────────────────┘ │ └─────────────────────────────────────────┘ box-sizing: content-box (default) → width/height applies to content only → Total = width + padding + border → Example: width: 200px; padding: 20px; border: 5px; Total = 200 + 20 + 20 + 5 + 5 = 250px box-sizing: border-box (recommended!) → width/height includes padding and border → Total = exactly what you specify → Example: width: 200px; padding: 20px; border: 5px; Content = 200 - 20 - 20 - 5 - 5 = 150px Total = 200px (as specified!)
Layout Algorithm
LAYOUT ALGORITHM STEPS
STEP 1: Start at root (viewport) ───────────────────────────────── Viewport size is known (e.g., 1920×1080) This is the "containing block" for the document viewport = { width: 1920, height: 1080, x: 0, y: 0 } STEP 2: Calculate widths (TOP-DOWN) ────────────────────────────────────── Width often depends on parent, so go parent → child Parent: width = 1000px Child: width = 50% → Child computed width = 500px STEP 3: Calculate heights (BOTTOM-UP) ─────────────────────────────────────── Height often depends on children, so go child → parent Child 1: height = 100px Child 2: height = 150px Child 3: height = 80px → Parent height = 100 + 150 + 80 = 330px STEP 4: Calculate positions (x, y coordinates) ────────────────────────────────────────────────── Based on: • Display mode (block, inline, flex, grid) • Position property (static, relative, absolute, fixed) • Float property • Margins (including margin collapse!)
Layout Modes (Formatting Contexts)
DIFFERENT LAYOUT MODES
BLOCK FORMATTING CONTEXT (BFC) ══════════════════════════════ Elements with display: block, flex, grid, table ┌───────────────────────────────────────────────────────────┐ │ Block 1 (full width) │ └───────────────────────────────────────────────────────────┘ ┌───────────────────────────────────────────────────────────┐ │ Block 2 (full width) │ └───────────────────────────────────────────────────────────┘ Rules: • Each block on its own line (vertical stacking) • Width fills container (unless specified) • Vertical margins COLLAPSE between siblings ──────────────────────────────────────────────────────────── INLINE FORMATTING CONTEXT (IFC) ═══════════════════════════════ Elements with display: inline, inline-block ┌────────────────────────────────────────────────────────────┐ │ This is [inline1] text with [inline2] elements that [in- │ │ line3] wrap to the next line when they run out of space. │ └────────────────────────────────────────────────────────────┘ Rules: • Elements flow horizontally (like text) • Wrap to next line when no space • Vertical margins DON'T apply (use line-height) ──────────────────────────────────────────────────────────── FLEXBOX LAYOUT ══════════════ display: flex ┌──────────────────────────────────────────────────────────┐ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Flex 1 │ │ Flex 2 │ │ Flex 3 │ │ Flex 4 │ │ │ │ flex:1 │ │ flex:2 │ │ flex:1 │ │ flex:1 │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ └──────────────────────────────────────────────────────────┘ ──────────────────────────────────────────────────────────── GRID LAYOUT ═══════════ display: grid; grid-template-columns: 1fr 2fr 1fr; ┌──────────────────────────────────────────────────────────┐ │ ┌────────┐ ┌──────────────────────┐ ┌────────┐ │ │ │ 1 │ │ 2 │ │ 3 │ │ │ └────────┘ └──────────────────────┘ └────────┘ │ │ ┌────────┐ ┌──────────────────────┐ ┌────────┐ │ │ │ 4 │ │ 5 │ │ 6 │ │ │ └────────┘ └──────────────────────┘ └────────┘ │ └──────────────────────────────────────────────────────────┘
Margin Collapse
⚠️ Margin Collapse - A Layout Quirk
In Block Formatting Context, vertical margins can collapse! If Box 1 has margin-bottom: 30px and Box 2 has margin-top: 20px, the gap is only 30px (larger one wins), not 50px!
What Triggers Layout?
LAYOUT TRIGGERS
CSS PROPERTY CHANGES (that affect geometry): • width, height, min-*, max-* • margin, padding, border-width • top, left, right, bottom (positioned elements) • font-size, font-family, font-weight • display, position, float • flex-*, grid-* DOM CHANGES: • Adding/removing elements • Changing text content • Moving elements READING LAYOUT PROPERTIES (Forces sync layout!): • offsetTop, offsetLeft, offsetWidth, offsetHeight • clientTop, clientLeft, clientWidth, clientHeight • scrollTop, scrollLeft, scrollWidth, scrollHeight • getComputedStyle() (some properties) • getBoundingClientRect() ⚠️ Reading these FORCES browser to calculate layout immediately!
Layout Thrashing
LAYOUT THRASHING EXPLAINED
❌ BAD: Causes layout thrashing! boxes.forEach(box => { const width = box.offsetWidth; // READ → Forces layout! box.style.width = (width + 10) + 'px'; // WRITE → Invalidates // Next iteration: READ again → Forces NEW layout! }); Timeline: [Layout][Layout][Layout][Layout][Layout] ... 100 times! If 100 boxes: 100 layout calculations = ~1 SECOND of blocking! ───────────────────────────────────────────────────────────── ✅ GOOD: Batch reads, then batch writes // BATCH READ (one layout calculation) const widths = Array.from(boxes).map(box => box.offsetWidth); // BATCH WRITE (no layout during writes) boxes.forEach((box, i) => { box.style.width = (widths[i] + 10) + 'px'; }); Timeline: [Layout]...[Paint] Total: ~10ms instead of 1 second! ───────────────────────────────────────────────────────────── VISUALIZATION: ❌ Layout Thrashing: R W L R W L R W L R W L R W L R W L R W L R W L R W L R W L └─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘ Many layout calculations interleaved! ✅ Batched: R R R R R R R R R R │ L │ W W W W W W W W W W └───── Reads ───────┘ └────── Writes ──────┘ Single layout!
❌ BAD: Read-Write Loop
boxes.forEach(box => {
const width = box.offsetWidth; // READ
box.style.width = width + 'px'; // WRITE
// Repeat = Layout every iteration!
});
✅ GOOD: Batched
// Batch reads
const widths = boxes.map(b => b.offsetWidth);
// Batch writes
boxes.forEach((box, i) => {
box.style.width = widths[i] + 'px';
});
Paint
Paint converts Layout boxes into actual pixels using drawing commands (Paint Records). This is where the browser draws colors, images, text, shadows, and everything visual!
WHAT IS PAINT?
Layout tells us: Paint tells us: "This box is at "Fill this area with position (100, 50) blue (#0066ff), draw with size 200×100" a 2px black border, render text 'Hello' in Arial 16px" ┌─────────────────┐ ┌─────────────────┐ │ │ │█████████████████│ │ x: 100 │ → │█ █│ │ y: 50 │ │█ Hello █│ │ width: 200 │ │█ █│ │ height: 100 │ │█████████████████│ └─────────────────┘ └─────────────────┘ Just geometry Actual pixels!
PAINT RECORDS (Drawing Commands)
CSS:
.button {
background: linear-gradient(#4CAF50, #388E3C);
border: 2px solid #2E7D32;
border-radius: 8px;
box-shadow: 0 4px 6px rgba(0,0,0,0.3);
color: white;
font: bold 16px Arial;
}
Paint Records Generated:
1. DrawShadow(
x: 100, y: 54, // Offset for shadow
blur: 6,
color: rgba(0,0,0,0.3)
)
2. DrawRoundedRect(
x: 100, y: 50,
width: 200, height: 50,
radius: 8,
fill: LinearGradient(#4CAF50 → #388E3C)
)
3. StrokeRoundedRect(
x: 100, y: 50,
width: 200, height: 50,
radius: 8,
strokeWidth: 2,
strokeColor: #2E7D32
)
4. DrawText(
text: "Click Me",
x: 150, y: 80, // Centered position
font: "bold 16px Arial",
color: #FFFFFF
)
These commands are executed in ORDER to produce the final pixels!
Paint Order (Stacking Context)
PAINT ORDER
Elements are painted in a SPECIFIC ORDER (back to front): PAINT ORDER (within each stacking context): 1. Background color of element 2. Background image 3. Border 4. Children (in DOM order) 5. Outline STACKING ORDER (z-axis, back to front): BACK (painted first) ↓ 1. Root element background 2. Positioned elements with negative z-index 3. Non-positioned block elements (in DOM order) 4. Non-positioned float elements 5. Non-positioned inline elements (text, images) 6. Positioned elements with z-index: 0 or auto 7. Positioned elements with positive z-index ↓ FRONT (painted last, on top)
What Triggers Paint?
| Property Type | Layout | Paint | Composite |
|---|---|---|---|
| width, height, margin, padding | ✓ | ✓ | ✓ |
| color, background, box-shadow | ✗ | ✓ | ✓ |
| transform, opacity | ✗ | ✗ | ✓ |
Paint Cost
PAINT COST: WHAT'S EXPENSIVE?
🟢 CHEAP (fast to paint): ────────────────────────── • Solid color backgrounds • Simple borders • Simple text .simple { background: #fff; border: 1px solid #ccc; color: #333; } ───────────────────────────────────────────────────────────── 🟡 MEDIUM (more work): ────────────────────── • Gradients • Border-radius • Images .medium { background: linear-gradient(to bottom, #fff, #eee); border-radius: 10px; } ───────────────────────────────────────────────────────────── 🔴 EXPENSIVE (slow to paint): ───────────────────────────── • Box shadows (especially large blur radius) • Text shadows • Filters (blur, drop-shadow) • Clip-path (complex shapes) • Mix-blend-mode .expensive { box-shadow: 0 10px 50px rgba(0,0,0,0.5); // Large blur! filter: blur(5px) drop-shadow(10px 10px 10px #000); clip-path: polygon(50% 0%, 100% 50%, 50% 100%, 0% 50%); } ───────────────────────────────────────────────────────────── PAINT AREA MATTERS TOO: Small area with expensive effect: ┌────┐ │blur│ ~1ms (small area, still okay) └────┘ Large area with expensive effect: ┌────────────────────────────────────────────────────────────┐ │ BLUR ENTIRE PAGE │ └────────────────────────────────────────────────────────────┘ ~50ms+ (huge area = SLOW!) Paint cost = Complexity × Area
Paint Layers
WITH vs WITHOUT LAYERS
WITHOUT LAYERS (Single Surface): ───────────────────────────────── Any change = Repaint EVERYTHING on that surface ┌─────────────────────────────────────────────────────────────┐ │ ████████████████████████████████████████████████████████████│ │ ████████ Change here ═══════════════▶ Repaint ALL! █████████│ │ ████████████████████████████████████████████████████████████│ └─────────────────────────────────────────────────────────────┘ ───────────────────────────────────────────────────────────── WITH LAYERS (Multiple Surfaces): ──────────────────────────────── Each layer is painted independently! Layer 3 (animated element): ┌─────────────────┐ │ Button (hover) │ ◀── Only this layer repaints! └─────────────────┘ Layer 2 (fixed header): ┌─────────────────────────────────────────────────────────────┐ │ Header │ └─────────────────────────────────────────────────────────────┘ Layer 1 (main content): ┌─────────────────────────────────────────────────────────────┐ │ ████████████████████████████████████████████████████████████│ └─────────────────────────────────────────────────────────────┘ Change in Layer 3 = Only repaint Layer 3! (much faster)
💡 DevTools: Visualize Paint
Paint Flashing: DevTools → Cmd+Shift+P → "Show paint flashing" → Green flash shows repainted areas
Layer Borders: Rendering tab → Check "Layer borders" → See compositor layers
Performance Panel: Record and see paint timing in the flame chart
Compositing
Compositing is the final step — GPU combines all painted layers into the final image. This runs on a separate compositor thread!
WHAT IS COMPOSITING?
After Paint creates bitmaps (textures) for each layer: Layer Textures (in GPU memory): ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ Layer 1 │ │ Layer 2 │ │ Layer 3 │ │ (content) │ │ (header) │ │ (modal) │ │ │ │ │ │ │ │ ┌────────┐ │ │ ┌────────┐ │ │ ┌────────┐ │ │ │ Bitmap │ │ │ │ Bitmap │ │ │ │ Bitmap │ │ │ └────────┘ │ │ └────────┘ │ │ └────────┘ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ └──────────────────┼─────────────────┘ │ ▼ ┌─────────────────┐ │ COMPOSITOR │ │ │ │ • Position │ │ • Transform │ │ • Opacity │ │ • Blend │ └────────┬────────┘ │ ▼ ┌─────────────────┐ │ FINAL FRAME │ │ (to screen) │ └─────────────────┘ Key insight: GPU can transform/blend textures WITHOUT repainting!
COMPOSITOR THREAD vs MAIN THREAD
MAIN THREAD COMPOSITOR THREAD • JavaScript • Layer composition • DOM manipulation • Transform animations • Style calculation • Opacity animations • Layout • Scrolling • Paint (generate records) • Pinch-zoom Can be BLOCKED by NEVER blocked by heavy JavaScript! JavaScript! ─────────────────────────────────────────────────────────────── Scenario: Heavy JavaScript running (500ms) Main Thread: ┌───────────────────────────────────────────────────────────────┐ │ ████████████████████████ JavaScript (500ms) █████████████████ │ │ BLOCKED - Can't do layout/paint! │ └───────────────────────────────────────────────────────────────┘ Compositor Thread: ┌───────────────────────────────────────────────────────────────┐ │ ░░░ Composite ░░░ Composite ░░░ Composite ░░░ Composite ░░░ │ │ Still running! Smooth scrolling! 60fps animations! │ └───────────────────────────────────────────────────────────────┘ Transform/opacity animations stay SMOOTH even when JavaScript is blocking the main thread!
Compositor-Only Operations (GPU Accelerated)
These operations can be performed by the GPU without repainting:
GPU OPERATIONS
1. TRANSLATE (Move position) ───────────────────────────── transform: translateX(100px) translateY(50px); ┌─────────┐ ┌─────────┐ │ Layer │ ───────────▶ │ Layer │ └─────────┘ └─────────┘ Original Moved (GPU just repositions!) 2. SCALE (Resize) ────────────────── transform: scale(1.5); ┌─────────┐ ┌───────────────┐ │ Layer │ ───────────▶ │ Layer │ └─────────┘ └───────────────┘ Original Scaled (GPU stretches texture!) 3. ROTATE ───────── transform: rotate(45deg); ┌─────────┐ ◇─────────◇ │ Layer │ ───────────▶ ◇│ Layer │◇ └─────────┘ ◇─────────◇ Original Rotated (GPU rotates texture!) 4. OPACITY (Transparency) ─────────────────────────── opacity: 0.5; ┌─────────┐ ┌ ─ ─ ─ ─ ─┐ │█████████│ ───────────▶ │░░░░░░░░░░│ └─────────┘ └ ─ ─ ─ ─ ─┘ Solid Semi-transparent (GPU blends with background!) ALL OF THESE: • Don't require repaint! • Run on compositor thread (off main thread!) • Are GPU accelerated (super fast!) • Can hit 60fps even with heavy JS!
What Creates Layers?
LAYER PROMOTION TRIGGERS
AUTOMATIC LAYER PROMOTION: ✓ 3D transforms transform: translateZ(0) transform: translate3d(x, y, z) transform: rotateX/Y/Z() ✓ CSS animation/transition on transform or opacity .box { transition: transform 0.3s; } @keyframes slide { to { transform: translateX(100px); } } ✓ position: fixed Fixed elements often get their own layer ✓ will-change property will-change: transform, opacity; ✓ <video> and <canvas> elements Media always gets own layer ✓ CSS filter or backdrop-filter filter: blur(10px); ✓ Element overlapping a composited layer If A is layered and B overlaps A, B might get a layer too! ✓ opacity < 1 opacity: 0.99 triggers layer creation!
Layer Tree Visualization
3D VIEW OF LAYERS
Example page with multiple layers:
┌───────────┐
╱│ Video │ Layer 5 (front)
╱ └───────────┘
╱
╱ ┌───────────┐
╱ ╱│ Modal │ Layer 4
╱ ╱ └───────────┘
╱ ╱
╱ ╱ ┌───────────┐
╱ ╱ ╱│ Card │ Layer 3
╱ ╱ ╱ └───────────┘
╱ ╱ ╱
╱ ╱ ┌───────────┐
╱ ╱ ╱│ Header │ Layer 2
╱ ╱ └───────────┘
╱
┌───────────────────────────────────────────┐
│ Main Content │ Layer 1 (back)
└───────────────────────────────────────────┘
GPU composites these layers together each frame!
Change in one layer = Only that layer updates!
Layer Memory Cost
MEMORY CALCULATION
Layer size: 1920 × 1080 pixels Color depth: 4 bytes per pixel (RGBA) Memory = 1920 × 1080 × 4 = 8,294,400 bytes ≈ 8 MB per full-screen layer! ───────────────────────────────────────────────────────────── ⚠️ LAYER EXPLOSION - Common Problem: Problematic code: /* Every list item gets its own layer! */ .list-item { will-change: transform; /* Creates layer! */ } If you have 1000 list items = 1000 layers! = Huge GPU memory usage = Slow compositing = Possible crashes on mobile! ───────────────────────────────────────────────────────────── ✅ Better approach: /* Only promote when needed */ .list-item:hover { will-change: transform; /* Layer only on hover! */ } .list-item.animating { will-change: transform; /* Layer only during animation! */ }
⚠️ will-change Best Practices
DO: Apply will-change before animation starts, remove after animation ends.
DON'T: Apply will-change to everything or keep it permanently on static elements.
element.addEventListener('transitionend', () => element.style.willChange = 'auto');
The Compositing Process
COMPOSITING STEP BY STEP
STEP 1: Collect Layer Information ─────────────────────────────────── For each layer, compositor knows: • texture: GPU_TEXTURE_ID // Reference to painted bitmap • position: { x: 100, y: 50 } // Screen position • transform: matrix3d(...) // Any transforms applied • opacity: 0.9 // Transparency • zIndex: 3 // Stacking order STEP 2: Sort Layers by Z-Order ───────────────────────────────── 1. Background layer (z: 0) 2. Content layer (z: 1) 3. Fixed header (z: 100) 4. Modal overlay (z: 1000) 5. Tooltip (z: 9999) STEP 3: Draw Layers (Back to Front) ───────────────────────────────────── GPU Framebuffer: Start: Empty ┌─────────────────────────────────────────────────────────────┐ │ (empty) │ └─────────────────────────────────────────────────────────────┘ Draw Layer 1 (background): ┌─────────────────────────────────────────────────────────────┐ │ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │ └─────────────────────────────────────────────────────────────┘ Draw Layer 2 (content) - blended on top: ┌─────────────────────────────────────────────────────────────┐ │ ░░░░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░ │ └─────────────────────────────────────────────────────────────┘ Draw Layer 3 (header) with transform: ┌─────────────────────────────────────────────────────────────┐ │ ████████████████████████████████████████████████████████████│ │ ░░░░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░ │ └─────────────────────────────────────────────────────────────┘ Final: Complete frame ready for display! STEP 4: Display (Swap Buffers) ───────────────────────────────── GPU uses double/triple buffering - swap to display at vsync
The Complete Rendering Pipeline
Now let's see how ALL the pieces fit together — from the user typing a URL to pixels appearing on screen!
THE COMPLETE JOURNEY: URL → PIXELS
USER TYPES: https://example.com ═══════════════════════════════════════════════════════════════ PHASE 1: NETWORK ═══════════════════════════════════════════════════════════════ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ DNS │────▶│ TCP │────▶│ TLS │ │ Lookup │ │ Handshake │ │ Handshake │ │ (~20-120ms)│ │ (~40ms) │ │ (~40-100ms)│ └──────────────┘ └──────────────┘ └──────────────┘ │ │ ▼ ▼ "What's the IP?" "Connection secure!" │ ▼ ┌────────────────────────────────┐ │ HTTP Request/Response │ │ "GET /index.html" │ │ ───────▶ │ │ ◀─────── HTML bytes │ └────────────────────────────────┘ ═══════════════════════════════════════════════════════════════ PHASE 2: PARSING (Parallel Processes) ═══════════════════════════════════════════════════════════════ HTML Stream arrives: <html><head><link href="style.css"><script src="app.js">... │ ┌─────────────────────┼─────────────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ HTML Parser │ │ CSS Parser │ │ Preload │ │ │ │ │ │ Scanner │ │ Tokenize │ │ Parse CSS │ │ │ │ Build DOM │ │ Build CSSOM │ │ Find more │ │ │ │ │ │ resources! │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ ▼ ▼ ▼ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ Fetch: │ │ DOM TREE │ │ CSSOM │ │ - images │ │ │ │ │ │ - scripts │ │ document │ │ StyleSheets │ │ - fonts │ │ └─html │ │ └─rules │ │ (parallel!) │ │ └─body │ │ └─styles │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ BLOCKED BY: │ │ ◀──────────────│ CSS (render blocking) │ <script> (parser blocking) │ │ └─────────┬──────────┘ │ ▼ Wait for BOTH to be ready... ═══════════════════════════════════════════════════════════════ PHASE 3: RENDER TREE CONSTRUCTION ═══════════════════════════════════════════════════════════════ ┌──────────────┐ ┌──────────────┐ │ DOM TREE │ + │ CSSOM │ └──────┬───────┘ └──────┬───────┘ │ │ └──────────┬─────────────┘ │ ▼ ┌────────────────────┐ │ STYLE CALC │ │ │ │ For each DOM node: │ │ - Find matching │ │ CSS rules │ │ - Apply cascade │ │ - Resolve inherit │ │ - Compute values │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ RENDER TREE │ │ │ │ Only VISIBLE nodes │ │ + computed styles │ │ │ │ (display:none │ │ elements removed) │ └─────────┬──────────┘ │ ▼ ═══════════════════════════════════════════════════════════════ PHASE 4: LAYOUT ═══════════════════════════════════════════════════════════════ ┌────────────────────┐ │ LAYOUT │ │ (Reflow) │ │ │ │ Calculate: │ │ • Exact positions │ │ • Exact sizes │ │ │ │ Convert: │ │ %, em, vh → pixels │ │ auto → calculated │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ LAYOUT TREE │ │ │ │ Each node has: │ │ x: 100 │ │ y: 50 │ │ width: 400 │ │ height: 200 │ └─────────┬──────────┘ │ ▼ ═══════════════════════════════════════════════════════════════ PHASE 5: PAINT ═══════════════════════════════════════════════════════════════ ┌────────────────────┐ │ PAINT │ │ │ │ Generate drawing │ │ commands: │ │ • DrawRect(...) │ │ • DrawText(...) │ │ • DrawImage(...) │ │ │ │ Create paint │ │ layers for: │ │ • transform │ │ • opacity │ │ • position:fixed │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ PAINT RECORDS │ │ per layer │ │ │ │ Layer 1: [...] │ │ Layer 2: [...] │ │ Layer 3: [...] │ └─────────┬──────────┘ │ ▼ ═══════════════════════════════════════════════════════════════ PHASE 6: RASTERIZATION ═══════════════════════════════════════════════════════════════ ┌────────────────────┐ │ RASTERIZATION │ │ │ │ Convert paint │ │ records to pixels │ │ (bitmaps/textures) │ │ │ │ Done on GPU or │ │ raster threads │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ LAYER TEXTURES │ │ in GPU memory │ │ │ │ [████████████████] │ │ [████████████████] │ │ [████████████████] │ └─────────┬──────────┘ │ ▼ ═══════════════════════════════════════════════════════════════ PHASE 7: COMPOSITING ═══════════════════════════════════════════════════════════════ ┌────────────────────┐ │ COMPOSITOR │ │ (Separate Thread) │ │ │ │ Combine layers: │ │ • Apply transforms │ │ • Apply opacity │ │ • Handle z-order │ │ • Blend together │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ FINAL FRAME │ │ sent to GPU │ │ │ │ ┌────────────────┐ │ │ │████████████████│ │ │ │██ YOUR PAGE ███│ │ │ │████████████████│ │ │ └────────────────┘ │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ DISPLAY! │ │ (60fps = 16.6ms │ │ per frame) │ └────────────────────┘
TIMELINE VIEW: WHAT HAPPENS WHEN?
Time ──────────────────────────────────────────────────────────────▶ NETWORK: │ DNS │ TCP │ TLS │════════ HTML Download ═════════│ │ │ │ │ │══ CSS ══│ │ │ │ │ │ │═══════════ JS ══════════│ │ │ │ │ │══════ Images ═══════════════════════════│ MAIN THREAD: │ │ HTML Parse │ Style │ Layout │ Paint │ │ │ │────────────│───────│────────│───────│ │ │ │ DOM │ │ │ │ │ │ │ ◀─blocked─▶│ │ │ │ │ │ │ (by JS/CSS)│ │ │ │ │ COMPOSITOR THREAD: │ │ Composite │────────▶ │ │───────────│ │ │ │ KEY METRICS: │ │ ├── TTFB (Time to First Byte) │ │ │ ├─────────── FCP (First Contentful Paint) │ │ │ ├────────────────────── LCP (Largest Contentful Paint) │ │ │ BLOCKING POINTS: • CSS blocks rendering (render-blocking) • <script> blocks parsing (parser-blocking) • JavaScript on main thread blocks everything else!
RE-RENDERING: WHAT TRIGGERS WHAT?
When you change something, what work does the browser do? ═══════════════════════════════════════════════════════════════ CHANGE WIDTH/HEIGHT/MARGIN (Geometry Changes) ═══════════════════════════════════════════════════════════════ [Style] → [Layout] → [Paint] → [Composite] ↑ Most expensive! Recalculates positions for potentially many elements. Avoid in animations! ═══════════════════════════════════════════════════════════════ CHANGE COLOR/BACKGROUND/SHADOW (Visual-only Changes) ═══════════════════════════════════════════════════════════════ [Style] → → [Paint] → [Composite] ↑ Medium cost. Skips layout but still repaints affected area. ═══════════════════════════════════════════════════════════════ CHANGE TRANSFORM/OPACITY (Compositor-only Changes) ═══════════════════════════════════════════════════════════════ [Style] → → → [Composite] ↑ Cheapest! GPU just moves/blends existing textures. Can run at 60fps even with heavy JavaScript! ═══════════════════════════════════════════════════════════════ VISUAL COMPARISON: .move-with-left { .move-with-transform { left: 100px; // BAD! transform: translateX(100px); // GOOD! } } Left animation: Transform animation: ┌────┬────┬────┬────┬────┐ ┌────┬────┬────┬────┬────┐ │ L │ P │ C │ L │ P │ │ C │ C │ C │ C │ C │ └────┴────┴────┴────┴────┘ └────┴────┴────┴────┴────┘ Layout every frame! Composite only! Much faster!
Frame Budget
⏱️ The 16.6ms Budget
For smooth 60fps animations, each frame must complete in 16.6ms (1000ms ÷ 60 frames).
Frame breakdown:
• JavaScript: ~10ms max
• Style + Layout + Paint + Composite: ~6ms
If any frame takes longer, you get "jank" (visible stutter)!
Optimization Best Practices
1
Animate transform/opacity
These are compositor-only properties. They skip layout and paint entirely!
2
Avoid layout thrashing
Batch DOM reads together, then batch writes. Never interleave read-write-read-write.
3
Inline critical CSS
Inline above-the-fold CSS to avoid render-blocking. Load rest async.
4
Use async/defer scripts
Don't block the HTML parser. Use defer for scripts that need DOM.
5
Don't over-use layers
Each layer costs memory. Only promote elements that actually animate.
6
Use passive listeners
For scroll/touch events, use {passive: true} to keep scrolling smooth.
Animation: Right vs Wrong
❌ Wrong: Animating left
.box {
position: absolute;
left: 0;
transition: left 0.3s;
}
.box:hover {
left: 100px; /* Triggers layout! */
}
✅ Right: Animating transform
.box {
transform: translateX(0);
transition: transform 0.3s;
}
.box:hover {
transform: translateX(100px);
/* Compositor only! */
}
Summary
🎯 The Complete Pipeline
HTML → DOM → CSSOM → Render Tree → Layout → Paint → Composite → Screen Change width: [Style] → [Layout] → [Paint] → [Composite] Change color: [Style] → → [Paint] → [Composite] Change transform: [Style] → → → [Composite] Less work = Faster! Transform/opacity skip the most steps!
Key Takeaways
| Stage | What to Optimize | Key Techniques |
|---|---|---|
| Network | Reduce latency | Preconnect, HTTP/2, CDN |
| Parsing | Don't block parser | async/defer scripts, inline critical CSS |
| Styles | Reduce complexity | Simple selectors, avoid * |
| Layout | Avoid thrashing | Batch reads/writes, use transform |
| Paint | Reduce area/complexity | Promote layers, avoid shadows |
| Composite | Use GPU | transform, opacity only |
🎉 Congratulations!
You now understand the complete browser rendering pipeline — from DNS resolution to compositing. Use this knowledge to build faster, more performant web applications!