What Really Happens When You Type google.com in Your Browser?

You open Chrome.

You click the address bar.

You type:

google.com

And press Enter.

A fraction of a second later, Google’s homepage appears.

It feels simple.

But behind those 11 characters, your computer may perform DNS lookups, cache checks, TCP/TLS handshakes, HTTP requests, load balancing, server-side processing, JavaScript execution, DOM construction, layout, painting, and compositing.

Let’s follow the complete journey.
. You Type google.com

The first thing that happens is not DNS.

The browser first needs to figure out:

“What does the user mean by this input?”

Is it a URL?

A search query?

A local address?

For:

google.com

the browser recognizes that this looks like a domain name.

It then constructs something conceptually similar to:

https://google.com/

Modern browsers may also apply policies such as HTTPS upgrades and HSTS before making the request.

But before going to the network, the browser may have something much faster available.

2. Check the Cache

Why go to the network if the browser already has what it needs?

The browser can potentially use several layers of locally available information.

A simplified view is:

Browser
   │
   ├── HTTP Cache
   │
   ├── Service Worker
   │
   ├── DNS Cache
   │
   └── Connection Pool

These caches serve different purposes.

For example:

HTTP cache

The browser might already have:

style.css
app.js
logo.png

stored locally.

If the resource is still fresh, the browser may not need to download it again.

Service Worker

A website can register a Service Worker that intercepts requests:

Browser
   │
   ↓
Service Worker
   │
   ├── Cache hit → return cached response
   │
   └── Cache miss → network

This is one reason some websites can appear incredibly fast after you’ve visited them before.

3. DNS — What Is google.com?

Your computer doesn’t communicate with:

google.com

directly.

Networks ultimately need an IP address.

For example:

google.com
     ↓
     ?
     ↓
IP address

DNS — the Domain Name System — translates domain names into IP addresses.

Think of DNS as the internet’s phone book.

google.com
     ↓
DNS
     ↓
IP address

But even here, we don’t necessarily contact a DNS server immediately.

There can be multiple caches.

Browser DNS Cache
        ↓
OS DNS Cache
        ↓
Router / Local DNS
        ↓
Recursive DNS Resolver
        ↓
Root DNS
        ↓
.com DNS
        ↓
Authoritative DNS

If the answer is already cached, DNS resolution can be extremely fast.

4. Finding the Server

Suppose DNS gives us an IP address.

Now the browser knows where it needs to connect.

Conceptually:

google.com
     ↓
DNS
     ↓
142.x.x.x

But that doesn’t necessarily mean your request is going directly to Google’s application server.

Large websites typically sit behind infrastructure such as:

Internet
                    │
                    ↓
              ┌───────────┐
              │    CDN    │
              └─────┬─────┘
                    ↓
              ┌───────────┐
              │   Load    │
              │ Balancer  │
              └─────┬─────┘
                    ↓
          ┌─────────┼─────────┐
          ↓         ↓         ↓
       Server A  Server B  Server C

The request may be routed to infrastructure geographically or based on load.

5. Establishing a Connection

Now the browser needs a network connection.

Depending on the protocol being used, this can involve different mechanisms.

For traditional HTTP/1.1 or HTTP/2 over TLS, conceptually:

Browser
   │
   │ TCP connection
   ↓
Server
   │
   │ TLS handshake
   ↓
Secure connection

TCP historically begins with the famous three-way handshake:

Client                 Server

  SYN ────────────────→
      ←──────── SYN-ACK
  ACK ────────────────→

Then TLS establishes encryption.

Modern HTTP/3 uses QUIC, which runs over UDP and combines transport and TLS establishment differently.

The important idea is:

Before your HTTP request can be processed, the browser needs a usable secure connection to the server infrastructure.

6. The Browser Finally Sends the HTTP Request

Now we get to something familiar:

GET / HTTP/2
Host: google.com
Accept: text/html
Accept-Encoding: gzip, br
User-Agent: ...

Conceptually:

Browser
   │
   │ GET /
   ↓
Internet
   │
   ↓
Google infrastructure

