DEV Community

Sh Raj
Sh Raj

Posted on

What REALLY Happens When You Type a URL?

#webdev #programming #ai #networking

🌐 What REALLY Happens When You Type a URL?

You type: https://example.com
You press: Enter
And somehow: a complete webpage appears in milliseconds.

But what actually happened between those two events?

This article follows the journey of a URL from your keyboard → browser → DNS → network → server → browser → pixels on your screen.

🧠 The Big Picture

At a very high level:

You type a URL
      ↓
Browser parses the URL
      ↓
Check browser cache
      ↓
DNS: "What IP belongs to this domain?"
      ↓
Get IP address
      ↓
Establish connection
      ↓
TLS handshake (HTTPS)
      ↓
HTTP request
      ↓
Server processes request
      ↓
HTTP response
      ↓
Browser receives HTML
      ↓
Download CSS / JavaScript / Images
      ↓
Build DOM + CSSOM
      ↓
Layout + Paint + Composite
      ↓
🎨 Webpage appears
Enter fullscreen mode Exit fullscreen mode

And this can happen incredibly quickly.

1. 🔗 First: What Exactly Is a URL?

A URL (Uniform Resource Locator) tells your browser where a resource is and how to access it.

Consider:

https://www.example.com:443/products?id=42#reviews
Enter fullscreen mode Exit fullscreen mode

Let's break it apart.

Component Value Purpose
Scheme https Protocol
Host www.example.com Website/domain
Port 443 Network port
Path /products Resource location
Query ?id=42 Additional parameters
Fragment #reviews Position inside page

🧩 URL Anatomy 

              https://www.example.com:443/products?id=42#reviews
              └─┬─┘   └────┬──────┘ └┬┘ └────┬────┘ └──┬───┘
             scheme       host       port   query    fragment
Enter fullscreen mode Exit fullscreen mode

💡 Important

The browser does not immediately connect to:

www.example.com
Enter fullscreen mode Exit fullscreen mode

Computers communicate using IP addresses.

So eventually we need something like:

www.example.com
       ↓
93.184.216.34
Enter fullscreen mode Exit fullscreen mode

And that's where DNS enters the story.

2. 🧭 The Browser First Parses the URL

When you press Enter, the browser first determines what you've entered.

For example:

https://example.com/products
Enter fullscreen mode Exit fullscreen mode

The browser understands:

Protocol → HTTPS
Host     → example.com
Path     → /products
Port     → 443
Enter fullscreen mode Exit fullscreen mode

The browser now knows:

“I need to retrieve /products from example.com using HTTPS.”

But it still doesn't know where example.com actually lives.

3. ⚡ Before DNS: Check the Cache

Your browser may already know the answer.

Modern browsers and operating systems maintain several caches.

A simplified hierarchy looks like:

Browser DNS Cache
       ↓
Operating System Cache
       ↓
Hosts File
       ↓
Configured DNS Resolver
       ↓
Root DNS
       ↓
TLD DNS
       ↓
Authoritative DNS
Enter fullscreen mode Exit fullscreen mode

If the IP is already cached and hasn't expired:

example.com
     ↓
Cached IP
     ↓
Skip DNS lookup
Enter fullscreen mode Exit fullscreen mode

This is one reason why repeatedly visiting a website can feel faster.

4. 📖 DNS — The Internet's Phone Book

What is DNS?

DNS = Domain Name System

Humans prefer:

google.com
Enter fullscreen mode Exit fullscreen mode

Computers ultimately need:

142.250.x.x
Enter fullscreen mode Exit fullscreen mode

DNS translates the domain name into an IP address.

          DNS
           │
           ▼
"Where is example.com?"
           │
           ▼
    93.184.216.34
Enter fullscreen mode Exit fullscreen mode

5. 🌳 How DNS Actually Finds the IP

Here's where things get interesting.

Suppose your DNS resolver doesn't already know the answer.

It can walk through the DNS hierarchy.

flowchart TD
    A["Browser"] --> B["DNS Resolver"]
    B --> C["Root DNS Server"]
    C --> D[".com TLD Server"]
    D --> E["Authoritative DNS Server"]
    E --> F["IP Address"]
    F --> B
    B --> A

Step 1 — Ask the Resolver

