code with zaheer

How the web works · A visual walkthrough

In this article, I’ll guide you through an overview of what happens when you navigate to a website using your browser. Whether you’re new to web development or have some experience, this post will help you gain a better understanding of how the web and its core technologies work.

20 min read14 interactive diagramsBeginner friendlyUpdated 9 November 2026

BrowserThe client. Asks for pages and turns them into pixels.

DNSThe contact book. Turns names into IP addresses.

NetworkThe roads. TCP/IP carries data as packets.

ServerThe kitchen. Stores the site and answers requests.

BackendApp code that can build a page on request.

DatabaseThe pantry. Data the backend reads from.

Watch it first

The whole trip, behind the scenes

Press Play to follow one visit to https://www.exampleurl.com from the address bar to the finished page. Each stop is covered in detail further down. You can also step through it or jump to any stage with the numbered buttons.

9 stops, about a second in real life Everything on this diagram usually happens in well under a second. Press Play to slow it down and follow one request from your keyboard to the screen.

Before we start

Two ideas everything else builds on

Before going into the details of every step included in the process, let's review some of the basic concepts we’ll be covering.

World Wide Webthis article

Chat

File sharing

The Interneta huge network of interconnected computers

The internet is the road network; the web is one kind of traffic on it. The World Wide Web (aka web) is built on top of that technology, as well as other services such as email, chat systems or file sharing, and so on.

Computers connected to the internet are either clients or servers. A restaurant is a good way to picture the split:

In a restaurant

The diner reads the menu and places an order.
The kitchen keeps the recipes and ingredients, cooks the dish and sends it out.

On the web

Clients the web user's devices and the software that those devices use to access the web.
Servers computers that store web pages, sites, or apps and the files they need to be displayed in the user's web browser or devices.

1Stop one · the address

Finding a Resource: URLs

Each resource stored in a server can be located by clients using its valid associated URL. You may already know what a URL is, but let’s see in detail each one of its parts. Tap any part of the URL below. The colour shows who uses that part.

Scheme `https:`

The first part of an URL indicates the protocol that should be used to retrieve the resource. Websites use the HTTP and the HTTPS protocol, but we’ll see more details about this later. The : after the scheme is what separates it from the next part of the URL.

✉ Like choosing courier or registered mail.

Authority `//www.exampleurl.com:443`

This part is composed by the domain name and the port number separated by a colon. The port is only mandatory when the standard ports of the HTTP protocol (80 for HTTP and 443 for HTTPS) are not being used by the web server. The // before the domain name indicates the beginning of the authority.

✉ The building’s address, and which door to knock on. Here :443 could be left out, because 443 is the HTTPS default.

Path to resource

This is the abstract or physical path to the resource in the web server.

✉ The room inside the building.

Parameters `?key=value&…`

A set of key/value pairs that add extra options to apply to the returning the requested resource. They are separated by a & and each web server has its own way to handle parameters. This section starts with ?.

✉ Special instructions written on the parcel.

Anchor `#dns`

This section, if present, starts by a # and is handled by the browser to display a specific part of the returned document. For example, it can point to a specific section in a HTML document.

✉ “Start reading at page 3.” The recipient handles it, the courier never sees it.

One URL, five jobs. The scheme picks the protocol, the authority finds the server, the path and parameters tell the server what to send back, and the anchor stays in the browser.

There are a few things that happen when you type a URL into your browser’s address bar that allow you to navigate to a site and interact with its content. Let’s see each one in detail.

2Stop two · the contact book

Matching IPs and URLs: DNS Resolution

While, as humans, we prefer domain names composed of words, computers communicate with each other using IP addresses. IP addresses are composed by numbers and are harder to remember for our human minds. The Domain Name System (DNS) is what puts together domain names and IP addresses.

Your phone’s contact book

Mom

+1 555 0142

You tap a name. The phone network only understands the number.

DNS

www.exampleurl.com

203.0.113.10

You type a name. Routers on the internet only understand the IP address.

Where the browser looks first

When you type a URL, the browser will first look into the local cache to see if the results for the DNS lookup are already stored. Then, it will equally check into the operating system cache. If there are no results stored, then the browser will call the DNS Resolver to try to find the associated IP address for the domain name.

Check 1Browser cacheSites you visited recentlyhit → use the IP

Check 2OS cacheShared by every app on the devicehit → use the IP