The request may contain many headers that provide information about:

• accepted content types
• compression
• cookies
• language preferences
• browser information
• authentication/session information
• caching

7. The Request Travels Through the Backend

This is where the architecture becomes interesting.

Your request might pass through multiple layers.

Request
                    │
                    ↓
              ┌───────────┐
              │    CDN    │
              └─────┬─────┘
                    ↓
              ┌───────────┐
              │   Load    │
              │ Balancer  │
              └─────┬─────┘
                    ↓
              ┌───────────┐
              │ API / Web │
              │  Server   │
              └─────┬─────┘
                    ↓
           ┌────────┼────────┐
           ↓        ↓        ↓
        Service   Service   Service
           │        │        │
           └────────┼────────┘
                    ↓
              ┌───────────┐
              │ Database  │
              └───────────┘

A simple website might involve only a few components.

A large-scale application can involve many distributed services.

The backend might need to:

1. Authenticate the request.
2. Determine what content is required.
3. Fetch data.
4. Query caches.
5. Call other services.
6. Generate or retrieve HTML/data.
7. Return the response.

8. The Server Sends a Response

Eventually, your browser receives something like:

HTTP/2 200 OK
Content-Type: text/html
Content-Encoding: br
Cache-Control: ...

And then the response body.

For a traditional server-rendered application, that could be HTML.

For a modern web application, it could be a combination of:

HTML
CSS
JavaScript
Images
Fonts
JSON

The browser now enters a completely different phase.

The network got us the data.

Now the browser has to turn that data into pixels.

9. HTML → DOM

The browser receives HTML.

For example:

<html>
  <body>
    <h1>Hello</h1>
    <button>Search</button>
  </body>
</html>

The browser parses it and creates the DOM — Document Object Model.

Conceptually:

HTML
 │
 │ Parser
 ↓
DOM Tree

Document
   │
   └── html
        │
        └── body
             ├── h1
             │    └── "Hello"
             │
             └── button
                  └── "Search"

The DOM is essentially the browser’s structured representation of the HTML document.

10. CSS → CSSOM

Now the browser needs to understand how things should look.

Suppose we have:

h1 {
  font-size: 32px;
}

button {
  padding: 10px;
}

The browser parses CSS and creates a representation called the CSSOM.

So we now have:

HTML
 ↓
DOM

CSS
 ↓
CSSOM

The browser combines information from both.

11. DOM + CSSOM → Render Tree

The browser now needs to determine what actually participates in rendering.

Conceptually:

HTML
              │
              ↓
             DOM
              │
              ├──────────┐
              │          │
              │          ↓
              │         CSS
              │          │
              │          ↓
              │         CSSOM
              │          │
              └────┬─────┘
                   ↓
              Render Tree

The Render Tree contains the visual representation that will eventually be laid out and painted.

For example, elements such as:

display: none;

don’t participate in the rendered output in the same way as visible elements.

12. Style Calculation

Now the browser asks:

“What styles does every visible element actually have?”

This is called style calculation.

Get pavan bhansali’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The browser considers things such as:

• CSS selectors
• inheritance
• cascade
• computed values
• media queries
• pseudo-classes
• browser defaults

For example:

div {
  color: red;
}

.card div {
  color: blue;
}

The browser needs to determine which rule wins for a particular element.

The result is a set of computed styles.

13. Layout — Where Does Everything Go?

Knowing that a button should be:

width: 100px
height: 40px

isn’t enough.

The browser also needs to know:

Where should the button be placed?

This is the layout phase.

For example:

Viewport
┌─────────────────────────────┐
│                             │
│        Heading              │
│                             │
│    ┌───────────────────┐    │
│    │      Button       │    │
│    └───────────────────┘    │
│                             │
└─────────────────────────────┘

The browser calculates:

x
y
width
height

for elements.

Layout is sometimes called reflow.

And here’s an important performance lesson:

Changing certain layout-related properties can cause expensive work because other elements may need to be repositioned.

14. Paint — Turn Things Into Pixels

Now the browser knows:

