How Modern Browsers Work: Inside Chromium, Blink, V8 and Multi‑Process Architecture
This article walks through the complete lifecycle of a web page in modern browsers, covering network fetching, HTML/CSS parsing, layout calculation, painting and GPU compositing, the V8 JavaScript engine pipeline, module loading, multi‑process isolation, and key differences among Chromium, Gecko and WebKit implementations.
1. Network and Resource Loading
When a user enters a URL, the browser UI thread in the browser process initiates a navigation request. The network stack resolves the domain via DNS (or DoH), establishes a TCP/TLS connection, performs the TLS handshake for HTTPS, and then sends an HTTP request, preferring HTTP/2 or HTTP/3 when supported. Responses are streamed; missing or incorrect Content-Type triggers MIME sniffing and security checks such as CORB. Chrome’s Network Service runs in a separate process, isolating the renderer from direct network access.
Chrome also performs speculative optimizations: DNS prefetch, preconnect, and a preload scanner that scans ahead in the HTML stream to discover resources (images, scripts, styles) that can be fetched in parallel, though dynamically injected resources cannot be preloaded.
2. HTML, CSS, and JavaScript Parsing
The renderer process receives the HTML and parses it incrementally into a DOM tree. Errors like missing </p> are auto‑corrected. While parsing, the browser requests linked resources (e.g., <link rel="stylesheet">, <img src="...">) in parallel. Encountering a <script> without defer or async pauses parsing, executes the script (because it may call document.write()), then resumes parsing.
CSS is parsed into a CSSOM. The style system matches selectors, computes the computed style for each DOM node, and resolves cascade, inheritance and default user‑agent styles.
3. Style and Layout
With DOM and CSSOM ready, the layout engine builds a layout tree (or render tree) that contains only visual elements. It calculates each box’s geometry according to the CSS box model, flexbox, grid, and other layout algorithms. Elements with display:none are omitted; pseudo‑elements like ::before generate boxes. Layout proceeds recursively from <html> downwards, handling size dependencies and performing incremental re‑layout when scripts modify the DOM or styles.
4. Painting, Composition, and GPU Rendering
After layout, the renderer records paint commands (paint records) for each layer. Modern browsers split work into layers; elements with transform, opacity, video, or canvas often get their own layer. The compositor thread (separate from the main thread) rasterizes these layers—Chrome rasterizes on the CPU then uploads bitmaps to the GPU, while Firefox’s WebRender rasterizes directly on the GPU using display lists. Layers are tiled (e.g., 256 × 256 px) and sent to the GPU process, which composites them via OpenGL/DirectX/Metal into the final frame. This design enables smooth scrolling and animation because only transformed layers need updating.
5. V8 JavaScript Engine
V8 parses JavaScript into an AST, then compiles to bytecode executed by the Ignition interpreter. Since Chrome 66, background threads can compile scripts, reducing main‑thread parse time by 5‑20 %. V8 employs a tiered JIT: Ignition (interpreter), Sparkplug (baseline JIT), Maglev (mid‑tier optimizer introduced in 2023), and TurboFan (high‑tier optimizer). Hot functions eventually reach TurboFan, which generates highly optimized machine code; newer versions are migrating to the Turboshaft IR. V8 also performs profile‑guided tiering and explicit compile hints to improve start‑up performance.
Garbage collection uses the Orinoco GC with generational, incremental and concurrent phases, minimizing pause times. Bytecode flushing reclaims unused bytecode after several GC cycles.
6. Module Loading and Import Maps
ES 6 modules are fetched asynchronously, building a dependency graph before execution. Static imports wait for all dependencies; dynamic import() returns a promise that resolves after the module and its deps are loaded. Import Maps let developers map bare specifiers (e.g., "react") to real URLs, enabling unbundled development without a build step. All modern browsers support this feature (Chrome 89+, Firefox 108+, Safari 16.4+).
7. Multi‑Process Architecture
Chromium uses a central browser process for UI and coordination, a separate renderer process per tab (or per site with strict site isolation), a GPU process, a Network Service process, and various utility processes (audio, video, extensions). This isolation improves stability, security (sandboxing), and performance isolation. Firefox’s Electrolysis (e10s) and Project Fission provide similar content‑process isolation, while Safari’s WebKit2 uses a UI process and per‑tab WebContent processes.
Site isolation (OOPIF) ensures cross‑origin iframes run in separate processes, mitigating Spectre attacks. Sandboxing restricts system calls via OS mechanisms (seccomp, job objects, namespaces).
8. Engine Differences
CSS : Blink (single‑threaded C++), Gecko’s Stylo (Rust, multi‑threaded), WebKit (single‑threaded with selector JIT).
Layout & Rendering : Chrome rasterizes on CPU, Firefox’s WebRender rasterizes on GPU, Safari uses CoreAnimation layers.
JavaScript : V8 (Ignition/Sparkplug/Maglev/TurboFan), SpiderMonkey (Baseline/WarpMonkey), JavaScriptCore (LLInt/Baseline/DFG/FTL with LLVM).
Process Model : Chrome – many processes per site; Firefox – limited content processes; Safari – per‑tab processes.
9. Takeaways
Understanding the browser pipeline explains why practices like minimizing reflows, using async / defer, preferring transform / opacity for animation, and leveraging HTTP/2/3, caching, and import maps improve performance and reliability. DevTools (Performance, Network, Memory) expose each stage, helping developers diagnose bottlenecks.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
AI Tech Publishing
In the fast-evolving AI era, we thoroughly explain stable technical foundations.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.