Skip to main content

How the Web Works: Browser, Rendering, and Runtime Model

The moment a user requests a URL, a coordinated sequence of systems activates: the network delivers bytes, the browser parses them into structured documents, a rendering engine converts those documents into pixels, and a JavaScript runtime manages the logic that makes the page interactive. Understanding this end-to-end flow is the first step toward treating frontend engineering as a system discipline rather than a collection of UI code.

The High-Level Flow: From URL to Interactive Page​

When a user types a URL and presses Enter, the browser orchestrates the following macro-level phases:

  1. Navigation – resolve the domain name, establish a secure connection, and send an HTTP request.
  2. Resource fetching – receive the initial HTML document and discover subresources (CSS, JavaScript, images, fonts).
  3. Parsing – convert raw bytes into the Document Object Model (DOM) and CSS Object Model (CSSOM).
  4. Rendering – combine DOM and CSSOM into a render tree, compute layout, and paint pixels to the screen.
  5. Execution – load and execute JavaScript, attach event handlers, and enable interactivity.

Each phase involves distinct browser subsystems that operate under specific constraints. A frontend engineer who understands these constraints can anticipate performance bottlenecks, diagnose rendering issues, and design architectures that work with the platform rather than against it.

Browser Architecture: The Execution Environment​

Modern browsers (Chrome, Edge, Firefox, Safari) are multi-process applications. The key processes relevant to frontend engineering are:

  • Browser process (main process) – manages the address bar, navigation, and the top-level UI. It coordinates other processes and handles user input.
  • Renderer process – each tab typically gets its own renderer process (or site-isolated process in modern security models). The renderer contains the Blink rendering engine and the V8 JavaScript engine (in Chromium-based browsers). It is responsible for parsing, rendering, and executing JavaScript.
  • GPU process – performs compositing and rasterization on the GPU, offloading graphics work from the renderer.
  • Network process – handles all network requests independent of any single tab.
  • Plugin and extension processes – isolate third-party code.

The renderer process is sandboxed and communicates with the browser process via inter-process communication (IPC). This architecture ensures that a crash in one tab does not bring down the entire browser and that malicious code cannot directly access the operating system.

Within the renderer process, the main thread does the majority of the work: parsing, style calculation, layout, painting, and JavaScript execution. A compositor thread handles scrolling and animations by operating on layers, decoupled from the main thread. Understanding this threading model is critical for performance: the main thread is a shared, single-threaded resource that must be carefully managed.

DNS Resolution, TCP, TLS, and HTTP​

Before any bytes of HTML arrive, the browser must locate the server and establish a communication channel.

  • DNS lookup – the browser checks its own cache, the OS cache, and then queries recursive DNS servers to resolve a domain name to an IP address. A DNS resolution can take tens to hundreds of milliseconds.
  • TCP handshake – the browser opens a TCP socket to the server IP on port 80 (HTTP) or 443 (HTTPS). The three-way handshake adds one round-trip time (RTT) of latency.
  • TLS handshake – for HTTPS, a TLS handshake negotiates encryption parameters and verifies the server certificate. This adds at least one additional RTT (with TLS 1.3, reduced from older versions).
  • HTTP request – the browser sends an HTTP request (GET, POST, etc.) with headers (cookies, accept-encoding, user-agent). The server processes the request and sends back an HTTP response with status code, headers, and body (typically the HTML document).

This network overhead is a significant component of initial page load time. The browser can reuse established connections (HTTP keep-alive, HTTP/2 multiplexing) to reduce subsequent round trips, but the first navigation to a new origin always incurs the full cost. This is why resource-hint directives like preconnect and dns-prefetch exist.

HTML Parsing and DOM Construction​

When the renderer process receives the first bytes of HTML, the main thread begins parsing. The HTML parser is a state machine that follows the HTML specification, tolerating errors and constructing the DOM tree incrementally.

The process:

  1. Bytes → characters (decoded via the specified charset).
  2. Characters → tokens – the tokenizer identifies start tags, end tags, attributes, and text content.
  3. Tokens → nodes – each token produces a corresponding DOM node (element, text, comment).
  4. Nodes → DOM tree – nodes are connected in a parent-child hierarchy.

The parser can be paused. When it encounters a <script> tag without async or defer, it stops HTML parsing, fetches and executes the script, and then resumes. This is because scripts may call document.write, which alters the parsing stream. Non-blocking scripts (async, defer) allow parsing to continue while the script is fetched, but only defer scripts wait until parsing is complete before executing.

The DOM is a live, mutable in-memory representation of the document. Every frontend framework, every JavaScript manipulation of the UI, operates on this tree.

CSS Parsing and CSSOM Construction​

While HTML is being parsed, the browser also fetches and parses CSS. The process mirrors HTML parsing but has critical differences:

  • CSS is a context-free grammar, so the parser can operate in parallel on distinct stylesheets.
  • The result is the CSS Object Model (CSSOM), a tree of style rules with their selectors and property values.
  • The CSSOM is needed to determine the final computed style for every element, so it is a render-blocking resource. The browser cannot render content until CSS is parsed. However, CSS parsing does not block the DOM construction; the browser builds the DOM tree while waiting for CSS, but it will not paint until CSSOM is available.

The browser's style engine takes the CSSOM and resolves the cascade: it determines exactly which rules apply to each DOM node, computing final values for all CSS properties. This is an expensive step because every node must be matched against potentially many selectors. Inefficient selectors (deep nesting, universal selectors) increase this cost.

The Rendering Pipeline: From DOM/CSSOM to Pixels​