WHAT to display
WHERE to display it

Next:

“How should it actually look?”

This is painting.

The browser paints things such as:

• text
• backgrounds
• borders
• shadows
• images
• gradients

Conceptually:

Layout
  ↓
Paint commands
  ↓
Pixels / paint information

Imagine the browser receiving instructions like:

Draw background
Draw rectangle
Draw border
Draw text
Draw image
Draw shadow

These operations eventually contribute to what appears on screen.

15. Composite — The Often-Misunderstood Step

This is one of the most interesting parts.

Modern browsers don’t necessarily treat the entire page as one giant bitmap.

Some content can be placed into separate composited layers.

For example:

┌─────────────────────────────┐
│       Main Page Layer       │
│                             │
│   ┌─────────────────────┐   │
│   │   Animated Layer    │   │
│   └─────────────────────┘   │
│                             │
│          ┌───────┐          │
│          │ Image │          │
│          └───────┘          │
└─────────────────────────────┘

The compositor takes these layers and combines them in the correct order.

Layer 1 ─────┐
Layer 2 ─────┤
Layer 3 ─────┼──→ Composite → Screen
Layer 4 ─────┤
Layer 5 ─────┘

This is especially useful for things like animations and transforms.

For example:

transform: translateX(100px);

can sometimes be handled primarily by the compositor without requiring the browser to redo layout for the entire page.

That’s one reason properties such as transform and opacity are commonly preferred for smooth animations.

16. Finally — The Screen

After all that:

HTML
 ↓
DOM
 ↓
CSSOM
 ↓
Style Calculation
 ↓
Layout
 ↓
Paint
 ↓
Composite
 ↓
🖥️ Pixels on your screen

You see:

Google.

And all you did was press Enter.

But What About JavaScript?

We haven’t talked about one of the biggest pieces yet.

JavaScript.

A modern application might look more like:

HTML
 │
 ├───────────────┐
 ↓               ↓
DOM             CSS
 │               │
 │               ↓
 │             CSSOM
 │               │
 └───────┬───────┘
         ↓
    Initial Render
         │
         ↓
   JavaScript loads
         │
         ↓
   JavaScript executes
         │
         ↓
   DOM updates
         │
         ↓
   Style Calculation
         │
         ↓
      Layout
         │
         ↓
       Paint
         │
         ↓
     Composite

This is where frameworks such as React enter the picture.

React Changes the Story — But Not the Browser’s Final Job

Suppose React renders:

function App() {
  return (
    <div>
      <h1>Hello</h1>
      <button>Search</button>
    </div>
  );
}

React has its own rendering process.

Conceptually:

React Component
      ↓
React Render
      ↓
Reconciliation
      ↓
DOM Updates

But React doesn’t paint pixels onto your monitor.

The browser still does:

DOM
 ↓
Style
 ↓
Layout
 ↓
Paint
 ↓
Composite
 ↓
Screen

This distinction is extremely important.

There are effectively two different meanings of “rendering” happening:

React rendering

Component
   ↓
React reconciliation
   ↓
DOM changes

Browser rendering

DOM + CSS
   ↓
Style calculation
   ↓
Layout
   ↓
Paint
   ↓
Composite
   ↓
Screen

React prepares the UI.

The browser turns it into pixels.

The Complete Journey

Let’s put everything together.

USER
                  │
                  │ Types google.com
                  ↓
          ┌─────────────────┐
          │     Browser     │
          └────────┬────────┘
                   │
                   ↓
            Cache / SW / HSTS
                   │
                   ↓
              DNS Lookup
                   │
                   ↓
              IP Address
                   │
                   ↓
          TCP / QUIC + TLS
                   │
                   ↓
             HTTP Request
                   │
                   ↓
             ┌───────────┐
             │    CDN    │
             └─────┬─────┘
                   ↓
             Load Balancer
                   │
                   ↓
             Backend/API
                   │
          ┌────────┼────────┐
          ↓        ↓        ↓
       Service  Service  Service
          │        │        │
          └────────┼────────┘
                   ↓
               Database
                   │
                   ↓
             HTTP Response
                   │
                   ↓
            HTML / CSS / JS
                   │
                   ↓
              HTML Parser
                   │
                   ↓
                  DOM
                   │
             CSS Parser
                   │
                   ↓
                 CSSOM
                   │
             ┌─────┴─────┐
             ↓           ↓
       Style Calculation
                   │
                   ↓
                 Layout
                   │
                   ↓
                  Paint
                   │
                   ↓
               Composite
                   │
                   ↓
                🖥️ Screen

