You type a URL, press Enter, and a page appears. From the user’s perspective, that feels like one action. Inside the browser, it is a chain of network and rendering steps: the browser resolves a name, establishes a connection, requests a document, parses streamed bytes, discovers more resources, builds internal trees, runs code, and finally responds to input.
The order is not merely academic. It explains why a page can show text before images, why a stylesheet can delay visual changes, why a JavaScript file can block parsing, and why a fast server does not guarantee a fast interaction. The MDN guide to how browsers work describes this process through navigation, response, parsing, rendering, and interactivity. This article follows the same path in a smaller, practical model.
1. The browser turns a URL into a navigation
A URL identifies a resource through several pieces of information: a scheme such as https, a host name, an optional port, a path, and sometimes a query string or fragment. The browser first decides what kind of navigation is being requested and whether it can reuse information from cache, a service worker, a connection, or a previous DNS lookup.
A simplified timeline looks like this:
URL
↓
DNS lookup
↓
Connection and TLS
↓
HTTP request
↓
HTML response
↓
DOM + CSSOM
↓
Render tree → layout → paint
↓
JavaScript and user interaction
This is a model, not a promise that every browser performs every step in exactly the same visible order. Browsers overlap work whenever possible. A preload scanner can discover resources while the main HTML parser is still processing the document, and cached resources can remove network steps entirely.
2. DNS answers “which server?”
The browser cannot send an HTTP request to example.com until it can associate the host name with an IP address. The Domain Name System provides that mapping. The result may come from the browser cache, the operating system, a recursive resolver, or an authoritative DNS server.
DNS is not the same as downloading the page. It only helps the client find where to connect. If DNS is slow, the request cannot begin. If DNS is fast but the origin server takes a long time to generate the response, the page can still feel slow.
When investigating a navigation, separate name resolution from the rest of the request. The browser’s Network panel and performance tools can show timing phases such as DNS, connection, request, response, and download. Treating all waiting as “the server” hides the real bottleneck.
3. HTTPS adds a secure connection step
With HTTPS, the browser negotiates a secure TLS connection before sending application data. The connection also depends on transport details such as TCP or newer protocols, network distance, congestion, and whether a reusable connection already exists.
The important beginner distinction is this: HTTPS protects the communication channel; it does not make application code automatically safe or correct. A page can be served over HTTPS and still contain a broken selector, an insecure dependency, or a server-side authorization error.
Once the connection is ready, the browser sends an HTTP request. A simplified request might look like this:
GET /courses/javascript HTTP/1.1
Host: example.com
Accept: text/html
The response contains a status code, headers, and a body. The status describes the result at the HTTP level; the body contains the representation the browser must interpret.
4. The first response is usually a document, not a finished page
A typical document response includes HTML. The browser starts consuming it as bytes arrive instead of waiting for the entire file to download. It tokenizes the markup and creates nodes in the Document Object Model, or DOM.
Consider this small document:
<!doctype html>
<html>
<head>
<title>Loading example</title>
</head>
<body>
<h1>Hello</h1>
<p>Content can be parsed incrementally.</p>
</body>
</html>
The HTML source is text. The DOM is the browser’s structured, in-memory representation of that text. The WHATWG HTML parsing specification defines the rules browsers use to turn text/html into a tree, including how they handle malformed markup.
The DOM is not a screenshot. It is not a direct list of pixels. It is a set of objects and relationships that scripts and browser subsystems can inspect and update. Read What Is the DOM in JavaScript? for a focused explanation of nodes, selection, and events.
5. CSS creates a second structure
When the parser finds a stylesheet, the browser fetches it and parses the CSS into the CSS Object Model, or CSSOM. The CSSOM represents rules and declarations that can apply to the document. The browser then combines the DOM and CSSOM to determine how visible content should be styled.
A stylesheet can therefore affect the critical rendering path. This does not mean every stylesheet blocks every activity in the same way, but it does mean the browser needs enough style information to calculate a trustworthy visual result.
The MDN critical rendering path guide describes the relationship among the DOM, CSSOM, render tree, layout, and paint. A useful mental model is:
| Internal result | What it represents | What it enables |
|---|---|---|
| DOM | Document structure and nodes | Finding elements and understanding relationships |
| CSSOM | Parsed style rules | Calculating applicable styles |
| Render tree | Visible, styled objects | Deciding what participates in rendering |
| Layout | Size and position | Placing boxes in the viewport |
| Paint | Visual instructions | Drawing text, colors, borders, and images |
Elements such as display: none can exist in the DOM while being absent from the render tree. Conversely, a pseudo-element can appear visually without being a normal DOM element you selected with querySelector().
6. The render tree becomes layout and pixels
After enough structure and style information is available, the browser builds a render tree, calculates layout, and paints. Layout answers questions such as how wide a block is and where it should appear. Paint turns that result into drawing operations. Compositing can then combine layers, especially for effects and animations.
A page can look visually complete before every non-critical resource has finished. Images, fonts, advertisements, and below-the-fold content may continue loading. This is why “the page appeared” and “the page is fully loaded” are not identical measurements.
Modern performance work uses user-centered metrics rather than a single load event. The browser exposes timing information through APIs, and tools such as the Performance panel show long tasks, resource waterfalls, layout shifts, and scripting time. The right metric depends on the experience being measured: first content, visual stability, or readiness for interaction.
7. JavaScript can change the schedule
When the parser reaches a classic script without async or defer, it may pause while the browser fetches and executes that script. The code can inspect the DOM that has already been parsed, but it cannot see markup the parser has not reached yet.
A deferred external script downloads while parsing and runs after document parsing. An async script downloads in parallel and executes as soon as it is ready, without preserving the order other async scripts appear in the HTML. Module scripts are deferred by default and use explicit imports. The MDN script element reference explains these differences.
This is why script placement and loading attributes matter. A script may be correct in isolation and still fail because it runs before the element it needs or because a dependency has not executed yet. How to Add JavaScript to an HTML Page turns those choices into a practical comparison.
8. Interactivity is another phase, not the same as paint
A page can be painted and still not be ready for a useful click. JavaScript may be parsing, compiling, executing, attaching event listeners, or making additional network requests. Long tasks on the main thread can delay input even when the page looks finished.
For a button to respond, several things must be true:
- The button must exist in the DOM.
- The script must have found the intended element.
- The event listener must have been attached.
- The main thread must be available to handle the event.
- The handler must complete without throwing an error.
A useful diagnostic separates these conditions. Log the selector result, inspect the listener setup, watch the Console, and use the Performance panel when the handler is delayed rather than missing.
What the request waterfall can tell you
A network waterfall is a story about dependencies and waiting. A long DNS segment points toward name resolution. A long connection segment may indicate handshake or network conditions. A long waiting segment before the first byte can indicate server processing or an upstream dependency. A large download may point toward response size or compression. A long scripting task appears after a resource arrives and can delay interaction.
Do not treat every bar as an optimization target. Removing a useful stylesheet or delaying essential code can make one number look better while damaging the actual experience. Start with the user-visible problem, measure it, and change the smallest responsible part.
A practical performance reading exercise
Open a page in DevTools and record five observations: the document request, the first stylesheet, the first script, the first meaningful visual content, and the first interaction you can perform. Then ask where each item sits in the timeline. Which resources are discovered from the document? Which requests are blocked by dependencies? Which long task occurs before the interaction?
This exercise connects the abstractions to a real page. You do not need to memorize every browser subsystem. You need to know whether a delay is caused by finding the server, receiving the response, building the page, running code, or handling input.
A browser does not simply “download HTML and display it.” It coordinates a network pipeline, parser, DOM, CSSOM, rendering engine, JavaScript runtime, and event system. Understanding that chain makes performance bugs less mysterious and makes later topics—DOM scripting, APIs, and script loading—much easier to reason about.
Continue with: How to Add JavaScript to an HTML Page to understand script timing, or Introduction to APIs for Beginners to follow what happens after a page makes a request.
Alex Carter is the editorial name behind Vandutz Academy, a programming blog for beginners. Alex reviews and tests the examples and explanations published on the site, with a focus on making Python, JavaScript, web development, and developer tools easier to understand.