Check 3DNS resolver cacheAnswers it fetched for anyonehit → send the IP back

Last resortFull lookupRoot → TLD → authoritative

Like checking your recent calls before phoning directory enquiries. Each level only asks the next one when it has no stored answer.

Scenario

8 messages

Switch scenarios to see why caching matters. Every answer the resolver receives is stored, so the next lookup for the same domain skips some or all of the chain.

What is the DNS Resolver?

The resolver is typically defined by your internet provider’s DNS, even though that’s the default most people use, and it is possible to change it to Google’s or Cloudflare’s or anything else you want.

Your internet provider (default)Google · 8.8.8.8Cloudflare · 1.1.1.1…or anything else you want

Again, the provider’s DNS might have the results for the domain name stored in its cache, if not, it will ask the Root DNS server.

What is the Root DNS Server?

ABCDEFGHIJKLM

The Root DNS server is a system that actually drives the entire internet. It is composed of thirteen servers distributed across the planet. It returns the query from the resolver with the relevant Top Level Domain server for the requested domain name.

At this moment, the DNS resolver will cache the IP of that Top Level Domain server so it doesn’t have to ask the Root DNS server again for it.

Precise versionThirteen servers, or thousands?

The thirteen are named root server identities, a.root-servers.net through m.root-servers.net. Each identity is run as many machines in many countries that share one address (a technique called anycast), so your resolver reaches whichever copy is nearest. In total there are well over a thousand physical root server instances.

What is the Top Level Domain Server?

The Top Level Domain (TLD) server stores the IP addresses of the authoritative name servers for the domain that the user is looking for. In the URL, www.exampleurl.com, the top-level domain is .com.

wwwsubdomain. exampleurldomain name
(authoritative NS). comtop-level domain
(TLD server)

DNS reads a name from right to left. The root knows who runs .com, the .com TLD server knows who is authoritative for exampleurl.com, and that nameserver knows the address of www.exampleurl.com.

Generic TLDs

.com .org .net

Country code TLDs

Usually the two-letter ISO country code: .uk .in .de

…and more

Other types exist beyond these two groups.

The TLD returns the authoritative name servers for the requested domain. One more time, the DNS resolver will cache the results so it doesn’t have to come back later for them.

Authoritative Nameserver

This server contains the DNS records that maps domain names to IP addresses. There is more than one name server attached to any domain.

Name	Type	Value	Meaning
exampleurl.com	NS	ns1.exampleurl.com	nameserver #1
exampleurl.com	NS	ns2.exampleurl.com	nameserver #2 (backup)
www.exampleurl.com	A	203.0.113.10	the IP address we need

There is no caching involved at this point, because the authoritative nameserver is the highest authority and the latest piece in the DNS resolution chain.

✓ IP address available
The authoritative nameserver responds to the DNS resolver query with the domain name’s IP address.

✗ Not available
It will respond with an error.

Then, the DNS resolver stores the IP and sends it back to the client’s browser. Once the DNS lookup is completed and the browser has the IP address, it can attempt to establish a connection with the server.

3Stop three · the road

Establishing a Connection: TCP/IP Model

The connection between client and server is established using the Transmission Control Protocol (TCP) and the Internet Protocol (IP). These protocols are the main ones behind the World Wide Web and other internet technologies, such as email, and determine how data travels across the network.

The TCP/IP model is a framework used to organize the different protocols involved in the internet and other network communications. The primary responsibility of TCP/IP is to divide the data into packets and send them to their final destination, ensuring the packets can be put back together on the other end of the communication.

This process follows a four-layer model, where data travels in one direction and then in the reverse direction when it reaches the destination:

Down on one side, up on the other. The four-layer model includes the application layer, the transport layer, the internet layer, and the network layer. Data travels back and forth through these layers.

Posting a parcel works the same way. Each layer wraps what it was given and adds only the label it is responsible for. At the other end each label is read and removed in reverse order.

Ports: numbered doors on one address

Web server203.0.113.10

:80HTTP

:443HTTPS

:…others

The transport layer that ensures applications can exchange data by establishing data channels. It is also the layer that establishes the concept of network ports, a system of numbered data channels allocated for the specific communication channels that applications need.

The TCP/IP model’s transport layer includes two protocols that are most commonly used on the internet: the TCP and the User Datagram Protocol (UDP). TCP includes some capabilities that make it prevalent over most of the internet-based applications such as the web, so let’s focus on it.