Your computer asks its configured DNS resolver:

What is the IP address of example.com?
Enter fullscreen mode Exit fullscreen mode

The resolver might be operated by:

  • your ISP
  • your organization
  • a public DNS service
  • another DNS provider

Step 2 — Root DNS

If the resolver doesn't know, it can ask a root DNS server.

The root doesn't usually know the final IP.

Instead, it says approximately:

“I don't know example.com, but I know who handles .com.”

Root
 ↓
.com TLD
Enter fullscreen mode Exit fullscreen mode

Step 3 — TLD Server

The resolver asks the .com TLD server:

Who is authoritative for example.com?
Enter fullscreen mode Exit fullscreen mode

The TLD server points toward the domain's authoritative DNS servers.

.com
 ↓
Authoritative DNS
Enter fullscreen mode Exit fullscreen mode

Step 4 — Authoritative DNS

Finally:

Authoritative DNS
       ↓
example.com
       ↓
93.184.216.34
Enter fullscreen mode Exit fullscreen mode

The resolver returns the answer to your computer.

6. 🧠 DNS Records

DNS isn't just about IP addresses.

A domain can have different record types.

Record Purpose
A IPv4 address
AAAA IPv6 address
CNAME Alias to another hostname
MX Mail server
TXT Text / verification / policy data
NS Authoritative nameserver
CAA Certificate authority authorization

For example:

example.com
     │
     ├── A     → IPv4
     ├── AAAA  → IPv6
     ├── MX    → Mail server
     └── TXT   → Verification / policy
Enter fullscreen mode Exit fullscreen mode

7. 🕒 TTL — Why DNS Doesn't Happen Every Time

DNS records have a TTL (Time To Live).

Example:

example.com
A → 93.184.216.34
TTL → 300 seconds
Enter fullscreen mode Exit fullscreen mode

A resolver can cache the answer for that period.

So the next request may become:

Browser
  ↓
Cached DNS result
  ↓
IP
Enter fullscreen mode Exit fullscreen mode

instead of:

Browser
 ↓
Resolver
 ↓
Root
 ↓
TLD
 ↓
Authoritative DNS
 ↓
IP
Enter fullscreen mode Exit fullscreen mode

8. 📍 We Now Have an IP Address

Great!

Suppose DNS returned:

93.184.216.34
Enter fullscreen mode Exit fullscreen mode

Now the browser knows:

“That's the machine I need to communicate with.”

But there's another question:

How do we establish the connection?

For HTTPS, traditionally this involves TCP + TLS.

For HTTP/3, it can instead use QUIC over UDP.

Let's first understand the classic TCP path.

9. 🤝 TCP — Establishing a Connection

TCP provides a reliable connection between two endpoints.

Before sending application data, TCP traditionally performs the famous:

Three-Way Handshake 

Client                         Server
  │                               │
  │ -------- SYN ---------------> │
  │                               │
  │ <------- SYN + ACK ---------- │
  │                               │
  │ -------- ACK ---------------> │
  │                               │
  │        Connection ready       │
Enter fullscreen mode Exit fullscreen mode

What do these mean?

SYN

“I want to start a TCP connection.”

SYN-ACK

“I received your request and I'm willing to connect.”

ACK

“Got it.”

Now the TCP connection is established.

10. 🔐 HTTPS Changes the Story

If the URL is:

https://example.com
Enter fullscreen mode Exit fullscreen mode

we need encryption.

That's what TLS provides.

Without HTTPS:

Browser ────────────────> Server
          HTTP
Enter fullscreen mode Exit fullscreen mode

With HTTPS:

Browser ════════════════> Server
          Encrypted
Enter fullscreen mode Exit fullscreen mode

11. 🔐 TLS Handshake

TLS allows the browser and server to establish cryptographic parameters and authenticate the server.

A simplified TLS 1.3 flow:

sequenceDiagram
    participant B as Browser
    participant S as Server

    B->>S: ClientHello
    S->>B: ServerHello
    S->>B: Certificate
    S->>B: Handshake messages
    B->>S: Finished
    S->>B: Finished
    Note over B,S: Encrypted application data

The exact wire exchange is more detailed, but conceptually:

Browser
   │
   │ "Here are the cryptographic options I support."
   ▼
