Webpage Rendering Process

1. URL Parsing (Client to Server)

• Scheme (Protocol) - The scheme, such as https or http, indicates the protocol used to access the resource. It tells the browser which rules to follow for data transfer and often implies a default port (443 for https).

• Host (Hostname) - The host identifies the specific server hosting the resource, typically represented by a domain name (www.example.com) or an IP address. This component is resolved via DNS to find the server's physical location on the network.

• Port - The port specifies the network port on the host to connect to. While often omitted because browsers use default ports (80 for http, 443 for https), it is critical for accessing services on non-standard ports.

• Path - The path identifies the specific resource or file location on the server, such as /api/users/42. It acts like a directory structure, guiding the server to the exact data or page being requested.

• Query - The query string, starting with a question mark (?), contains key-value pairs (page=1&sort=name) that provide additional parameters to the server. These parameters allow for dynamic content retrieval, filtering, or search functionality.

• Fragment - The fragment, preceded by a hash symbol (#), identifies a secondary resource or section within the page (e.g., #section-2). Unlike other components, the fragment is never sent to the server; it is handled entirely by the browser to scroll to a specific part of the document or manage client-side routing.

2. DNS Resolution

• Browser Cache - In-memory, per-session; Chrome applies a 60-second minimum Time To Live (TTL).

• OS Cache - dnscache on Windows, mDNSResponder on macOS, systemd-resolved on Linux.

• Recursive Resolver - ISP or public like 8.8.8.8 / 1.1.1.1 which first checks its own cache, then on a miss walks the hierarchy: root > Top-Level Domain (TLD) > authoritative nameserver.

• Authoritative Nameserver - Returns the A/AAAA record with a Time To Live (TTL).

3. TCP + TLS Handshake

• A 3-way TCP handshake (SYN > SYN-ACK > ACK) establishes the connection. For HTTPS, a TLS handshake follows: the server presents its certificate, the client verifies it, and both derive a symmetric session key for encrypted communication.

4. HTTP Request

• The browser sends a GET request (with headers like Host, User-Agent, cookies) to the server on the resolved IP.

  GET /index.html HTTP/1.1
  Host: www.example.com
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0
  Accept: text/html
  Accept-Encoding: gzip, deflate
  Cookie: session=abc123

• Host - Tells the server which virtual host to serve (critical when one IP hosts many sites).
  

• User-Agent - Identifies the browser/OS so the server can tailor the response.
  

• Cookie - Carries all stored key-value pairs matching the domain and path, enabling session state.
  

  Other common headers include Accept-Language, Connection, Referer, and Sec-Fetch-*.
  
  The request is sent over the established connection to the resolved IP address on port 80 (HTTP) or 443 (HTTPS). The server processes it and returns an HTTP response with a status code, response headers, and a body.

5. Server Processing

• The web server (Nginx, Apache) either serves a static file or forwards to a backend (PHP, Node, etc.), which may query a database and assemble the response.

• Static File - Reads it from disk and returns it directly (HTML, CSS, JS, images). No application code runs.

• Dynamic Route - Forwards the request to a backend application server (PHP-FPM, Node.js, Python, etc.) via reverse proxy or FastCGI. The backend executes business logic, may query a database, assembles the response (HTML, JSON, etc.), and sends it back through the web server to the client.

  A common production pattern is Nginx in front as the reverse proxy handles TLS termination, serves static assets, and proxies all dynamic requests to the app server which keeps the fast, lightweight server focused on I/O while the app server handles logic and data access.

6. HTTP Response

• The server returns a status code (e.g., 200 OK), headers, and a body (typically an HTML document).

  HTTP/1.1 200 OK
  Content-Type: text/html; charset=utf-8
  Content-Length: 512
  Cache-Control: max-age=60

  ...

• Status line - protocol version + 3-digit status code + reason phrase. The first digit categorizes the outcome.
  
  | 1xx | Informational
  | 2xx | Success (200, 201, 204…)
  | 3xx | Redirection (301, 302, 304…)
  | 4xx | Client error (400, 401, 404…)
  | 5xx | Server error (500, 502, 503…)
  

• Headers - metadata telling the client how to handle the body: Content-Type (format), Content-Length or Transfer-Encoding: chunked (size), Cache-Control (caching), Set-Cookie, Location (for redirects), etc.
  

• Body - the actual payload: an HTML document, JSON, an image, or nothing at all (204 No Content). A blank line (CRLF) separates headers from the body; it's still present even when the body is empty.
  

  
  In HTTP/2 and HTTP/3 the text status line is replaced by a :status pseudo-header carrying just the numeric code, but the logical structure remains the same.

7. Browser Rendering

The HTML is tokenized and parsed into a tree of nodes (the Document Object Model).

• Parse HTML - (Input) HTML bytes > (Output) DOM tree

  • Pauses on synchronous <script>

Stylesheets are parsed into the CSS Object Model.

• Parse CSS - (Input) CSS bytes > (Output) CSSOM tree

  • Render-blocking - no paint until CSSOM is ready

DOM + CSSOM are merged into a render tree containing only visible, styled elements.

• Build Render Tree - (Input) DOM + CSSOM > (Output) visible nodes + computed styles

  • display: none excluded; visibility: hidden included (occupies space)

The browser calculates the exact position and size of every node.

• Layout (Reflow) - (Input) Render Tree > (Output) geometry (x, y, w, h) for every box

  • Recalculated whenever geometry changes

The render tree is converted into a list of drawing instructions (text, colors, borders, images).

• Paint - (Input) Geometry > (Output) display list (vector draw commands) > rasterized tiles

  • Fills pixels: text, colors, borders, shadows

Layers are combined and the final frame is drawn to the screen.

• Composite - (Input) Rasterized layers > (Output) final frame on GPU

  • Happens on the compositor thread, independent of the main thread

8. JavaScript Execution

Any JS (inline or external) runs in the engine (e.g., V8), which can mutate the DOM, trigger additional network requests, web APIs and cause reflows/repaints making the page interactive.

• Mutations - JavaScript can modify the DOM and CSSOM, directly altering page structure and style.

• Network Requests - JavaScript can initiate asynchronous operations via Web APIs (e.g., fetch, XMLHttpRequest), triggering new network requests without blocking the main thread.

• Reflows/Repaints - Changes to layout properties (e.g., width, height) trigger reflows (recalculating geometry), while changes to visibility (e.g., color, opacity) trigger repaints.

• Interactivity - This combination allows scripts to respond to user events, update content dynamically, and manage data flow, making the page interactive.

The whole cycle typically completes in a few hundred milliseconds, with First Contentful Paint (FCP) marking when the first content appears and Time to Interactive (TTI) marking when the page is fully responsive.

Performance & Threading

Not every change re-triggers the full pipeline.

• Layout width, height, margin, padding, top, font-size

  • Layout > Paint > Composite

• Paint color, background-color, box-shadow, border-radius

  • Paint > Composite

• Composite only transform, opacity, filter

  • Composite only

This is why animating transform/opacity is smooth — the compositor thread handles them without ever touching layout or paint on the main thread. Animating top or width forces the full cascade every frame.

• Main Thread - JS → Style → Layout → Paint (display list)

• Compositor - Scroll, transform/opacity, layer assembly (GPU)

The compositor can produce frames even when the main thread is blocked (during a long JS task), which is why compositor-only animations stay at 60 frames per second.

Let's Get Social

Be in the know by following IPv100

© 2026. IPv100 Inc.