TCP · a tracked, signed-for parcel

Connection first, then delivery. Lost pieces are sent again and everything arrives in order. Used by the web.

UDP · postcards

No connection setup. Each datagram is sent on its own, with no guarantee about delivery or order.

How Does TCP Connection Work?

TCP allows data to be transferred reliably and in order to its destination. It is a connection-oriented protocol, that means that the sender and the receiver must agree on connection parameters before actually establishing the connection. This process is known as the handshake procedure.

TCP Three-way Handshake

The handshake is a way for the client and the server to establish a secure connection and ensure that both parties are synchronized and ready to start exchanging messages. It works like the start of a phone call on a bad line.

3 messages

① Client → Server · SYN“Hello, can you hear me?”The client informs the server that it wants to establish a connection by sending a SYN (synchronize) packet. This packet specifies a sequence number that subsequent segments will start with.

② Server → Client · SYN-ACK“Yes, I hear you. Can you hear me?”The server receives the SYN and responds with a SYN-ACK (synchronize-acknowledgment) segment. It includes the server’s sequence number and an acknowledgment of the client’s sequence number, incremented by one.

③ Client → Server · ACK“Yes, I hear you too.”The client responds with an ACK message, acknowledging the server’s sequence number. At this point, the connection has been established.

Why the +1? Answering ack=101 to seq=100 proves the server really received the client’s number. The client does the same with the server’s 300.

4Stop four · the conversation

Starting the Exchange: Client-Server Communication

Once the TCP connection is established, the client and server can start exchanging messages using the HTTP protocol.

What is the HTTP Protocol?

Hypertext Transfer Protocol (HTTP) is the most widely used application layer protocol in the TCP/IP suite, but it’s considered insecure, leading to a shift towards HTTPS, which uses TLS on top of TCP for data encryption. You’ll find more details about this later.

a request is an order, a response is the plate

The order, step by stepThe diner never walks into the kitchen, and the kitchen never sits at the table. They only exchange tickets and plates. That is exactly how a browser and a server talk over HTTP.

The browser will start by sending an HTTP request message to the server, asking for a copy of the site in the form of an HTML file. HTTP protocol can transfer files like HTML, CSS, JS, SVG, and so on.

.html.css.js.svg.png.json…

HTTP Request/Response

There are two types of HTTP messages. Requests are sent by the client to the server to trigger an action. Responses are sent from the server to the client as an answer to the previous request. Messages are plain text documents, structured in a precise way determined by the communication protocol, in this case, HTTP.

Request browser → server

GET /blog/how-the-web-works.html HTTP/1.1

① Request lineIncludes the request method, which is a verb defining the action to perform. In the case we are covering in this blogpost, the browser will make a GET request to fetch a page from the server. The request line will also include the resource location, in this case an URL, and the protocol version being used.

Host: www.exampleurl.com
Connection: close
Accept: text/html

② Request headerA set of key value pairs. Two of them are mandatory. Host indicates the domain name to target, and Connection which is always set to close unless it must be kept open. The request header always ends with a blank line.

(blank line)

(empty for this GET)

③ Request bodyIs an optional field that allows sending data over the server.

Response server → browser

HTTP/1.1 200 OK

① Status lineIncludes the used protocol version, a status code and a status text, with a human readable description of the status code.

Date: Mon, 09 Nov 2026 10:00:00 GMTgeneral
Server: nginxresponse
Content-Type: text/htmlrepresentation
Content-Length: 1534representation

② HeadersA set of key-value pairs that can either be general headers, applying to the whole message; response headers, giving additional information about the server status; or representation headers, describing the format and encoding for the message data if present.

(blank line)

<!DOCTYPE html>
<html lang="en"> …

③ BodyContains the requested data or resource. If no data or resource is expected by the client, the response usually won’t include a body.

Precise versionWhich headers are really required, and is HTTP always plain text?

In HTTP/1.1 the only header a request must carry is Host. Connections stay open by default so they can be reused for the next request; sending Connection: close asks the other side to close the connection after this response.

HTTP/1.1 messages are plain text, exactly as shown above. HTTP/2 and HTTP/3 carry the same request line, headers and body, but encode them as binary frames.

Status codes: the note that comes with the plate

The server will reply to the request with an HTTP response. Responses include information about the request status and may include the requested resource or data. When the request for a web page is approved by the server, the response will include a 200 OK message. Other existing HTTP response codes are:

