Chromium / V8 Architecture | Mono Developer View

// section 01

Overview & Scale

36M+

Lines of Code

8

Major Subsystems

4-Tier

V8 JIT Pipeline

6-Stage

Render Pipeline

68%

Browser Market

Chromium is a multi-process, sandboxed browser engine that powers Chrome, Edge, Brave, Opera, and dozens of other browsers. It separates the browser chrome, web content rendering, GPU compositing, and networking into isolated processes communicating over Mojo IPC. V8, the JavaScript and WebAssembly engine, runs inside each renderer process with a 4-tier compilation pipeline from interpreter to optimizing JIT.

// high-level architecture overview

graph TD
    UI[" Browser Process 
UI, Tabs, Navigation"]
    R1[" Renderer Process 
Blink + V8"]
    R2[" Renderer Process 
Blink + V8"]
    GPU[" GPU Process 
Viz + Compositing"]
    NET[" Network Service 
net/ library"]
    STOR[" Storage Service 
IndexedDB, Cache"]
    EXT[" Extension Process 
Isolated World"]
    UTIL[" Utility Process 
Audio, Decode"]

    UI --> R1
    UI --> R2
    UI --> GPU
    UI --> NET
    UI --> STOR
    UI --> EXT
    UI --> UTIL
    R1 --> GPU
    R2 --> GPU
    R1 --> NET

    style UI fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style R1 fill:#fab387,stroke:#e89b72,color:#11111b
    style R2 fill:#fab387,stroke:#e89b72,color:#11111b
    style GPU fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style NET fill:#cba6f7,stroke:#b48fe0,color:#11111b
    style STOR fill:#f9e2af,stroke:#e5cf9a,color:#11111b
    style EXT fill:#f5c2e7,stroke:#e0aed2,color:#11111b
    style UTIL fill:#94e2d5,stroke:#7fcfc2,color:#11111b

// section 02

Process Architecture

Each major responsibility runs in a separate OS process with its own address space. The browser process is the privileged coordinator that spawns and manages all other processes. Renderer processes run in a restrictive sandbox with no direct filesystem or network access.

// process model & ipc topology

graph TD
    subgraph BROWSER["Browser Process"]
        UI_T["UI Thread"]
        IO_T["IO Thread"]
        NAV["Navigation
Controller"]
    end
    subgraph RENDERER["Renderer Process (per-site)"]
        MAIN["Main Thread
Blink + V8"]
        COMP["Compositor
Thread"]
        WORK["Web Workers"]
    end
    subgraph GPUPROC["GPU Process"]
        CMD["Command
Buffer"]
        VIZ["Viz Display
Compositor"]
    end
    subgraph NETPROC["Network Service"]
        URL["URLLoader
Factory"]
        CACHE["HTTP Cache"]
    end

    IO_T -->|"Mojo IPC"| MAIN
    IO_T -->|"Mojo IPC"| CMD
    IO_T -->|"Mojo IPC"| URL
    COMP -->|"CompositorFrame"| VIZ
    MAIN -->|"ResourceRequest"| URL

    style BROWSER fill:#1e1e2e,stroke:#89b4fa,color:#cdd6f4
    style RENDERER fill:#1e1e2e,stroke:#fab387,color:#cdd6f4
    style GPUPROC fill:#1e1e2e,stroke:#a6e3a1,color:#cdd6f4
    style NETPROC fill:#1e1e2e,stroke:#cba6f7,color:#cdd6f4
    style UI_T fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style IO_T fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style NAV fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style MAIN fill:#fab387,stroke:#e89b72,color:#11111b
    style COMP fill:#fab387,stroke:#e89b72,color:#11111b
    style WORK fill:#fab387,stroke:#e89b72,color:#11111b
    style CMD fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style VIZ fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style URL fill:#cba6f7,stroke:#b48fe0,color:#11111b
    style CACHE fill:#cba6f7,stroke:#b48fe0,color:#11111b

Browser Process

Privileged coordinator. Manages tabs, navigation, permissions, and spawns all child processes. Runs the UI thread and IO thread for IPC dispatch.

Renderer Process

One per site (site isolation). Contains Blink rendering engine and V8 JS engine. Sandboxed with no direct OS access. Main thread + compositor thread.

GPU Process

Single process for all GPU operations. Hosts the Viz display compositor and command buffer. Rasterizes tiles and composites final frames to screen.

Network Service

Sandboxed networking. Handles HTTP/HTTPS, DNS, cookies, cache, proxy resolution, and TLS. Runs as a Mojo service in its own process.

Process	Sandboxed	Threads	Key Responsibility
Browser	No (privileged)	UI, IO, ThreadPool	Coordination, navigation, permissions
Renderer	Yes (strict)	Main, Compositor, Workers	DOM, JS execution, layout, paint
GPU	Partial	Main, Display Compositor	Rasterization, compositing, display
Network	Yes	IO	HTTP, DNS, TLS, caching
Utility	Yes	Varies	Audio decode, file ops, data decode
Extension	Yes	Main + Workers	Extension service workers, APIs

// section 03

Blink Rendering Pipeline

Blink is Chromium's rendering engine (forked from WebKit in 2013). It transforms HTML/CSS into GPU-composited frames through a strict 6-stage pipeline. RenderingNG, a multi-year rewrite completed in 2022, eliminated reentrant code paths, making the pipeline fully deterministic and non-reentrant.

// rendering pipeline stages

graph LR
    DOM[" DOM 
Parse HTML"]
    STY[" Style 
Cascade + Computed"]
    LAY[" Layout 
Fragment Tree"]
    PPT[" Pre-Paint 
Property Trees"]
    PNT[" Paint 
Display Lists"]
    CMT[" Commit 
to Compositor"]
    LYR[" Layerize 
cc::Layers"]
    RAS[" Raster 
GPU Tiles"]
    DRW[" Draw 
to Screen"]

    DOM --> STY
    STY --> LAY
    LAY --> PPT
    PPT --> PNT
    PNT --> CMT
    CMT --> LYR
    LYR --> RAS
    RAS --> DRW

    style DOM fill:#f38ba8,stroke:#e07595,color:#11111b
    style STY fill:#fab387,stroke:#e89b72,color:#11111b
    style LAY fill:#f9e2af,stroke:#e5cf9a,color:#11111b
    style PPT fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style PNT fill:#89dceb,stroke:#74c7d6,color:#11111b
    style CMT fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style LYR fill:#cba6f7,stroke:#b48fe0,color:#11111b
    style RAS fill:#f5c2e7,stroke:#e0aed2,color:#11111b
    style DRW fill:#94e2d5,stroke:#7fcfc2,color:#11111b

DOM + Style

Parse HTML into a DOM tree. Run the CSS cascade algorithm to compute final styles for each node. Invalidation is fine-grained — only dirty subtrees recompute.

Layout

Generate an immutable fragment tree with box sizes and positions. LayoutNG uses a constraint-based solver replacing the legacy recursive model.

Pre-Paint + Paint

Build property trees (transform, clip, effect, scroll). Convert LayoutObject tree into display item lists — GPU-ready drawing instructions.

Commit + Composite

Copy property trees and display lists to the compositor thread. Layerize into cc::Layer list, rasterize GPU texture tiles, then composite and draw to screen via Viz.

Thread boundary: Stages DOM through Paint run on the main thread. Commit transfers data to the compositor thread, which runs Layerize, Raster, and Draw independently — enabling smooth scrolling and animations even when the main thread is blocked by JavaScript.

// section 04

V8 Engine Internals

V8 is a register-based JavaScript and WebAssembly engine with a 4-tier compilation pipeline. Code starts in the Ignition interpreter and gets promoted through increasingly aggressive compilation tiers as it gets hotter, with deoptimization bail-outs when type assumptions break.

// compilation tier pipeline

graph TD
    SRC[" JavaScript Source "]
    PARSE[" Parser 
AST Generation"]
    BC[" Bytecode 
Generator"]
    IGN[" Ignition 
Interpreter"]
    SP[" Sparkplug 
Baseline JIT"]
    MG[" Maglev 
Mid-Tier Optimizer"]
    TF[" TurboFan 
Optimizing JIT"]
    DEOPT[" Deoptimize 
Bail Out"]

    SRC --> PARSE
    PARSE --> BC
    BC --> IGN
    IGN -->|"warm"| SP
    SP -->|"warmer"| MG
    MG -->|"hot"| TF
    TF -.->|"type guard fails"| DEOPT
    MG -.->|"type guard fails"| DEOPT
    DEOPT -.-> IGN

    style SRC fill:#6c7086,stroke:#585b70,color:#cdd6f4
    style PARSE fill:#89dceb,stroke:#74c7d6,color:#11111b
    style BC fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style IGN fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style SP fill:#f9e2af,stroke:#e5cf9a,color:#11111b
    style MG fill:#fab387,stroke:#e89b72,color:#11111b
    style TF fill:#f38ba8,stroke:#e07595,color:#11111b
    style DEOPT fill:#f38ba8,stroke:#e07595,color:#11111b

Tier	Type	Compile Speed	Code Quality	When Used
Ignition	Interpreter	Instant (bytecode)	Baseline	All code initially
Sparkplug	Baseline JIT	Very fast (~1ms)	Good	Warm functions
Maglev	Mid-tier optimizer	Fast (~10ms)	Better	Warmer functions
TurboFan	Optimizing JIT	Slow (~100ms)	Best	Hot loops, stable types

Ignition Interpreter

Register-based bytecode interpreter. Generates compact bytecode from the AST. Collects type feedback (inline caches) that drives optimization decisions in higher tiers.

Sparkplug Baseline

Non-optimizing compiler that directly translates bytecode to native machine code without an IR. No register allocation — mirrors Ignition's register layout. Near-instant compilation.

Maglev Mid-Tier

Simple SSA-based optimizing compiler introduced in Chrome M117. ~10x slower to compile than Sparkplug but ~10x faster than TurboFan. Handles most warm code paths efficiently.

TurboFan Optimizer

Sea-of-nodes IR with aggressive speculative optimizations: inlining, escape analysis, bounds check elimination, and loop-invariant code motion. Produces the fastest code.

// section 05

Memory & Garbage Collection

V8's Orinoco garbage collector uses a generational strategy based on the observation that most objects die young. The heap is split into a young generation (semi-space nursery) and an old generation (mark-compact). Orinoco introduced concurrent, parallel, and incremental GC to minimize pause times.

// generational heap layout & gc strategy

graph TD
    ALLOC[" Object Allocation "]
    NURS[" Nursery 
Young Gen: From-Space"]
    TO[" To-Space 
Scavenge Copy Target"]
    INTER[" Intermediate 
Survived 1 GC"]
    OLD[" Old Generation 
Long-Lived Objects"]
    LO[" Large Object Space 
Oversized Allocs"]
    CODE[" Code Space 
JIT Machine Code"]

    ALLOC --> NURS
    NURS -->|"Scavenger (Minor GC)"| TO
    TO --> INTER
    INTER -->|"Survives again"| OLD
    OLD -->|"Mark-Compact (Major GC)"| OLD
    ALLOC -->|"large"| LO

    style ALLOC fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style NURS fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style TO fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style INTER fill:#f9e2af,stroke:#e5cf9a,color:#11111b
    style OLD fill:#fab387,stroke:#e89b72,color:#11111b
    style LO fill:#cba6f7,stroke:#b48fe0,color:#11111b
    style CODE fill:#f5c2e7,stroke:#e0aed2,color:#11111b

Scavenger (Minor GC)

Collects young generation using semi-space copying. Copies live objects from From-Space to To-Space, then swaps. Parallel scavenging across multiple threads reduces pause to ~1ms.

Mark-Compact (Major GC)

Collects old generation. Three phases: concurrent marking (off-main-thread), finalization (pause), and parallel compaction. Orinoco reduced compaction from ~7ms to under 2ms.

Concurrent Marking

Worker threads traverse the object graph while JavaScript continues to run. Write barriers track mutations. Final marking pause only processes objects modified during concurrent phase.

Incremental GC

Major GC work is broken into small increments interleaved with JavaScript execution. Prevents long pauses on heaps with millions of objects. Budget: ~1ms per increment.

// section 06

IPC & Mojo

Mojo is Chromium's cross-process communication framework, replacing the legacy IPC system. It provides language-agnostic interface definitions (Mojom IDL), type-safe message pipes, zero-copy data pipes, and shared memory buffers. Mojo is 3x faster than legacy IPC with one-third the context switching overhead.

// mojo ipc primitives

graph TD
    MOJOM[" Mojom IDL 
Interface Definition"]
    CODEGEN[" Code Generation 
C++ / Java / JS"]
    REMOTE[" Remote<T> 
Send Messages"]
    RECV[" Receiver<T> 
Handle Messages"]
    PIPE[" Message Pipe 
Bidirectional Channel"]
    DATA[" Data Pipe 
Streaming Bytes"]
    SHM[" Shared Buffer 
Zero-Copy Memory"]

    MOJOM --> CODEGEN
    CODEGEN --> REMOTE
    CODEGEN --> RECV
    REMOTE --> PIPE
    RECV --> PIPE
    PIPE --> DATA
    PIPE --> SHM

    style MOJOM fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style CODEGEN fill:#89dceb,stroke:#74c7d6,color:#11111b
    style REMOTE fill:#fab387,stroke:#e89b72,color:#11111b
    style RECV fill:#fab387,stroke:#e89b72,color:#11111b
    style PIPE fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style DATA fill:#cba6f7,stroke:#b48fe0,color:#11111b
    style SHM fill:#f9e2af,stroke:#e5cf9a,color:#11111b

// cross-process mojo connections

graph LR
    BP[" Browser Process "]
    RP[" Renderer Process "]
    GP[" GPU Process "]
    NP[" Network Service "]

    BP <-->|"content::mojom"| RP
    BP <-->|"viz::mojom"| GP
    BP <-->|"network::mojom"| NP
    RP <-->|"CompositorFrameSink"| GP
    RP -->|"URLLoaderFactory"| NP

    style BP fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style RP fill:#fab387,stroke:#e89b72,color:#11111b
    style GP fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style NP fill:#cba6f7,stroke:#b48fe0,color:#11111b

Mojom IDL: Interfaces are defined in .mojom files using a language-agnostic IDL. The build system generates type-safe bindings for C++, Java, and JavaScript. A single .mojom file can define interfaces used across all three languages.

// section 07

Compositor Architecture

Chromium's compositor (the cc library) runs on a dedicated thread in the renderer process. It takes display lists from Blink, rasterizes them into GPU texture tiles, and submits compositor frames to the Viz display compositor in the GPU process, which aggregates frames from all sources and draws to the screen.

// frame production pipeline

graph TD
    BIF[" BeginImplFrame 
VSync Signal"]
    BMF[" BeginMainFrame 
Main Thread Work"]
    CMT[" Commit 
Copy to Impl"]
    ACT[" Activate 
Pending to Active"]
    RAS[" Raster 
GPU Tile Worker"]
    DRW[" Draw 
Build Quads"]
    SWAP[" Submit Frame 
to Viz"]
    AGG[" Surface Aggregator 
Merge All Frames"]
    DISP[" Display 
to Screen"]

    BIF --> BMF
    BMF --> CMT
    CMT --> ACT
    ACT --> RAS
    RAS --> DRW
    DRW --> SWAP
    SWAP --> AGG
    AGG --> DISP

    style BIF fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style BMF fill:#fab387,stroke:#e89b72,color:#11111b
    style CMT fill:#f9e2af,stroke:#e5cf9a,color:#11111b
    style ACT fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style RAS fill:#94e2d5,stroke:#7fcfc2,color:#11111b
    style DRW fill:#cba6f7,stroke:#b48fe0,color:#11111b
    style SWAP fill:#f5c2e7,stroke:#e0aed2,color:#11111b
    style AGG fill:#f38ba8,stroke:#e07595,color:#11111b
    style DISP fill:#89dceb,stroke:#74c7d6,color:#11111b

cc Library

Chrome Compositor library. Manages layer trees, tile management, rasterization scheduling, and frame submission. Runs on the compositor thread in each renderer process.

Viz Service

Display compositor in the GPU process. Aggregates CompositorFrames from all renderer processes and the browser process into a single frame per VSync via SurfaceAggregator.

Skia / Ganesh / Graphite

2D graphics library used for rasterization. Ganesh is the OpenGL/Vulkan backend; Graphite is the next-gen backend with better batching and Dawn/WebGPU integration.

// section 08

Network Stack

The network stack runs as an isolated Mojo service (formerly in-process). It handles DNS resolution, TLS negotiation, HTTP/2 and HTTP/3 (QUIC), proxy configuration, cookie management, and the HTTP cache. Renderers request resources via URLLoaderFactory, which the browser process creates with appropriate security restrictions.

// request lifecycle

graph TD
    REQ[" Renderer 
fetch() / Resource"]
    SW[" Service Worker 
Intercept?"]
    ULF[" URLLoaderFactory 
Browser-Created"]
    UL[" URLLoader 
Network Service"]
    DNS[" Host Resolver 
DNS Lookup"]
    TLS[" SSL / TLS 
BoringSSL"]
    HTTP[" HTTP Transaction 
H2 / H3 / QUIC"]
    CACHE[" HTTP Cache 
Disk Backend"]

    REQ --> SW
    SW -->|"no intercept"| ULF
    SW -->|"respond"| REQ
    ULF --> UL
    UL --> DNS
    DNS --> TLS
    TLS --> HTTP
    UL --> CACHE

    style REQ fill:#fab387,stroke:#e89b72,color:#11111b
    style SW fill:#f5c2e7,stroke:#e0aed2,color:#11111b
    style ULF fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style UL fill:#cba6f7,stroke:#b48fe0,color:#11111b
    style DNS fill:#89dceb,stroke:#74c7d6,color:#11111b
    style TLS fill:#f38ba8,stroke:#e07595,color:#11111b
    style HTTP fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style CACHE fill:#f9e2af,stroke:#e5cf9a,color:#11111b

URLLoaderFactory

Browser-process creates factories with embedded security policies (CORS, CSP). Passes them to renderer via Mojo. Renderer cannot forge or modify factory restrictions.

Service Worker Interception

Service workers sit between the renderer and network, intercepting fetch events. Can respond from cache, modify requests, or fall through to the network. Enables offline-first PWAs.

QUIC / HTTP/3

Chromium pioneered QUIC (now IETF HTTP/3). UDP-based, 0-RTT connection establishment, multiplexed streams without head-of-line blocking, built-in encryption via TLS 1.3.

// section 09

Extensions System

Chrome extensions run in isolated processes with controlled API access. Manifest V3 replaced persistent background pages with event-driven service workers. Content scripts run in an isolated JavaScript world within web pages — same DOM, separate JS context.

// extension architecture (manifest v3)

graph TD
    MF[" manifest.json 
Permissions + Config"]
    SW[" Service Worker 
Background Logic"]
    CS[" Content Script 
Isolated World"]
    POP[" Popup / SidePanel 
Extension UI"]
    API[" Chrome APIs 
tabs, storage, etc."]
    WEB[" Web Page 
DOM Access"]
    BP[" Browser Process 
Permission Broker"]

    MF --> SW
    MF --> CS
    MF --> POP
    SW --> API
    CS --> WEB
    POP --> API
    API --> BP
    CS -->|"messaging"| SW

    style MF fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style SW fill:#fab387,stroke:#e89b72,color:#11111b
    style CS fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style POP fill:#f9e2af,stroke:#e5cf9a,color:#11111b
    style API fill:#cba6f7,stroke:#b48fe0,color:#11111b
    style WEB fill:#89dceb,stroke:#74c7d6,color:#11111b
    style BP fill:#f5c2e7,stroke:#e0aed2,color:#11111b

Service Worker Background

Event-driven, no persistent state. Wakes on events (alarms, messages, web requests), processes them, then sleeps. 5-minute idle timeout. Replaces Manifest V2 background pages.

Content Scripts

Injected into web pages matching manifest patterns. Run in an isolated JavaScript world — share the DOM but have a separate JS context. Cannot access page's JS variables directly.

Permissions Model

Declared in manifest.json, granted by user at install. Chrome APIs (tabs, cookies, storage, webRequest) are gated by permission. Host permissions control which sites can be accessed.

// section 10

Security Model

Chromium's security architecture enforces defense-in-depth through three layers: process isolation (site isolation), OS-level sandboxing, and browser-enforced IPC restrictions. A compromised renderer process cannot access cross-site data, modify permissions, or escape the sandbox to reach the filesystem.

// security layers

graph TD
    WEB[" Web Content 
Untrusted Input"]
    REND[" Renderer Sandbox 
seccomp-BPF / macOS Seatbelt"]
    SITE[" Site Isolation 
Process-per-Site"]
    IPC[" IPC Validation 
Browser Checks All"]
    BROWSER[" Browser Kernel 
Privileged Process"]
    OS[" OS / Hardware 
Process Boundaries"]

    WEB --> REND
    REND --> SITE
    SITE --> IPC
    IPC --> BROWSER
    BROWSER --> OS

    style WEB fill:#f38ba8,stroke:#e07595,color:#11111b
    style REND fill:#fab387,stroke:#e89b72,color:#11111b
    style SITE fill:#f9e2af,stroke:#e5cf9a,color:#11111b
    style IPC fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style BROWSER fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style OS fill:#cba6f7,stroke:#b48fe0,color:#11111b

Site Isolation

Each site gets its own renderer process. Cross-site iframes run in separate processes. Prevents Spectre-style side-channel attacks and UXSS. Enforced since Chrome 67.

Sandbox

Renderers run in OS-level sandboxes: seccomp-BPF (Linux), macOS Seatbelt, Win32 restricted tokens. No filesystem, network, or device access. All I/O brokered through the browser process.

Rule of Two

Chromium's security rule: of (untrusted data, unsafe language, unsandboxed process), at most two are allowed. Processing untrusted data in C++ requires sandboxing.

IPC Validation

Browser process validates all Mojo messages from renderers. A compromised renderer cannot request cross-site cookies, use another site's permissions, or navigate to privileged URLs.

// section 11

DevTools Architecture

Chrome DevTools is a web application communicating with the browser via the Chrome DevTools Protocol (CDP). The protocol uses JSON-RPC 2.0 over WebSocket, with domain-specific agents in both the renderer (Blink/V8) and browser process. The frontend is a three-layer architecture: UI panels, SDK models, and generated protocol bindings.

// cdp architecture

graph LR
    FE[" DevTools Frontend 
Web App (TypeScript)"]
    WS[" WebSocket 
JSON-RPC 2.0"]
    BA[" Browser Agents 
Page, Target, Security"]
    RA[" Renderer Agents 
DOM, CSS, Network"]
    V8A[" V8 Agents 
Debugger, Profiler"]

    FE <-->|"CDP"| WS
    WS <--> BA
    WS <--> RA
    WS <--> V8A

    style FE fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style WS fill:#f9e2af,stroke:#e5cf9a,color:#11111b
    style BA fill:#fab387,stroke:#e89b72,color:#11111b
    style RA fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style V8A fill:#cba6f7,stroke:#b48fe0,color:#11111b

CDP Domains

Protocol organized into domains: Page, DOM, CSS, Network, Runtime, Debugger, HeapProfiler, Performance. Each domain has methods, events, and types defined in PDL files.

Frontend Architecture

Three layers: UI panels interact with SDK models via high-level APIs. SDK models abstract protocol details. Protocol layer is auto-generated from PDL and handles serialization.

Remote Debugging

Start Chrome with --remote-debugging-port=9222 to expose CDP over WebSocket. Used by Puppeteer, Playwright, Selenium, and IDE debuggers for browser automation.

// section 12

Component Interconnections

End-to-end data flow from URL bar to pixels on screen, showing how a navigation request traverses every major subsystem in Chromium.

// full navigation data flow

sequenceDiagram
    participant User
    participant Browser as Browser Process
    participant Network as Network Service
    participant Renderer as Renderer (Blink+V8)
    participant Compositor as Compositor Thread
    participant GPU as GPU / Viz

    User->>Browser: Enter URL
    Browser->>Network: URLLoader request
    Network-->>Browser: Response headers
    Browser->>Renderer: Commit navigation
    Network-->>Renderer: Stream body bytes
    Renderer->>Renderer: Parse HTML + Execute JS
    Renderer->>Renderer: Style + Layout + Paint
    Renderer->>Compositor: Commit display lists
    Compositor->>GPU: Raster tiles + Submit frame
    GPU->>GPU: Aggregate + Display

// subsystem dependency map

graph TD
    BLINK[" Blink 
Rendering Engine"]
    V8E[" V8 
JS / Wasm Engine"]
    CC[" cc 
Chrome Compositor"]
    VIZS[" Viz 
Display Compositor"]
    SKIA[" Skia 
2D Graphics"]
    MOJO[" Mojo 
IPC Framework"]
    NETL[" net/ 
Network Library"]
    BASE[" base/ 
Core Utilities"]

    BLINK --> V8E
    BLINK --> CC
    BLINK --> MOJO
    CC --> VIZS
    CC --> SKIA
    VIZS --> SKIA
    NETL --> MOJO
    BLINK --> BASE
    V8E --> BASE
    MOJO --> BASE

    style BLINK fill:#fab387,stroke:#e89b72,color:#11111b
    style V8E fill:#a6e3a1,stroke:#8fd18a,color:#11111b
    style CC fill:#89dceb,stroke:#74c7d6,color:#11111b
    style VIZS fill:#94e2d5,stroke:#7fcfc2,color:#11111b
    style SKIA fill:#f5c2e7,stroke:#e0aed2,color:#11111b
    style MOJO fill:#89b4fa,stroke:#74a0e8,color:#11111b
    style NETL fill:#cba6f7,stroke:#b48fe0,color:#11111b
    style BASE fill:#f9e2af,stroke:#e5cf9a,color:#11111b

~16ms

Frame Budget (60fps)

<100ms

Input Latency Target

0-RTT

QUIC Reconnect

<2ms

GC Compaction

~1ms

Minor GC Pause