One More Important Question: Why Does the Second Visit Feel Faster?

Imagine you visit the same website again.

The browser may already have:

DNS information
HTTP resources
CSS
JavaScript
Images
Fonts
TLS connections

cached or reused.

So the journey can become:

First Visit

Browser
  ↓
DNS
  ↓
Connection
  ↓
Server
  ↓
Download everything
  ↓
Render

Second Visit
Browser
  ↓
Cache / Existing Connection
  ↓
Download only what's necessary
  ↓
Render

This is one of the fundamental reasons caching is so important for web performance.

Where Can Performance Go Wrong?

Once you understand the pipeline, performance problems become easier to reason about.

Your page can be slow because of:

Page Load
                     │
      ┌──────────────┼──────────────┐
      ↓              ↓              ↓
   Network        Backend        Browser
      │              │              │
      ↓              ↓              ↓
    DNS           Database       JavaScript
    TLS           APIs           Style
    Download      Services       Layout
    Latency       Processing     Paint
                                  Composite

For example:

Slow DNS

DNS ────────────────→ slow

Slow backend

Browser → API ───────────────→ slow

Huge JavaScript bundle

Download
   ↓
Parse
   ↓
Compile
   ↓
Execute
   ↓
Main thread blocked

Expensive layout

DOM change
   ↓
Style recalculation
   ↓
Layout
   ↓
Paint

Too much JavaScript

JavaScript
     ↓
Main Thread
     ↓
████████████████████

The browser can’t respond smoothly while the main thread is overloaded.

The Mental Model I Use

Whenever I think about web performance, I divide the journey into three big worlds.

┌───────────────────────────────────────────┐
│                  WORLD 1                  │
│                NETWORK                    │
│                                           │
│ DNS → TCP/QUIC → TLS → HTTP → Server     │
└─────────────────────┬─────────────────────┘
                      ↓
┌───────────────────────────────────────────┐
│                  WORLD 2                  │
│                 SERVER                    │
│                                           │
│ CDN → LB → APIs → Services → Database    │
└─────────────────────┬─────────────────────┘
                      ↓
┌───────────────────────────────────────────┐
│                  WORLD 3                  │
│                 BROWSER                   │
│                                           │
│ HTML → DOM → CSSOM → Style → Layout      │
│              → Paint → Composite         │
└─────────────────────┬─────────────────────┘
                      ↓
                    🖥️
                   SCREEN

And this gives us a simple debugging strategy.

If the page is slow:

Ask where the time is going.

Is it the network?
       ↓
Is it the server?
       ↓
Is it downloading too much?
       ↓
Is JavaScript blocking the main thread?
       ↓
Is layout expensive?
       ↓
Is painting expensive?
       ↓
Are too many layers being composited?

Instead of simply saying:

“The website is slow.”

You can ask:

Which stage of the browser-to-pixel pipeline is slow?

That’s a much more useful question.

Final Thought

The next time you type:

google.com

don’t think of it as:

“I requested a webpage.”

Think of it as a pipeline:

Human
  ↓
Browser
  ↓
Cache
  ↓
DNS
  ↓
Network
  ↓
CDN
  ↓
Load Balancer
  ↓
Backend
  ↓
HTTP Response
  ↓
HTML / CSS / JS
  ↓
DOM / CSSOM
  ↓
Style
  ↓
Layout
  ↓
Paint
  ↓
Composite
  ↓
Pixels
  ↓
Your eyes 👀

11 characters trigger an entire distributed system and graphics pipeline.

And that’s what makes the modern web fascinating.