2xx · success

200OK“Here’s your dish.”

3xx · go elsewhere / reuse

301Moved Permanently“We moved. Here’s the new address.”

304Not Modified“The copy you already have is still fresh.”

4xx · problem with the request

401Unauthorized“Show me your membership card first.”

403Forbidden“I know who you are. Still no.”

404Not Found“That isn’t on the menu.”

5xx · problem on the server

500Internal Server Error“Something broke in the kitchen.”

The response will also contain a list of HTTP headers and the response body, including the corresponding HTML code for the requested page.

HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is not a different protocol, but an extension of the HTTP. It is usually referred to as HTTP over Transport Layer Security (TLS). Let’s see what it exactly means.

HTTP is the protocol used for most communications between browsers and servers, but it lacks security. Any data sent over HTTP can potentially be visible to anyone on the network. This is especially risky when sensitive data is involved in the connection, such as login credentials, financial information, health information, and so on.

Without TLS · HTTP Browser

Someone on the network reads: password=hunter2password=hunter2

Server

With TLS · HTTPS Browser

They only see: 8f3ac91e7b0d…🔒 8f3ac91e7b0d…

Server

Same wire, same eavesdropper. Over HTTP the form data travels as readable text. Over HTTPS the eavesdropper sees ciphertext they cannot read or change unnoticed.

The main motivation behind HTTPS is to ensure data privacy, integrity, and identification:

Privacy

Data is only accessible to whom it is supposed to be.

Integrity

Data cannot be intercepted or modified by anyone in between.

Identification

Both sender and receiver can be identified as who they claim to be by a legitimate authority.

In HTTPS the communications are encrypted using the TLS protocol, which relies on asymmetric public key infrastructure. It combines two keys: one public and one private. The server shares its public key so the client can use it to encrypt messages that can only be decrypted by the server’s private key.

1 · Serveropen padlocks for anyoneThe public key works like an open padlock. The server hands copies to everyone who asks.

2 · Browsersnaps it shutThe browser locks its message with that padlock. Now not even the browser can reopen it.

3 · Serverthe only keyOnly the server’s private key opens the padlock, and it never leaves the server.

Asymmetric means two different keys. One locks, the other unlocks, so the locking key can be shared publicly.

To establish an encrypted communication, the client and the server have to initiate another handshake. During the handshake, they agree on the TLS version to use and on how they will encrypt data and authenticate each other during the connection, a set of rules known as the cipher suite. This handshake or TLS negotiation starts once a TCP connection has been established. Step through it below or tap any step.

7 steps

1Client hello: The browser sends a hello message that includes all supported TLS versions and cipher suites.
2Server Hello: The server responds with the chosen cipher suite and TLS version, along with its SSL certificate containing the server's public key.
3Authentication and Pre-Master Key: The client verifies the server’s SSL certificate with the corresponding trusted authority, then creates a pre-master key using the server's public key (previously shared in the certificate) and shares this pre-master key with the server.
4Pre-master key decryption: The pre-mastered key can only be decrypted using the server’s private key. If the server is able to decrypt it, the client and server can then agree on a shared master secret to use for the session.
5Client ChangeCipherSpec: The client creates a session key using the shared master secret and sends the server all previously exchanged records, this time encrypted with the session key.
6Server ChangeCipherSpec: If the server generates the correct session key, it will be able to decrypt the message and verify the received record. The server then sends a record to confirm that the client also has the correct keys.
7Secured connection established: The handshake is complete.

Steps in the SSL/TLS handshake, in the classic TLS 1.2 form with RSA key exchange that the steps above describe.

Precise versionWhat changed in TLS 1.3?

Most connections today use TLS 1.3. It no longer sends an RSA-encrypted pre-master key. Instead, both sides exchange Diffie-Hellman key shares in the two hello messages and compute the same secret independently, so the handshake needs one round trip instead of two. The certificate check and the switch to a shared session key work the same way as described above.

During the handshake · asymmetric

Two different keys: the public key locks, the private key unlocks. Used to agree on a secret safely.

After the handshake · symmetric

Both sides hold the same session key and use it to encrypt and decrypt everything that follows.

Once the handshake is completed, all the communication between the client and server is protected by symmetric encryption using the session key, and the browser can make the first HTTP GET request for the site.

Time to First Byte