Server
   │
   │ "Let's use these."
   │
   │ "Here's my certificate."
   ▼
Browser
   │
   │ Verify certificate
   ▼
Secure session established
Enter fullscreen mode Exit fullscreen mode

12. 🪪 What's the Certificate For?

When you visit:

https://example.com
Enter fullscreen mode Exit fullscreen mode

your browser wants to know:

“Am I really talking to example.com?”

The server presents a digital certificate.

The certificate contains information such as the domain names it covers and cryptographic identity information.

It is signed through a chain involving trusted Certificate Authorities (CAs).

Simplified:

Certificate
     │
     ▼
Trusted CA
     │
     ▼
Browser's trust store
     │
     ▼
"Can I trust this identity?"
Enter fullscreen mode Exit fullscreen mode

If certificate validation fails, the browser may show a security warning.

13. 🔒 Is the Data Now Encrypted?

After the TLS handshake:

Browser
   ║
   ║ 🔐 Encrypted
   ║
   ▼
Server
Enter fullscreen mode Exit fullscreen mode

Someone observing the network generally cannot simply read the HTTPS request contents.

However, HTTPS does not make you invisible.

Depending on the circumstances, information such as destination IP addresses and some connection metadata can still be observable.

14. 📦 Now Comes HTTP

Finally, we can send the actual web request.

For example:

GET /products HTTP/1.1
Host: example.com
Accept: text/html
Accept-Language: en-US
Enter fullscreen mode Exit fullscreen mode

Conceptually:

GET
 ↓
/products
 ↓
example.com
 ↓
"Please give me this resource."
Enter fullscreen mode Exit fullscreen mode

With HTTP/2 or HTTP/3, the wire representation is different from this textual HTTP/1.1 example, but the application-level idea remains similar.

15. 📬 What Is an HTTP Request?

An HTTP request contains several important pieces.

┌─────────────────────────────┐
│ Method                      │
│ URL / Path                  │
│ Headers                     │
│ Body (optional)             │
└─────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Common HTTP methods:

Method Typical purpose
GET Retrieve data
POST Submit/create data
PUT Replace data
PATCH Partially update data
DELETE Delete data

When loading a webpage, the initial navigation is commonly a GET.

16. 📨 HTTP Request Example 

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: en-US
Enter fullscreen mode Exit fullscreen mode

Think of it as:

“Server, give me the homepage.”

17. 🏢 But Where Did Our Request Actually Go?

This is an important part people often skip.

The IP address may not represent the actual application server.

Modern websites can sit behind infrastructure such as:

                Internet
                   │
                   ▼
              CDN / Edge
                   │
            Load Balancer
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
       Server A Server B Server C
          │        │        │
          └────────┼────────┘
                   ▼
                Database
Enter fullscreen mode Exit fullscreen mode

Your request may pass through several layers.

18. 🌍 CDN — The Website May Be Closer Than You Think

A CDN (Content Delivery Network) places cached content at locations around the world.

Instead of:

India
  │
  └──────────────> US Server
Enter fullscreen mode Exit fullscreen mode

you might get:

India
  │
  ▼
Nearby CDN Edge
  │
  ▼
Cached Content
Enter fullscreen mode Exit fullscreen mode

This reduces latency for cacheable resources.

19. ⚖️ Load Balancer

Suppose millions of users visit a website.

One server may not be enough.

A load balancer can distribute requests:

flowchart LR
    U["Users"] --> L["Load Balancer"]
    L --> A["Server A"]
    L --> B["Server B"]
    L --> C["Server C"]
    A --> D["Database"]
    B --> D
    C --> D

The browser doesn't necessarily know which backend server handled the request.

20. 🧠 The Server Starts Working

The server receives:

GET /
Enter fullscreen mode Exit fullscreen mode

Now application code may execute.

For example:

Request
   ↓
Web server
   ↓
Application
   ↓
Authentication
   ↓
Business logic
   ↓
Database
   ↓
Response
Enter fullscreen mode Exit fullscreen mode

Imagine an e-commerce website.

Your request:

GET /products/42
Enter fullscreen mode Exit fullscreen mode

could cause the application to:

