Browser & Runtime Internals
Deep dives into browser rendering and JavaScript runtime internals.
-
Critical Rendering Path: Rendering Pipeline Overview
Browser & Runtime Internals / Critical Rendering Path 14 min readThe browser’s rendering pipeline transforms HTML, CSS, and JavaScript into visual pixels through a series of discrete, highly optimized stages. Modern browser engines like Chromium employ the RenderingNG architecture—a next-generation rendering system developed between 2014 and 2021—which decouples the main thread from the compositor and GPU processes to ensure 60fps+ performance and minimize interaction latency.
-
Critical Rendering Path: DOM Construction
Browser & Runtime Internals / Critical Rendering Path 13 min readHow browsers parse HTML bytes into a Document Object Model (DOM) tree, why JavaScript loading strategies dictate performance, and how the preload scanner mitigates the cost of parser-blocking resources.
-
Critical Rendering Path: CSSOM Construction
Browser & Runtime Internals / Critical Rendering Path 10 min readThe CSS Object Model (CSSOM) is the browser engine’s internal representation of all CSS rules—a tree structure of stylesheets, rule objects, and declaration blocks. Unlike DOM construction, which is incremental, CSSOM construction must complete entirely before rendering can proceed. This render-blocking behavior exists because the CSS cascade requires the full rule set to resolve which declarations win.
-
Critical Rendering Path: Style Recalculation
Browser & Runtime Internals / Critical Rendering Path 10 min readStyle Recalculation transforms the DOM and CSSOM into computed styles for every element. The browser engine matches CSS selectors against DOM nodes, resolves cascade conflicts, and computes absolute values—producing the ComputedStyle objects that the Layout stage consumes. In Chromium’s Blink engine, this phase is handled by the StyleResolver, which uses indexed rule sets, Bloom filters, and invalidation sets to minimize work on each frame.
-
Critical Rendering Path: Layout Stage
Browser & Runtime Internals / Critical Rendering Path 12 min readLayout is the rendering pipeline stage that transforms styled elements into physical geometry—computing exact pixel positions and sizes for every visible box. In Chromium’s LayoutNG architecture, this stage produces the Fragment Tree, an immutable data structure describing how elements are broken into boxes (fragments) with resolved coordinates.
-
Critical Rendering Path: Prepaint
Browser & Runtime Internals / Critical Rendering Path 14 min readPrepaint is a RenderingNG pipeline stage that performs an in-order traversal of the LayoutObject tree to build Property Trees and compute paint invalidations. It decouples visual effect state (transforms, clips, filters, scroll offsets) from the paint and compositing stages, enabling compositor-driven animations and off-main-thread scrolling.
-
Critical Rendering Path: Paint Stage
Browser & Runtime Internals / Critical Rendering Path 11 min readThe Paint stage records drawing instructions into display lists—it does not produce pixels. Following Prepaint (property tree construction and invalidation), Paint walks the layout tree and generates a sequence of low-level graphics commands stored in Paint Artifacts. These artifacts are later consumed by the Rasterization stage, which executes them to produce actual pixels on the GPU.
-
Critical Rendering Path: Commit
Browser & Runtime Internals / Critical Rendering Path 12 min readCommit is the synchronization point where the Main Thread hands over processed frame data to the Compositor Thread. This blocking operation ensures the compositor receives an immutable, consistent snapshot of property trees and display lists—enabling the dual-tree architecture that allows rasterization to proceed independently while the main thread prepares the next frame.
-
Critical Rendering Path: Layerize
Browser & Runtime Internals / Critical Rendering Path 9 min readThe Layerize stage converts paint chunks into composited layers (cc::Layer objects), determining how display items should be grouped for independent rasterization and animation. This process happens after Paint produces the paint artifact and before Rasterization converts those layers into GPU textures.
-
Critical Rendering Path: Rasterization
Browser & Runtime Internals / Critical Rendering Path 10 min readRasterization is the process where the browser converts recorded display lists into actual pixels—bitmaps for software raster or GPU textures for hardware-accelerated paths. This stage marks the transition from abstract paint commands to concrete visual data. In Chromium, rasterization is managed by the compositor thread and executed by worker threads, ensuring smooth interactions even when the main thread is saturated with JavaScript or layout work.
-
Critical Rendering Path: Compositing
Browser & Runtime Internals / Critical Rendering Path 13 min readHow the compositor thread assembles rasterized layers into compositor frames and coordinates with the Viz process to display the final pixels on screen.
-
Critical Rendering Path: Draw
Browser & Runtime Internals / Critical Rendering Path 12 min readThe Draw stage is the final phase of the browser’s rendering pipeline. The Viz process (Visuals) in Chromium takes abstract compositor frames—consisting of render passes and draw quads—and translates them into low-level GPU commands to produce actual pixels on the display.
-
V8 Engine Architecture: Parsing, Optimization, and JIT
Browser & Runtime Internals / JavaScript Runtime Internals 18 min readV8’s multi-tiered compilation pipeline—Ignition interpreter through TurboFan optimizer—achieves near-native JavaScript performance while maintaining language dynamism. This analysis covers the four-tier architecture (as of V8 12.x / Chrome 120+), the runtime’s hidden class and inline caching systems that enable speculative optimization, and the Orinoco garbage collector’s parallel/concurrent strategies.
-
Browser Architecture: Processes, Caching, and Extensions
Browser & Runtime Internals / JavaScript Runtime Internals 17 min readModern browsers are multi-process systems with sophisticated isolation boundaries, layered caching hierarchies, and extension architectures that modify page behavior at precise lifecycle points. This article maps Chromium’s process model (browser, renderer, GPU, network, utility processes), the threading architecture within renderers (main thread, compositor, raster workers), caching layers from DNS through HTTP disk cache, speculative loading mechanisms, and extension content script injection timing.
-
Browser Event Loop: Tasks, Microtasks, Rendering, and Idle Time
Browser & Runtime Internals / JavaScript Runtime Internals 15 min readSpec-accurate map of the WHATWG HTML Living Standard event loop in window and worker contexts, centered on task selection, microtask checkpoints, rendering opportunities, and idle scheduling. Focus is on latency and frame-budget trade-offs rather than beginner JavaScript async basics.
-
Node.js Runtime Architecture: Event Loop, Streams, and APIs
Browser & Runtime Internals / JavaScript Runtime Internals 13 min readNode.js is a host environment that pairs V8 with libuv, a C++ bindings layer, and a large set of JavaScript core modules and Application Programming Interfaces (APIs). This article focuses on the runtime boundaries that matter at scale: event loop ordering, microtasks, thread pool backpressure, buffer and stream memory, and Application Binary Interface (ABI) stable extension points. Coverage is current as of Node.js 22 LTS (libuv 1.49+, V8 12.4+).
-
libuv Internals: Event Loop and Async I/O
Browser & Runtime Internals / JavaScript Runtime Internals 36 min readExplore libuv’s event loop architecture, asynchronous I/O capabilities, thread pool management, and how it enables Node.js’s non-blocking, event-driven programming model.
-
Node.js Event Loop: Phases, Queues, and Process Exit
Browser & Runtime Internals / JavaScript Runtime Internals 10 min readAs of Node.js 22 LTS (libuv 1.48.0), this article covers how Node schedules input/output (I/O): libuv phases first, then V8 (the JavaScript engine) microtasks and process.nextTick(), and finally process exit conditions. Includes a spec-precise contrast to the Hypertext Markup Language (HTML) event loop and the ECMAScript job queue.
-
JS Event Loop: Tasks, Microtasks, and Rendering (For Browser & Node.js)
Browser & Runtime Internals / JavaScript Runtime Internals 17 min readThe event loop is not a JavaScript language feature—it is the host environment’s mechanism for orchestrating asynchronous operations around the engine’s single-threaded execution. Browsers implement the WHATWG HTML Standard processing model optimized for UI responsiveness (60 frames per second, ~16.7ms budgets). Node.js implements a phased architecture via libuv, optimized for high-throughput I/O (Input/Output). Understanding both models is essential for debugging timing issues, avoiding starvation, and choosing the right scheduling primitive.