Once the browser's request is approved, the server will send a 200 OK message along with the response headers and the contents requested. As it is a website, content is likely to be an HTML document.

index.html→ #1#2#3#4#5#6 → #3 arrived damaged, resend only #3 →#3 →reassembled in order

Data travels between the client and server divided into a series of small data chunks, called data packets. This makes it easy to replace corrupted chunks of data if needed and also allows data to travel to and from different locations, enabling multiple users to access data faster and at the same time.

When the first request is made from the client, the first packet that arrives as response marks the Time to First Byte (TTFB), which represents the time elapsed since the request was initiated and when the first chunk of data was received as a response. It will include the time taken for the DNS lookup, the TCP handshake to establish the connection, and the TLS handshake if the request is made over HTTPS.

TTFB ≈ 250 ms

DNS lookupTCP handshakeTLS handshake (HTTPS only)request travels, server prepares the responserest of the response downloads

Switch to HTTP to see the TLS slice disappear. The timings are illustrative, but the order is the real one: every slice before the bracket is part of TTFB.

5Stop five · inside the browser

From Data to Pixels: The Critical Rendering Path

The Critical Rendering Path (CRP) is a series of steps that the browser performs to transform the data received back from the server into pixels on the screen. It includes creating the Document Object Model (DOM) and CSS Object Model (CSSOM), the render tree and layout.

The map for this chapter. Each box links to its section below.

Rendering in slow motion

Inside the browser

3C 21 44 4F 43 54 59 50 45 20 68 74
6D 6C 3E 0A 3C 68 74 6D 6C 20 6C 61
6E 67 3D 22 65 6E 22 3E 0A 3C 68 65 …

decoded as UTF-8 text:

<!DOCTYPE html>
<html lang="en">
<he…

html
├─ head
│  ├─ meta ×2
│  └─ title
└─ body
   ├─ main
   │  ├─ header › h1
   │  └─ section › h2, p ×3, ul › li ×2
   └─ footer › p

The DOM: every tag is now a node.

html
└─ body
   ├─ main
   │  ├─ header › h1
   │  └─ section › p ×3, ul › li ×2
   └─ footer › p
head, meta, title, h2  ← dropped

The render tree: visible nodes with computed styles.

https://www.exampleurl.comloading…

What Really Happens When You Navigate to a Website

Intro

Before entering into the details of every step included in the process, let's review some of the basic concepts.

The Internet is a huge network of interconnected computers.

Computers connected to the internet are either:

Clients, the web user's devices and software.
Servers, computers that store web pages, sites, or apps.

Nothing on screen yetThe browser is still receiving bytes.

Stage 1 of 6 · Bytes arriveThe response arrives as packets of raw bytes. The browser decodes them into characters: 3C 21 44 is <!D.

Building the DOM tree

When the first chunk of data arrives, the browser starts parsing the HTML. Parsing means analyzing and converting a piece of input code into a syntax and representation that can be interpreted by a specific runtime. In this case, the browser assembles the data packets received and parses the HTML, building a representation of the document as a node tree known as the DOM tree.

Each HTML tag in the document is represented as a node in the DOM tree. Nodes are connected to the DOM tree according to their hierarchical position in the document, and each node's representation includes all relevant information about the tag. For the following HTML code, the resulting DOM tree is on the right. Tap an element to fold its branch.

index.htmlHTML

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>What Really Happens When You Navigate to a Website</title>
</head>
<body>
    <main>
        <header>
            <h1>What Really Happens When You Navigate to a Website</h1>
        </header>

        <section>
            <h2>Intro</h2>
            <p>
                Before entering into the details of every step included in the process, let's review some of the basic concepts we will be discussing throughout the blog.
            </p>
            <p>
                The Internet is a huge network of interconnected computers. The World Wide Web (aka web) is built on top of that technology, as well as other services such as email, chat systems, or file sharing.
            </p>

            <p>Computers connected to the internet are either:</p>
            <ul>
                <li>
                    <p>Clients, the web user's devices and the software that those devices use to access the web.</p>
                </li>
                <li>
                    <p>Servers, computers that store web pages, sites, or apps and the files they need to be displayed in the user's web browser or devices.</p>
                </li>
            </ul>
        </section>
    </main>

    <footer>
        <p>© 2024</p>
    </footer>
</body>
</html>

- - meta charset
  - meta viewport
  - - “What Really Happens…”