1. Authenticate session
2. Validate product ID
3. Query database
4. Fetch product information
5. Render HTML
6. Return response
Enter fullscreen mode Exit fullscreen mode

21. 🗄️ Database

The server may need information from a database.

For example:

SELECT *
FROM products
WHERE id = 42;
Enter fullscreen mode Exit fullscreen mode

The database returns something like:

Product
──────────────
id: 42
name: Laptop
price: ₹79,999
stock: 12
Enter fullscreen mode Exit fullscreen mode

The application uses this information to generate the response.

22. 📨 The Server Sends an HTTP Response

The server might respond:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: ...
Enter fullscreen mode Exit fullscreen mode

followed by the HTML document.

Conceptually:

Browser
   │
   │ GET /
   ▼
Server
   │
   │ 200 OK + HTML
   ▼
Browser
Enter fullscreen mode Exit fullscreen mode

23. 🚦 HTTP Status Codes

The response has a status code.

Code Meaning
200 OK
201 Created
301 Permanent redirect
302 Temporary redirect
304 Not modified
400 Bad request
401 Authentication required
403 Forbidden
404 Not found
500 Server error
502 Bad gateway
503 Service unavailable

So when you see:

404
Enter fullscreen mode Exit fullscreen mode

the browser did communicate with a server.

The server is essentially saying:

“I don't have the resource you requested.”

24. 📄 The Browser Receives HTML

Now the browser finally has something to work with.

Example:

<!DOCTYPE html>
<html>
<head>
    <title>Hello</title>
</head>

<body>
    <h1>Hello World</h1>
    <p>Welcome!</p>
</body>
</html>
Enter fullscreen mode Exit fullscreen mode

But the page isn't finished yet.

The HTML may reference:

style.css
app.js
logo.png
font.woff2
Enter fullscreen mode Exit fullscreen mode

So the browser starts requesting those resources too.

25. 🕸️ One Page Can Trigger Many Requests

This is something you can demonstrate beautifully in your video.

You type:

example.com
Enter fullscreen mode Exit fullscreen mode

But the browser may request:

GET /
GET /style.css
GET /app.js
GET /logo.svg
GET /font.woff2
GET /api/user
GET /products
...
Enter fullscreen mode Exit fullscreen mode

One URL can therefore trigger dozens or hundreds of network requests on a modern site.

26. 🔄 The Browser Builds the DOM

The browser parses HTML and constructs the:

DOM — Document Object Model

HTML:

<body>
    <h1>Hello</h1>
    <p>World</p>
</body>
Enter fullscreen mode Exit fullscreen mode

Becomes conceptually:

flowchart TD
    A["Document"] --> B["html"]
    B --> C["body"]
    C --> D["h1"]
    C --> E["p"]
    D --> F["Hello"]
    E --> G["World"]

The DOM represents the document as a tree.

27. 🎨 CSSOM

CSS is parsed separately.

Example:

h1 {
    color: blue;
    font-size: 40px;
}
Enter fullscreen mode Exit fullscreen mode

The browser builds a structure called the:

CSSOM — CSS Object Model

Conceptually:

HTML
 ↓
DOM

CSS
 ↓
CSSOM
Enter fullscreen mode Exit fullscreen mode

Then the browser combines the information to determine what should be rendered.

28. 🧱 Render Tree

The browser uses the DOM and CSS information to determine what is rendered.

A simplified pipeline:

HTML
 ↓
DOM
 ↓
      ┌──────────────┐
CSS → │ CSSOM        │
      └──────┬───────┘
             ↓
       Render Tree
             ↓
          Layout
             ↓
           Paint
             ↓
        Composite
             ↓
          🖥️ Screen
Enter fullscreen mode Exit fullscreen mode

29. 📐 Layout

The browser calculates where everything should appear.

For example:

Viewport
┌──────────────────────────────┐
│ Header                       │
├──────────────────────────────┤
│                              │
│       Hello World             │
│                              │
│       [ Button ]              │
│                              │
└──────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

It calculates:

  • width
  • height
  • position
  • margins
  • padding
  • font metrics
  • line wrapping

This stage is commonly called layout.

30. 🎨 Paint

Now the browser needs to draw things.

It determines:

Text
Backgrounds
Borders
Shadows
Images
Gradients
Enter fullscreen mode Exit fullscreen mode

