1. The Intuition: The Multi-Process Assembly Plant Analogy

1.1 The Multi-Process Assembly Plant Analogy

Imagine a modern automotive manufacturing plant building custom sports cars. The factory does not rely on a single worker to read blueprints, forge engine parts, paint the chassis, and drive the car off the assembly line. Doing so would mean any single delay (e.g. waiting 3 hours for chassis paint to dry) halts the entire production line!

Instead, the plant operates with specialized, isolated departments: the **Architectural Department (Browser Process)** handles security permissions and user UI controls. The **Design Department (Renderer Main Thread)** converts text specifications into 3D CAD models (DOM & Layout Tree). The **Paint Department (Paint Engine)** records detailed painting commands into display lists. Finally, the **Assembly Line Operators (Compositor Thread & GPU Process)** slice the car into independent sub-assemblies (Layers) and assemble them at lightning speed (60 FPS GPU Compositing)!

Diagram: Chromium rendering pipeline streaming from HTML network bytes to GPU tile rasterization.

1.2 The Historical Evolution of Rendering Engines

Browser rendering architecture has evolved through three distinct technological eras over the past 25 years:

• Monolithic Single-Process Era (Internet Explorer 6, Firefox 1-3): A single operating system process handled networking, DOM rendering, JavaScript, and UI tabs. A single page error crashed the entire web browser window!
• Multi-Process Tab Isolation Era (Chrome 2008): Google introduced per-tab process isolation, sandboxing un-trusted Renderer processes from sensitive OS system APIs.
• Off-Main-Thread GPU Compositing Era (Modern Blink, WebKit, Gecko Servo): Splitting layout calculations from GPU layer compositing allowed smooth 60 FPS scrolling even when the Main Thread was temporarily busy executing JavaScript loops!

Pitfall — Blocking the Renderer Main Thread with Synchronous JS: JavaScript execution, DOM parsing, Style calculations, Layout reflow, and Paint recording all run on the **same single Main Thread** inside the Renderer Process! If a JavaScript event handler executes a long loop for 50 milliseconds, the Main Thread cannot compute Layout or record Paint, causing the browser to drop 3 consecutive frames (jank)! Always offload heavy computational tasks to Web Workers.

2. Architectural Deep Dive: Main Thread vs Compositor Thread vs GPU

2.1 Multi-Process Browser Process Architecture

Modern browsers like Chrome utilize a multi-process architecture to isolate tabs and prevent a single crashing web page from bringing down the entire browser window:

2.2 Inter-Process Communication (Mojo IPC) Overhead

How do separate OS processes communicate without risking security leaks? Chromium uses **Mojo IPC (Inter-Process Communication)** to serialize message payloads across process boundaries:

When a user scrolls a page, the OS sends touch inputs to the **Browser Process**, which forwards raw input events via Mojo IPC to the **Renderer Compositor Thread**. The Compositor calculates scroll offsets directly without waiting for V8 JavaScript execution on the Main Thread!

3. Under the Hood: The 6-Stage Rendering Pipeline

3.1 Dissecting the 6 Rendering Stages

Converting raw HTML/CSS strings into visible screen pixels involves 6 sequential stages executed by the rendering engine:

Modifying different CSS properties invalidates different stages of the rendering pipeline!

3.2 Chromium LayoutNG Architecture

In legacy browser engines, layout reflow was computed recursively through mutable C++ object pointers, making multi-core parallelization impossible. Chromium's **LayoutNG** engine rearchitected Layout into an immutable, functional pipeline:

• Layout Inputs (`NGConstraintSpace`): An immutable struct containing available inline/block sizes, writing modes, and float exclusions passed down to child boxes.
• Layout Outputs (`NGPhysicalFragment`): An immutable tree of 2D physical fragments outputting exact offsets without mutating parent DOM tree pointers!

3.3 CSS Selector Matching Complexity & Style Invalidation

Why do deeply nested descendant selectors like `body div.container ul li a.button` slow down Style Recalculation? Browsers evaluate CSS selector rules **from right to left** (key selector matching):

When evaluating `.button`, the engine first identifies all elements matching `.button` across the entire document. For every candidate element, it recursively traverses up parent DOM node pointers to verify whether the parent matches `a`, `li`, `ul`, `.container`, and `body`. Using atomic class utilities (like Tailwind CSS) reduces selector matching time to constant $O(1)$ dictionary lookups!

4. Shadow DOM & Web Components Encapsulation

4.1 Shadow DOM Tree Boundaries & CSS Isolation

The **Shadow DOM** allows developers to attach an encapsulated DOM subtree (`ShadowRoot`) to a host element. Styles declared inside a ShadowRoot do not leak out to the document DOM, and global page CSS selectors do not affect the internal shadow tree:

4.2 Slot Projection & Declarative Shadow DOM (DSD)

How does the rendering engine compose light DOM content passed into `` elements inside the shadow tree? Elements assigned to slots are not physically moved in the C++ DOM tree; they undergo **Flat Tree Composition**:

The rendering engine constructs a parallel **Composed Flat Tree** for style inheritance and layout calculation. During style resolution, slotted elements inherit styles from both the light DOM parent document and internal `::slotted()` CSS rules defined inside the shadow tree!

4.3 Performance Optimization with `adoptedStyleSheets`

Instantiating 10,000 custom web component instances by parsing inline `