- - - - “What Really Happens…”
    - - “Intro”
      - “Before entering into…”
      - “The Internet is a huge…”
      - “Computers connected…”
      - “Clients, the web user's…”
        
        “Servers, computers that…”
  - - - “© 2024”

The DOM tree includes all HTML elements, its content and its hierarchy relationships. Grey italic leaves are text nodes.

While parsing the HTML, the browser makes additional requests for encountered resources. CSS files and images are non-blocking resources, meaning the parser will continue its task while awaiting the requested resources. But if a <script> tag is found, the HTML parsing will pause impacting the time to first rendering.

<p>, <ul>…Becomes a DOM node.keeps parsing

<link rel="stylesheet">CSS is requested in the background.keeps parsing

<img>Image is requested in the background.keeps parsing

<script>Script must be fetched and run first.⏸ parsing pauses

Building the CSSOM Tree

While the DOM contains all the information about the content of the page and its hierarchy, the CSSOM contains the information on how to style the page. In the CSSOM, each HTML element is matched with its corresponding CSS styles. The result is a tree that doesn’t contain information about the content of the elements, but about how they should be displayed.

styles.cssCSS

* {
    box-sizing: border-box;
}

body {
    font-family: Arial, sans-serif;
    background-color: #f4f4f9;
    color: #333;
}

main {
    padding: 20px;
    max-width: 800px;
    margin: 0 auto;
}

header {
    background-color: #005bbb;
    color: #ffffff;
    padding: 10px;
    text-align: center;
}

h1 {
    font-size: 24px;
}

section {
    margin-top: 20px;
}

h2 {
    font-size: 20px;
    color: #005bbb;
    display: none;
}

p {
    margin-bottom: 10px;
}

ul {
    margin-left: 20px;
    list-style-type: disc;
}

footer {
    margin-top: 40px;
    text-align: center;
    font-size: 14px;
    color: #555;
}

* (every element)box-sizing: border-box
- bodyfont-family: Arialbackground #f4f4f9color #333
  - mainpadding: 20pxmax-width: 800pxmargin: 0 auto
    - headerbackground #005bbbcolor #fffpadding: 10pxtext-align: center
      - h1font-size: 24px
    - sectionmargin-top: 20px
      - h2font-size: 20pxcolor #005bbbdisplay: none
      - pmargin-bottom: 10px
      - ulmargin-left: 20pxlist-style-type: disc
        li
        pmargin-bottom: 10px
  - footermargin-top: 40pxtext-align: centerfont-size: 14pxcolor #555

The CSSOM tree includes each HTML element and their corresponding styles. Note the red display: none on h2: it decides that heading’s fate in the render tree.

Its creation is not incremental, meaning that the browser stops rendering the page until it processes all the CSS. This works this way because, as its name suggests, Cascading Style Sheets (CSS) apply styles from top to bottom, meaning that classes defined later override those at the beginning of the document. A CSS document needs to be fully processed before rendering anything on the screen, as there are classes that may change.