and produces drawing operations for the rendering system.

31. 🧩 Composite

Modern browsers can use multiple rendering layers.

Those layers can then be composited together to produce the final frame.

Simplified:

Layer 1 → Header
Layer 2 → Content
Layer 3 → Image
Layer 4 → Animation
          ↓
       Composite
          ↓
       🖥️ Frame
Enter fullscreen mode Exit fullscreen mode

And finally...

🎉 You See The Website 

Keyboard
   ↓
URL
   ↓
Browser
   ↓
DNS
   ↓
IP
   ↓
TCP / QUIC
   ↓
TLS
   ↓
HTTP
   ↓
Server
   ↓
Database / APIs
   ↓
HTML / CSS / JS
   ↓
DOM / CSSOM
   ↓
Layout
   ↓
Paint
   ↓
Composite
   ↓
👀 Website
Enter fullscreen mode Exit fullscreen mode

32. 🚀 But What About JavaScript?

We're not done.

Modern websites aren't just HTML.

JavaScript can execute after the page starts loading.

For example:

fetch("/api/user")
Enter fullscreen mode Exit fullscreen mode

might trigger:

Browser
   ↓
HTTP request
   ↓
API server
   ↓
Database
   ↓
JSON response
   ↓
JavaScript
   ↓
Update DOM
   ↓
Browser renders again
Enter fullscreen mode Exit fullscreen mode

This is why modern web applications can feel more like applications than documents.

33. 🍪 What About Cookies?

Cookies can also be involved.

A server may send:

Set-Cookie: session=abc123
Enter fullscreen mode Exit fullscreen mode

The browser stores the cookie according to its rules.

Later requests may include it:

Cookie: session=abc123
Enter fullscreen mode Exit fullscreen mode

This helps websites maintain things such as:

  • sessions
  • preferences
  • authentication state
  • certain tracking mechanisms

34. 🔑 What About Login?

Suppose you're already logged into a website.

The browser might send authentication information through a cookie or another mechanism.

Simplified:

Login
  ↓
Server authenticates user
  ↓
Session established
  ↓
Browser stores credential/session state
  ↓
Future requests identify the session
Enter fullscreen mode Exit fullscreen mode

So when you visit:

/dashboard
Enter fullscreen mode Exit fullscreen mode

the server can determine which account the request belongs to.

35. 📱 What If You're Using Your Phone?

The overall architecture remains similar.

But the network path may be different.

For example:

Phone
  ↓
Wi-Fi
  ↓
Router
  ↓
ISP
  ↓
Internet
  ↓
Server
Enter fullscreen mode Exit fullscreen mode

Or:

Phone
  ↓
Cellular Network
  ↓
Carrier Network
  ↓
Internet
  ↓
Server
Enter fullscreen mode Exit fullscreen mode

36. 🌐 What Happens to the Packet?

At the network level, your data is broken into packets and transported across networks.

A simplified view:

Your Computer
      ↓
Router
      ↓
ISP
      ↓
Internet Routers
      ↓
Destination Network
      ↓
Server
Enter fullscreen mode Exit fullscreen mode

The actual route can vary.

You can inspect routing information with:

traceroute example.com
Enter fullscreen mode Exit fullscreen mode

On Windows:

tracert example.com
Enter fullscreen mode Exit fullscreen mode

37. 🧪 Try It Yourself

Open DevTools.

Chrome / Edge 

Right Click
    ↓
Inspect
    ↓
Network
Enter fullscreen mode Exit fullscreen mode

Then visit a website.

You'll see requests such as:

Document
CSS
JS
Images
Fonts
XHR / Fetch
Enter fullscreen mode Exit fullscreen mode

38. 🔍 Inspect a Request

Click a request in the Network tab.

You'll usually find information such as:

Headers 

Request URL
Request Method
Status Code
Remote Address
Content-Type
Enter fullscreen mode Exit fullscreen mode

Response

The data returned by the server.

Timing

You can often see timing phases related to:

Queueing
DNS
Connection
TLS
Request
Waiting
Download
Enter fullscreen mode Exit fullscreen mode

This is one of the best ways to show the concepts in the video instead of only talking about them.

39. 🛠️ Useful Commands

