Browser & Runtime Internals

All Articles (19 articles)

• Critical Rendering Path: Rendering Pipeline Overview

  Browser & Runtime Internals / Critical Rendering Path 14 min read

  The 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 read

  How 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 read

  The 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 read

  Style 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 read

  Layout 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 read

  Prepaint 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 read

  The 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 read

  Commit 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 read

  The 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 read

  Rasterization 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 read

  How 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 read

  The 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 read

  V8’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 read

  Modern 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 read

  Spec-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 read

  Node.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 read

  Explore 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 read

  As 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 read

  The 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.