If the browser painted after line 3p { color: #333; }Computers connected to the internet…✗ grey: wrong, and about to change

After the whole file is readp { color: #005bbb; } /* later rule wins */Computers connected to the internet…✓ blue: the final style

Why CSS blocks rendering. A later rule can override an earlier one, so painting with half the stylesheet would show the wrong style and then flicker. The browser waits for the full CSSOM. (Illustrative rules, not part of the stylesheet above.)

Javascript Compilation and Execution

While the CSSOM is being created, rendering is blocked, but the browser continues downloading any JavaScript files it encounters.

JavaScript is also parsed, compiled, and interpreted by the browser, but as mentioned before, it is a parser-blocking resource by default. This means that when the browser encounters a <script> tag, it stops HTML parsing and executes the file before continuing. The async or defer attributes can be used to avoid this behavior, allowing parsing to continue while the resource is fetched. Compare the three below.

Default · parser-blockingParsing stops at the <script> tag. The file is downloaded and executed, and only then does parsing continue, so the page finishes parsing last.

Once the browser completes parsing and executes all JavaScript files that may modify the DOM and CSSOM, the next step is to build the render tree. However, before seeing this step in detail, let’s take a moment to focus on the accessibility tree.

Render tree

After building the DOM, CSSOM, and accessibility trees, the browser builds the render tree. This tree is a combination of the DOM and CSSOM trees. The browser processes all nodes and keeps only the visible ones. Then, it combines them with their corresponding CSSOM rules. The result is a collection of all visible elements matched with their computed styles.

Non-visible nodes, such as <script> or <meta> tags, as well as elements hidden with the display: none CSS property, are not included in this tree.

DOM+CSSOM= 21 DOM elements

html
headnever displayed
metanon-visible
metanon-visible
titlenon-visible
bodyArialbg #f4f4f9color #333
mainpadding 20pxmax-width 800px
headerbg #005bbbcolor #fffcenter
h124pxcolor #fff (inherited)
sectionmargin-top 20px
h2display: none
pmargin-bottom 10px
pmargin-bottom 10px
pmargin-bottom 10px
ulmargin-left 20pxdisc
li
pmargin-bottom 10px
li
pmargin-bottom 10px
footer14pxcentercolor #555
pmargin-bottom 10px

The render tree is created from the DOM and CSSOM trees. Press the button to drop the five nodes that never reach the screen and attach computed styles to the rest.

Layout

Once the render tree is computed, the browser runs the layout. In this process, the browser calculates the exact position and size each element will take into the page.

These calculations are based on the viewport size, the browser area that will actually display the site content. The size of the viewport varies based on the device screen size, the browser window size, system settings along other conditions. Drag the slider to resize the viewport and watch the browser recompute the boxes for our example page.

Viewport width 1024 px

viewport1024 px

main box (dashed)800 px

content inside padding760 px

reflows so far0

Box model of main at this width · DevTools colours

margin00104104

border0000

padding20202020

760 × auto

The same CSS gives different boxes. main has max-width: 800px and margin: 0 auto, so on wide viewports it stops at 800 px and centres; below about 816 px it fills the width minus the body’s default 8 px margins.

The layout output is a box model that captures the size and position that correspond to each element and object present in the render tree. The browser starts processing the document usually from the <body> tag and going through all its descendants.

After the layout calculation, any changes in the size or position of one or more elements in the document will trigger new calculations. Those following calculations are called reflows.

Painting

Now, the final step is displaying the layout output on the user's screen. During the painting or rasterization phase, the browser converts each layout box element into corresponding pixels on the screen.

1 · Layout boxes Only geometry: where and how big.

2 · Rasterize into pixels Each box becomes coloured pixels. Zoomed in, edges are rows of squares.

3 · Later: repaint only what changed The rest of the screen keeps its pixels.

A visual representation of the entire page is initially rendered on the screen, and then only the areas affected by changes are re-rendered.

Many factors impact the time it takes for the browser to perform this step, and there are tools that help developers measure and optimize this time.

After painting, and before users can start interacting with the website, the browser may execute any JavaScript that has been deferred using the defer or async attributes to avoid blocking the initial HTML parsing.

A Note About JavaScript Hydration

The steps we described above show the process of rendering all the website’s HTML, CSS, and JavaScript code in the browser. This is known as Client-Side Rendering (CSR). You may have also heard about Server-Side Rendering (SSR).

SSR consists of rendering a website’s content on each request and delivering it to the client as HTML ready to be displayed in the browser.

When a site is rendered using CSR, all the JavaScript is executed before the page is rendered. In SSR, the server-rendered HTML loads and displays quickly in the browser, but JavaScript still needs to be sent to the client to enable user interaction.

CSR

t₁ · HTML arrives

empty shell

Nothing to see yet.

t₂ · JS downloads, runs

still blank…

JavaScript builds the page.

t₃ · done

Like ✓

Visible and interactive at the same time.

SSR

t₁ · HTML arrives

Visible right away, built on the server.

t₂ · JS downloads

Looks ready, but clicks do nothing yet.

t₃ · hydrated

Like ✓

Interactive once JS attaches its listeners.

Same page, two timelines. CSR shows nothing until its JavaScript has run. SSR shows the content first and becomes interactive after hydration.

JavaScript Hydration is the process where JavaScript is added to a server-rendered HTML page to make it interactive. Once the initial HTML is served and displayed in the browser, JavaScript “hydrates” the static content, attaching event listeners and enabling interactive functionality. Think of a furnished show home: everything is in place, but the switches only work once the electricity is connected. Try it:

What Really Happens When You Navigate to a Website

Computers connected to the internet are either clients or servers.

Server-rendered HTML · not hydrated

// click “Like” before and after hydrating

The HTML never changes. Hydration only adds the click handler, which is why the button looks identical before and after.

Quick answers

Frequently asked questions

What happens when you type a URL into the browser?

The browser finds the IP address for the domain with a DNS lookup, checking its own cache and the operating system cache first. It then opens a TCP connection with a three-way handshake, adds a TLS handshake for HTTPS, and sends an HTTP GET request. The server answers with a response, usually an HTML document split into packets, and the browser turns the HTML, CSS and JavaScript into pixels through the critical rendering path.

What is DNS resolution?

DNS resolution matches a domain name to its IP address. The browser checks its cache, then the operating system cache, then asks a DNS resolver. If the resolver has no cached answer, it asks a root server, which points to the top-level domain (TLD) server, which points to the authoritative nameserver, which returns the IP address.

What is the TCP three-way handshake?

It is how a client and a server agree to start a TCP connection. The client sends SYN with a sequence number, the server replies SYN-ACK with its own sequence number and the client’s number plus one, and the client confirms with ACK. After these three messages the connection is established.

What is the difference between HTTP and HTTPS?

HTTPS is HTTP over Transport Layer Security (TLS). With plain HTTP, anyone on the network can potentially read the data. HTTPS encrypts it after a TLS handshake, which protects privacy and integrity and lets the browser verify the server’s identity through its certificate.

What is Time to First Byte (TTFB)?

TTFB is the time between the browser starting a request and receiving the first packet of the response. It includes the DNS lookup, the TCP handshake, the TLS handshake for HTTPS, and the time the server takes to start responding.

What is the critical rendering path?

It is the series of steps a browser performs to turn the HTML, CSS and JavaScript it receives into pixels: building the DOM tree and the CSSOM tree, combining them into the render tree, calculating the layout, and painting.

What is JavaScript hydration?

Hydration is the process where JavaScript is added to a server-rendered HTML page to make it interactive. The HTML is displayed first, then JavaScript attaches event listeners so buttons and other controls start working.

Wrapping up

Conclusion

URL→ DNS→ TCP→ TLS→ HTTP→ TTFB→ DOM + CSSOM→ Layout + Paint

Throughout this article, you enhanced your understanding of what happens from the moment you type a web address into your browser’s address bar until you access the content of the site you’re looking for.

You learned about URLs and the DNS lookup performed by the browser to find the site’s IP address. You also learned how connections are established between the browser and servers and how they communicate.

Finally, you explored what happens from the time the first chunk of data is received from the server until the site is displayed on your screen, along with key concepts such as the accessibility tree and the JavaScript hydration process.

I hope you enjoyed this guide and found it useful. Thanks for reading!

↑ Replay the whole journey

Example addresses use the reserved documentation range (203.0.113.0/24) and a placeholder domain. Timings in the TTFB diagram are illustrative.

Latest Blog Posts

What Happens When You Type a URL in Your Browser? Understanding How the Web Works

The whole trip, behind the scenes

Two ideas everything else builds on

Finding a Resource: URLs

Scheme https:

Authority //www.exampleurl.com:443

Path to resource

Parameters ?key=value&…

Anchor #dns

Matching IPs and URLs: DNS Resolution

Where the browser looks first

What is the DNS Resolver?

What is the Root DNS Server?

What is the Top Level Domain Server?

Generic TLDs

Country code TLDs

…and more

Authoritative Nameserver

Establishing a Connection: TCP/IP Model

Ports: numbered doors on one address

TCP · a tracked, signed-for parcel

UDP · postcards

How Does TCP Connection Work?

TCP Three-way Handshake

Starting the Exchange: Client-Server Communication

What is the HTTP Protocol?

HTTP Request/Response

Status codes: the note that comes with the plate

HTTPS

Privacy

Integrity

Identification

During the handshake · asymmetric

After the handshake · symmetric

Time to First Byte

From Data to Pixels: The Critical Rendering Path

Building the DOM tree

Building the CSSOM Tree

Javascript Compilation and Execution

Building the Accessibility Tree

Name

Description

Role

State and other properties

Render tree

Layout

Painting

A Note About JavaScript Hydration

What Really Happens When You Navigate to a Website

Frequently asked questions

Conclusion

Popular Posts

Contact Us

Labels

Get new posts by email:

Scheme `https:`

Authority `//www.exampleurl.com:443`

Parameters `?key=value&…`

Anchor `#dns`