DNS lookup 

nslookup example.com
Enter fullscreen mode Exit fullscreen mode

or:

dig example.com
Enter fullscreen mode Exit fullscreen mode

Trace network path 

traceroute example.com
Enter fullscreen mode Exit fullscreen mode

Test HTTP headers 

curl -I https://example.com
Enter fullscreen mode Exit fullscreen mode

Make an HTTP request 

curl https://example.com
Enter fullscreen mode Exit fullscreen mode

Verbose HTTPS connection 

curl -v https://example.com
Enter fullscreen mode Exit fullscreen mode

The verbose output can expose useful connection details such as DNS resolution, connection establishment, TLS negotiation, and HTTP exchange.

40. ⚡ Where Does Latency Come From?

The browser isn't necessarily spending all its time downloading data.

A simplified timeline:

DNS
 │
 ├── DNS lookup
 │
 ▼
Connection
 │
 ├── TCP / QUIC
 │
 ▼
TLS
 │
 ├── Secure handshake
 │
 ▼
Request
 │
 ├── HTTP request
 │
 ▼
TTFB
 │
 ├── Server processing
 │
 ▼
Download
 │
 ├── HTML / CSS / JS
 │
 ▼
Rendering
 │
 ├── Parse
 ├── Layout
 ├── Paint
 └── Composite
Enter fullscreen mode Exit fullscreen mode

41. 🏎️ Why Websites Use Caching

Without caching:

Every request
      ↓
Server
      ↓
Generate response
Enter fullscreen mode Exit fullscreen mode

With caching:

Request
   ↓
Cache
   ↓
Found?
 ┌─┴─┐
Yes  No
 ↓    ↓
Return Server
Enter fullscreen mode Exit fullscreen mode

Caching can happen at multiple layers:

Browser Cache
      ↓
CDN Cache
      ↓
Reverse Proxy Cache
      ↓
Application Cache
      ↓
Database
Enter fullscreen mode Exit fullscreen mode

42. 🌍 HTTP/2 and HTTP/3

The web has evolved.

HTTP/1.1

Traditionally represents requests as individual HTTP messages over a TCP connection.

HTTP/2

Introduces features such as:

  • multiplexed streams
  • binary framing
  • header compression

Multiple HTTP streams can share a connection.

             TCP Connection
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
    HTML         CSS        JS
   Stream 1    Stream 2   Stream 3
Enter fullscreen mode Exit fullscreen mode

HTTP/3

HTTP/3 uses:

HTTP/3
  ↓
QUIC
  ↓
UDP
  ↓
IP
Enter fullscreen mode Exit fullscreen mode

QUIC integrates transport and TLS functionality into its protocol design and provides features such as stream multiplexing and connection migration.

So the simplified modern stack can look like:

HTTP/3
  ↓
QUIC
  ↓
UDP
  ↓
IP
Enter fullscreen mode Exit fullscreen mode

instead of:

HTTP/2
  ↓
TLS
  ↓
TCP
  ↓
IP
Enter fullscreen mode Exit fullscreen mode

43. 🧠 The Entire Journey

Let's put everything together.

flowchart TD
    A["⌨️ Type URL"] --> B["Browser parses URL"]
    B --> C["Cache checks"]
    C --> D["DNS resolution"]
    D --> E["IP address"]
    E --> F["TCP or QUIC connection"]
    F --> G["TLS / HTTPS"]
    G --> H["HTTP request"]
    H --> I["CDN / Load Balancer"]
    I --> J["Web Server"]
    J --> K["Application"]
    K --> L["Database / APIs"]
    L --> M["HTTP Response"]
    M --> N["HTML"]
    N --> O["DOM"]
    N --> P["CSS"]
    P --> Q["CSSOM"]
    O --> R["Render Tree"]
    Q --> R
    R --> S["Layout"]
    S --> T["Paint"]
    T --> U["Composite"]
    U --> V["🖥️ Pixels on Screen"]

44. 🎯 The 10-Second Explanation

If someone asks you:

“What happens when I type a URL?”

You can answer:

The browser parses the URL, resolves the domain through DNS, establishes a network connection, negotiates HTTPS when applicable, sends an HTTP request to the server, receives the response, downloads additional resources like CSS and JavaScript, builds the DOM and rendering structures, calculates layout, paints the page, and finally displays the result on your screen.

