You type:
https://www.google.com
You press Enter.
A fraction of a second later, Google appears on your screen.
It feels almost instantaneous.
But behind that single action, your browser may perform DNS resolution, connection establishment, TLS negotiation, HTTP communication, server-side processing, HTML parsing, CSS processing, JavaScript execution, layout calculation, painting, and compositing.
And all of this happens while you are simply waiting to see a webpage.
So what actually happens when you open google.com?
Let's follow the request from your keyboard all the way to the pixels on your screen.
The Complete Journey
At a high level, the journey looks like this:
You type google.com
↓
Browser interprets the URL
↓
Check browser / OS caches
↓
DNS Resolution
↓
IP Address discovered
↓
Connection established
↓
TLS Handshake
↓
HTTP Request
↓
Google's infrastructure
↓
HTTP Response
↓
Browser receives HTML
↓
HTML → DOM
CSS → CSSOM
↓
Render Tree
↓
Layout
↓
Paint
↓
Compositing
↓
Pixels appear on screen
But each of these steps contains a lot more interesting engineering.
Let's start from the beginning.
1. You Type google.com
You open Chrome, Firefox, Safari, or another browser and type:
google.com
The browser doesn't immediately send those characters to Google.
First, it needs to understand what you entered.
The browser's UI process determines whether the input is:
- a URL
- a search query
- or something else
For example:
google.com
looks like a domain name, while:
best laptops for programming
looks more like a search query.
Modern browsers perform this processing before navigation begins.
In Chromium-based browsers, navigation involves the browser process, networking components, and a renderer process that eventually handles the webpage.
Once the browser determines that you're navigating to a website, the real journey begins.
2. The Browser Needs an IP Address
Computers communicate across networks using IP addresses.
Humans prefer:
google.com
Machines ultimately need something like:
<IP address>
So the browser needs to answer:
"Which IP address belongs to google.com?"
This is where DNS comes in.
DNS stands for:
Domain Name System
You can think of DNS as the internet's distributed phone book.
Instead of remembering:
142.x.x.x
you remember:
google.com
DNS maps the human-readable domain name to an IP address.
3. DNS Resolution
The browser doesn't necessarily perform a complete DNS lookup every time.
There can be multiple layers of caching.
A simplified flow looks like:
Browser
↓
OS / DNS cache
↓
DNS Resolver
↓
Root DNS Servers
↓
.com TLD Servers
↓
Google's Authoritative DNS
↓
IP Address
However, if a cached DNS result is still valid, some of these steps can be avoided.
This is one reason why repeated visits to websites can behave differently from the first visit.
Why caching matters
Imagine if every webpage visit required starting from the root DNS infrastructure.
That would add unnecessary latency.
Instead, DNS responses have a TTL (Time To Live) that allows results to be cached for a period of time.
So the browser may effectively say:
"I already know where google.com is."
and skip much of the lookup process.
Modern DNS can also use encrypted transports such as DNS over HTTPS (DoH) or DNS over TLS (DoT), depending on the system and browser configuration.
4. DNS Gives Us an IP Address
Eventually, the system obtains an address for the destination.
Now the browser knows:
google.com
↓
IP address
But knowing where to send the request isn't enough.
The browser still needs to establish communication with the server.
And this is where networking begins.
5. Establishing the Connection
For traditional HTTPS over TCP, the browser establishes a TCP connection to the destination.
TCP provides reliable, ordered delivery of data.
A simplified TCP handshake looks like:
Client Server
SYN ------------------------>
<------------------- SYN-ACK
ACK ------------------------>
This is commonly called the three-way handshake.
The goal is to establish the connection and synchronize the communication state between both sides.
Only after the connection is established can the browser proceed with the next stage.
But there's another important requirement.
We're visiting:
https://google.com
not:
http://google.com
So the communication needs to be encrypted.
6. The TLS Handshake
HTTPS uses TLS (Transport Layer Security) to protect the connection.
TLS provides important security properties including:
- Encryption
- Integrity
- Server authentication
The browser needs to establish cryptographic keys that can be used to securely communicate with the server.
A simplified TLS flow looks like:
Browser Server
ClientHello -------------------->
<---------------- ServerHello
<---------------- Certificate
<---------------- Key Exchange
Certificate verification
Key establishment
Finished ---------------------->
<---------------- Finished
The actual modern TLS handshake is more nuanced, but conceptually the browser and server are establishing a secure communication channel.
Why does the certificate matter?
Suppose you typed:
https://google.com
You don't want an attacker pretending to be Google.
The server provides a certificate that allows the browser to verify that the server is authorized for the requested domain.
If certificate validation fails, the browser can display a security warning instead of silently trusting the connection.
7. Now We Can Send an HTTP Request
DNS told us where to go.
TCP established reliable communication.
TLS established secure communication.
Now HTTP can finally do its job.
The browser sends an HTTP request.
Conceptually, it looks something like:
GET / HTTP/2
Host: www.google.com
User-Agent: ...
Accept: text/html
Accept-Language: en-US
Cookie: ...
The actual request headers and protocol details vary depending on the browser, connection, cookies, HTTP version, and other factors.
The important part is:
GET /
The browser is essentially saying:
"Give me the resource at the root path."
8. Your Request Travels Across the Internet
The request doesn't magically teleport from your laptop to Google.
It travels through a network.
A simplified model might look like:
Your Browser
↓
Your Device
↓
Wi-Fi Router
↓
ISP
↓
Internet Routers
↓
Google's Network
↓
Google Infrastructure
Every packet can travel through multiple network devices before reaching its destination.
Routers examine addressing information and determine where packets should go next.
This is one of the fascinating things about the internet:
Your browser doesn't need to know the entire route to Google's servers.
The network infrastructure handles routing.
9. The Request Reaches Google's Infrastructure
This is where the story gets much more interesting.
A request to a massive service isn't simply:
Internet → One Server
Large-scale systems typically have layers of infrastructure designed to handle enormous amounts of traffic.
A conceptual architecture could look like:
Internet
↓
Edge Network
↓
Load Balancing
↓
Frontend / Web Servers
↓
Application Services
↓
Internal Services / Storage
The exact architecture of Google's production systems is complex and not something we can reduce to one simple diagram.
But the important distributed-systems lesson is:
A large website is usually an ecosystem of services, not one giant computer.
10. The Server Processes the Request
Once the request reaches the appropriate service, the server determines what response should be returned.
Depending on the website, this might involve:
- Authentication
- Cookies
- Request routing
- Feature flags
- Personalization
- Application logic
- Cache lookup
- Database access
- Internal APIs
- Other services
For a simple static website, the server might be able to return cached content almost immediately.
For a dynamic application, the request may trigger much more work.
This is why backend architecture matters.
The user sees:
Google loaded.
But the backend may have performed many operations before the browser receives the response.
11. The Server Sends an HTTP Response
Eventually, the browser receives an HTTP response.
Conceptually:
HTTP/2 200
Content-Type: text/html
Content-Encoding: ...
Cache-Control: ...
followed by the response body.
The response body could contain HTML such as:
<!DOCTYPE html>
<html>
<head>
...
</head>
<body>
...
</body>
</html>
The browser now has something important:
HTML.
But the page isn't "finished" yet.
This is where browser rendering begins.
12. The Browser Starts Parsing HTML
The browser's rendering engine receives the HTML.
It doesn't simply wait for the entire document and then process everything at once.
HTML can be processed progressively as data arrives.
Modern browsers can parse streamed HTML incrementally, allowing rendering work to begin before the entire response has arrived.
The HTML parser turns markup into a structure called the:
DOM
DOM stands for:
Document Object Model
For example:
<body>
<h1>Hello</h1>
<p>Welcome!</p>
</body>
can be represented conceptually as:
Document
|
└── body
|
├── h1
| └── "Hello"
|
└── p
└── "Welcome!"
This tree structure allows JavaScript and browser APIs to interact with the document.
13. HTML Isn't Enough
HTML tells the browser:
"What elements exist?"
But it doesn't fully describe how those elements should look.
That's the job of CSS.
For example:
h1 {
font-size: 40px;
margin-bottom: 20px;
}
The browser needs to download and process the CSS.
It constructs another representation called the:
CSSOM
CSSOM stands for:
CSS Object Model
So now we have:
HTML
↓
DOM
CSS
↓
CSSOM
14. DOM + CSSOM
The browser combines information from the DOM and CSSOM to determine what should actually be rendered.
Conceptually:
HTML
↓
DOM
\
\
→ Render information
/
/
CSSOM
↑
CSS
This produces the information needed for rendering.
A simplified representation is often called the render tree.
The render tree contains the visual information necessary for the browser to determine what appears on the screen.
15. Then Comes Layout
The browser now needs to answer:
Where exactly should every element appear?
Suppose you have:
<div>
<h1>Hello</h1>
<p>This is a paragraph.</p>
</div>
The browser needs to calculate things such as:
h1:
x = 40
y = 20
width = 300
height = 50
p:
x = 40
y = 90
width = 500
height = 80
This process is called:
Layout
or sometimes:
Reflow
The browser calculates the geometry of visible elements.
This includes:
- Position
- Width
- Height
- Margins
- Padding
- Line wrapping
- Font metrics
- Relationships between elements
And this can become computationally expensive on complex pages.
16. Painting the Page
Once the browser knows where everything goes, it needs to determine what should actually be drawn.
This stage is called:
Paint
The browser creates drawing instructions for things such as:
- Text
- Backgrounds
- Borders
- Shadows
- Images
- Gradients
Conceptually:
DOM + CSS
↓
Layout
↓
Paint instructions
But we're still not quite done.
17. Compositing
Modern browsers don't necessarily draw the entire webpage as one giant image.
Different parts of a page can be handled as separate compositing layers.
For example:
Layer 1 → Background
Layer 2 → Main content
Layer 3 → Fixed header
Layer 4 → Animation
The browser can then composite these layers together.
Conceptually:
Painted Layers
↓
Compositor
↓
GPU / Display Pipeline
↓
Screen
This is one reason certain CSS operations can be significantly cheaper to animate than operations that repeatedly trigger expensive layout work.
18. JavaScript Enters the Picture
Modern websites aren't just HTML and CSS.
JavaScript can:
- Modify the DOM
- Respond to user interactions
- Fetch APIs
- Track state
- Update the UI
- Start animations
- Load additional resources
- Communicate with servers
For example:
button.addEventListener("click", () => {
console.log("Clicked!");
});
When JavaScript changes the page, the browser may need to perform additional rendering work.
For example:
JavaScript
↓
DOM change
↓
Style calculation
↓
Layout
↓
Paint
↓
Composite
Not every JavaScript operation triggers every stage, but expensive DOM and style changes can cause significant work.
19. One Page Can Trigger Many Requests
Here's an important realization.
You didn't just request:
google.com
The initial HTML can reference many additional resources.
For example:
HTML
├── CSS
├── JavaScript
├── Images
├── Fonts
├── API requests
└── Other resources
The browser discovers these resources while processing the document and requests them as needed.
This means a webpage is often not:
1 request → 1 response
It is closer to:
Navigation request
↓
HTML
↓
┌─────┼─────┬─────┐
↓ ↓ ↓ ↓
CSS JS Images Fonts
↓
API Requests
↓
More Data
That's why network waterfalls in Chrome DevTools can become surprisingly large.
20. HTTP/2 and HTTP/3 Make This More Efficient
Modern web communication isn't limited to the old HTTP/1.1 model.
HTTP/2 introduced features such as:
- Multiplexing
- Header compression
- Stream prioritization mechanisms
This allows multiple requests and responses to share a connection more efficiently.
HTTP/3 goes further by using QUIC, which runs over UDP and incorporates transport and TLS functionality into the protocol stack.
Conceptually:
Older model:
HTTP
↓
TCP
↓
IP
HTTP/2:
HTTP/2
↓
TCP
↓
IP
HTTP/3:
HTTP/3
↓
QUIC
↓
UDP
↓
IP
The important point is that the web's transport layer has evolved significantly to reduce latency and improve performance.
21. Caching Can Change Everything
Now imagine you've already visited Google.
The browser may already have cached some resources.
Instead of downloading everything again:
Browser
↓
"Do I already have this?"
↓
YES
↓
Use cached resource
Caching can exist at multiple layers:
Browser Cache
↓
Operating System / Network Cache
↓
CDN / Edge Cache
↓
Server Cache
↓
Database / Storage
A good caching strategy can dramatically reduce:
- Network requests
- Server work
- Latency
- Bandwidth usage
This is one of the most important performance principles in web development.
22. The Browser Finally Shows You the Page
After all this:
DNS
↓
Connection
↓
TLS
↓
HTTP
↓
Server
↓
HTML
↓
DOM
↓
CSSOM
↓
Render Tree
↓
Layout
↓
Paint
↓
Composite
↓
Pixels
you finally see the webpage.
To you, it looked like:
Type → Enter → Website
But internally, an enormous amount of work happened.
23. What Happens When You Click Something?
The process doesn't end when the page appears.
Suppose you click a button.
The browser might perform:
Mouse Event
↓
JavaScript Event Handler
↓
State Change
↓
DOM Update
↓
Style Calculation
↓
Layout
↓
Paint
↓
Composite
Or perhaps the button triggers an API request:
Click
↓
JavaScript
↓
fetch("/api/data")
↓
HTTP Request
↓
Server
↓
Database / Service
↓
HTTP Response
↓
JavaScript
↓
UI Update
So the same concepts repeat throughout the lifetime of the application.
24. Where Performance Problems Come From
Now the entire process becomes useful from an engineering perspective.
A webpage can be slow for completely different reasons.
DNS is slow
The browser spends more time resolving the domain.
Connection establishment is slow
Network latency or connection setup adds delay.
Server response is slow
The backend takes too long to generate the response.
HTML is large
The browser has more data to download and parse.
JavaScript is expensive
The main thread can become blocked.
CSS is expensive
Style calculation and layout can become costly.
Images are huge
Downloading and decoding them takes time.
Too many requests
The browser has more network work to coordinate.
Third-party scripts are expensive
Analytics, ads, widgets, and other external code compete for network and CPU resources.
This is why web performance isn't simply:
"Make your JavaScript faster."
Performance is an end-to-end problem.
25. The Browser Is Doing Multiple Things at Once
One of the biggest misconceptions about browsers is thinking they execute the webpage as one simple sequence.
Modern browsers are complex, multi-process systems.
A simplified architecture might look like:
Browser
|
┌───────────┼───────────┐
↓ ↓ ↓
Browser Network Storage
Process Work Work
|
↓
Renderer Process
|
┌────┼────┐
↓ ↓ ↓
HTML CSS JS
|
↓
Rendering Pipeline
|
↓
GPU
|
↓
Screen
Chromium's architecture separates browser-level responsibilities from renderer responsibilities, with communication between processes handled through IPC.
This architecture provides important isolation and allows browsers to manage complex web applications more safely and efficiently.
26. The Entire Journey in One Diagram
Here's the complete mental model I use:
USER
│
▼
Types google.com
│
▼
Browser UI
│
▼
URL Interpretation
│
▼
DNS Resolution
│
▼
IP Address
│
▼
Connection Establishment
│
▼
TLS Handshake
│
▼
HTTP Request
│
▼
┌───────────────────┐
│ Google's Network │
│ │
│ Edge / Routing │
│ Load Balancing │
│ Application Logic │
│ Internal Services │
└───────────────────┘
│
▼
HTTP Response
│
▼
HTML
│
┌───────┴────────┐
▼ ▼
DOM CSSOM
│ │
└───────┬────────┘
▼
Render Tree
│
▼
Layout
│
▼
Paint
│
▼
Compositing
│
▼
GPU
│
▼
SCREEN
And that entire pipeline happens incredibly quickly.
27. The Most Important Mental Model
If you're preparing for frontend, backend, or system-design interviews, don't memorize a list of terms.
Understand the dependency chain:
DNS
↓
Where is the server?
Connection
↓
How do I communicate with it?
TLS
↓
Can I communicate securely?
HTTP
↓
What resource do I want?
Server
↓
How should the request be processed?
HTML
↓
What exists on the page?
CSS
↓
How should it look?
JavaScript
↓
How should it behave?
Layout
↓
Where does everything go?
Paint
↓
What should be drawn?
Compositing
↓
How should the layers be combined?
GPU / Display
↓
How do those instructions become pixels?
Once you understand this chain, many seemingly unrelated web-development concepts start making sense.
28. Why This Question Is So Important
"What happens when you open Google.com?" sounds like a beginner question.
It isn't.
A strong answer can touch almost every major area of web development:
Frontend
├── HTML
├── CSS
├── JavaScript
└── Rendering
Networking
├── DNS
├── TCP
├── TLS
├── HTTP
└── IP
Backend
├── Servers
├── APIs
├── Caching
└── Databases
System Design
├── Load Balancing
├── Distributed Systems
├── CDNs
└── Scalability
Performance
├── Latency
├── TTFB
├── Rendering
└── Network Optimization
Security
├── HTTPS
├── TLS
├── Certificates
└── Origin Isolation
One URL can therefore become a tour through almost the entire web stack.
Final Takeaway
The next time you type:
google.com
don't think:
"The website opens."
Think:
URL
↓
DNS
↓
IP
↓
Connection
↓
TLS
↓
HTTP
↓
Server Infrastructure
↓
HTML
↓
DOM
↓
CSSOM
↓
JavaScript
↓
Layout
↓
Paint
↓
Compositing
↓
Pixels
What looks like a single action to the user is actually a coordinated interaction between your browser, operating system, DNS infrastructure, network, security protocols, servers, application services, and rendering engine.
And that is one of the most beautiful things about the web:
A few characters typed into an address bar can trigger an entire distributed system.
Top comments (0)