With the DOM and CSSOM constructed, the browser enters the rendering pipeline. This is the sequence that transforms data into the visual representation the user sees.

1. Style Calculation (Recalc)​

The style engine traverses the DOM, computes the final style for each node based on the cascade, inheritance, and default values. This produces the computed style map for every element.

2. Render Tree Construction​

The render tree (or layout tree) is a tree of visual elements that will actually be drawn. It excludes non-visual nodes (e.g., <head>, <script>, nodes with display: none). Each render tree node has its computed style attached.

3. Layout (Reflow)​

Layout determines the exact position and size of each render tree node in the viewport. The browser traverses the render tree and, based on the CSS box model and layout mode (block, inline, flex, grid), calculates geometry. Layout is a recursive process: changing one element's dimensions can ripple through ancestors, siblings, and descendants. This makes layout the most expensive phase of the pipeline.

4. Paint​

Paint converts the layout result into drawing instructions. The browser orders the visual elements into layers and paints the visual appearance (colors, borders, shadows, text, etc.) into bitmaps. Painting is performed on a per-layer basis.

5. Compositing​

The compositor thread takes the painted layers, combines them in the correct order, applies transforms and opacity, and outputs the final frame to the screen. Because compositing runs on the compositor thread, CSS transform and opacity animations can run without touching the main thread, enabling smooth 60 fps animations even if the main thread is busy.

The pipeline is not always executed from start to finish. Certain CSS property changes only trigger compositing (e.g., transform, opacity). Others trigger paint (e.g., color, box-shadow), and others force a full layout (e.g., width, margin, top). A deep understanding of which operations trigger which phases is essential for rendering performance.

JavaScript Runtime: Event Loop, Call Stack, and Asynchrony​

JavaScript runs on the same main thread as the rendering pipeline in the renderer process. The execution model is defined by three core components:

  • Call Stack – a LIFO (last-in-first-out) structure that tracks function calls. Each function invocation pushes a frame onto the stack; a return pops it. Blocking the call stack (e.g., a long-running synchronous loop) freezes all user interaction and rendering.
  • Task Queue (Macrotask Queue) – holds tasks from setTimeout, event listeners, network callbacks, and the DOM parser. The event loop picks one task from the queue when the call stack is empty and executes it.
  • Microtask Queue – holds promise callbacks (.then, catch, finally), MutationObserver callbacks, and queueMicrotask tasks. After every macrotask execution, the event loop empties the entire microtask queue before moving on to either the next macrotask or a rendering opportunity.

The event loop orchestrates this:

  1. Execute one macrotask.
  2. Drain all microtasks.
  3. If a rendering opportunity exists, perform the rendering pipeline (requestAnimationFrame callbacks, style calculation, layout, paint, composite).
  4. Repeat.

This model explains many behaviors: why setTimeout(fn, 0) does not run immediately (it must wait for the current macrotask and microtasks to finish), why long microtask chains can starve rendering, and why promise callbacks execute before setTimeout callbacks.

JavaScript is single-threaded. Concurrency is achieved through asynchronous callbacks and, more recently, Web Workers for off-main-thread computation. However, workers cannot access the DOM directly, limiting their applicability for rendering work.

The Critical Rendering Path​

The critical rendering path is the sequence of steps the browser takes to render the initial view of a page. It focuses on the resources and operations that are absolutely necessary to display content above the fold.

Key concepts:

  • Render-blocking resources – CSS and synchronous scripts. The browser must parse CSSOM before painting. Scripts without async/defer block the parser and thus delay DOM construction.
  • Parser-blocking resources – synchronous scripts. They halt HTML parsing. Place scripts at the end of the body or use async/defer.
  • Critical resources – the minimal set of HTML, CSS, and (sometimes) JavaScript needed for the first paint. The number and size of critical resources directly influence LCP (Largest Contentful Paint).

Optimizing the critical rendering path involves inlining critical CSS, deferring non-critical resources, and eliminating render-blocking JavaScript. This is a foundational performance technique that stems directly from understanding how the browser processes a page.

Putting It All Together: The Application Lifecycle​

A modern frontend application (e.g., a React or Vue app) goes through a life cycle that maps directly onto these browser subsystems:

  1. Server response – the server sends an HTML shell, often containing a minimal <div id="root"> and references to JavaScript bundles.
  2. Resource loading – the browser fetches and parses CSS, and loads JavaScript bundles (often split into vendor, common, and route-specific chunks).
  3. JavaScript initialization – the framework bootstraps, creates its own component tree (e.g., virtual DOM), and attaches event delegation. If it's a CSR app, the initial paint may be blank until this step completes.
  4. Data fetching – components initiate API requests to fetch data. The data is integrated into the framework’s state.
  5. Rendering – the framework reconciles its virtual representation with the real DOM, producing updates that flow into the browser’s rendering pipeline.
  6. Interactivity – event listeners handle user input, triggering state changes that cycle through the framework rendering and the browser pipeline again.

Each of these steps is constrained by the browser's execution and rendering model. Understanding the full stack—from network to JavaScript event loop to compositor thread—enables you to design applications that load fast, respond instantly, and degrade gracefully.

A System Perspective​

Frontend engineering is not just about writing UI components. It is about orchestrating work across multiple subsystems—network, parser, rendering engine, JavaScript runtime—under hard real-world constraints. The mental model built in this article is the foundation for all subsequent learning in FrontendDevPro. The next step is to dive deeper into each subsystem: browser internals, JavaScript execution, rendering pipeline details, and network fundamentals, all of which are covered in Frontend Foundations.

Treat the browser as an application platform. Understand its rules, and you can build systems that are robust, performant, and predictable.