45. 🧩 The Mental Model

Remember these layers:

                    🌐 WEBPAGE
                       ▲
                       │
                 Rendering
                       ▲
                       │
                HTML / CSS / JS
                       ▲
                       │
                    HTTP
                       ▲
                       │
                 TLS / HTTPS
                       ▲
                       │
               TCP / QUIC / UDP
                       ▲
                       │
                       IP
                       ▲
                       │
                    DNS
                       ▲
                       │
                     URL
Enter fullscreen mode Exit fullscreen mode

Or even simpler:

URL
 ↓
WHERE?
 ↓
DNS

HOW DO I CONNECT?
 ↓
TCP / QUIC

HOW DO I SECURE IT?
 ↓
TLS

WHAT DO I WANT?
 ↓
HTTP

WHERE DOES IT GO?
 ↓
CDN / Server / Application

WHAT DID I GET?
 ↓
HTML / CSS / JS

HOW DO I SHOW IT?
 ↓
DOM → Layout → Paint → Composite

🎨 SCREEN
Enter fullscreen mode Exit fullscreen mode

🧪 Mini Experiment

Open your browser and try this:

1. Open DevTools 

F12 / Right Click → Inspect
Enter fullscreen mode Exit fullscreen mode

2. Open Network 

Network → Reload
Enter fullscreen mode Exit fullscreen mode

3. Click the first document request

Look for:

Request URL
Status Code
Remote Address
Response Headers
Timing
Enter fullscreen mode Exit fullscreen mode

4. Run DNS 

dig example.com
Enter fullscreen mode Exit fullscreen mode

5. Inspect HTTP 

curl -I https://example.com
Enter fullscreen mode Exit fullscreen mode

6. Trace the route 

traceroute example.com
Enter fullscreen mode Exit fullscreen mode

Now you're no longer just learning the theory.

You're watching the process happen.

🎬 Suggested Video Flow

For teaching this on YouTube, don't present it like a textbook.

Use the browser as the protagonist.

Start with:

https://example.com
Enter fullscreen mode Exit fullscreen mode

Then say:

“I'm going to press Enter. Your browser is about to do way more work than you think.”

Then reveal the journey one step at a time:

YOU
 ↓
URL
 ↓
DNS
 ↓
IP
 ↓
TCP / QUIC
 ↓
TLS
 ↓
HTTP
 ↓
SERVER
 ↓
HTML
 ↓
CSS + JS
 ↓
RENDERING
 ↓
SCREEN
Enter fullscreen mode Exit fullscreen mode

At each stage, show the relevant DevTools panel or a simple animation.

🏁 Final Takeaway

The next time you type:

https://youtube.com
Enter fullscreen mode Exit fullscreen mode

don't think:

“A website opened.”

Think:

I entered a URL
      ↓
The browser interpreted it
      ↓
DNS found the destination
      ↓
A network path was established
      ↓
HTTPS secured the communication
      ↓
HTTP requested the resource
      ↓
Servers processed my request
      ↓
HTML/CSS/JS came back
      ↓
The browser parsed everything
      ↓
Layout was calculated
      ↓
Pixels were painted
      ↓
🎨 I see a webpage
Enter fullscreen mode Exit fullscreen mode

That tiny moment between pressing Enter and seeing a webpage is an entire distributed-system story happening in milliseconds.

📚 Concepts Covered

Networking

DNS · IP · TCP · UDP · QUIC · Routing · Packets

Security

HTTPS · TLS · Certificates · Encryption · Certificate Authorities

Web

HTTP · Headers · Cookies · Status Codes · CDN · Load Balancers · APIs

Backend

Servers · Application Logic · Databases · Caching

Browser

HTML · DOM · CSSOM · Render Tree · Layout · Paint · Composite · JavaScript

💭 One Last Question

The next time a website takes 5 seconds to load, ask:

Where exactly did those 5 seconds go?

Maybe it was DNS.

Maybe the network.

Maybe TLS.

Maybe the server.

Maybe the database.

Maybe JavaScript.

Maybe rendering.

And that's exactly what browser DevTools lets you investigate. 🔍

Top comments (0)