How a Web Page Actually Works

Programming · Web Development

From a URL typed into your browser to HTML rendered on your screen — a practical introduction to the web request lifecycle.

10 min read · Web Development · HTML · HTTP

A web page can feel deceptively simple. You enter a URL, press Enter, and a few seconds later a page appears.

Behind that simple interaction, however, a surprising number of things happen. Your browser needs to find a server, establish a connection, send a request, receive a response, parse the returned resources and finally construct the page you see.

Understanding this process is one of the most useful foundations for anyone working in web development.

The journey starts with a URL

Imagine entering this address into your browser:

https://example.com/articles/hello-world

A URL contains several pieces of information:

• HTTPS tells the browser which protocol to use.
• example.com identifies the host.
• /articles/hello-world identifies the requested resource.

Before the browser can request the page, it needs to discover where example.com actually lives.

DNS: finding the server

Computers communicate using IP addresses, while humans generally prefer readable domain names. DNS bridges that gap.

example.com
      ↓
     DNS
      ↓
203.0.113.42

The browser asks a DNS resolver for the address associated with the domain. The resolver may already have the answer cached, or it may need to query other DNS servers before returning the result.

You can inspect DNS information from a terminal with dig:

dig example.com

For example, to specifically request an A record:

dig example.com A

DNS is not limited to websites. It is also responsible for records used by email, domain verification, security policies and many other services.

Opening an HTTPS connection

Once the browser knows the server address, it needs to communicate with it. Modern websites generally use HTTPS rather than plain HTTP.

HTTPS combines HTTP with TLS encryption. This protects information travelling between the browser and the server and allows the browser to verify the server’s identity through its certificate.

Browser
   │
   │ DNS lookup
   ↓
Server IP
   │
   │ TLS connection
   ↓
Secure HTTPS channel
   │
   │ HTTP request
   ↓
Web server

This is one reason you should be suspicious of websites that handle sensitive information without HTTPS.

The HTTP request

The browser now sends an HTTP request to the server.

GET /articles/hello-world HTTP/1.1
Host: example.com
Accept: text/html
Accept-Language: en
User-Agent: Browser

The request contains information about what the browser wants and, through headers, additional information about the client and its capabilities.

The most common HTTP methods include:

• GET — retrieve a resource.
• POST — submit data or create something.
• PUT — replace a resource.
• PATCH — partially modify a resource.
• DELETE — remove a resource.

The server processes the request

What happens next depends entirely on the application architecture.

A simple static website might already have an HTML file ready to return. A dynamic application could execute server-side code, query a database, authenticate the user, fetch data from another API and construct a response.

HTTP Request
     ↓
Web Server
     ↓
Application
     ↓
Database / APIs
     ↓
Application Response
     ↓
Web Server
     ↓
HTTP Response

A simple server

You can experiment with this process without deploying anything to the internet. Python includes a small development HTTP server:

mkdir web-demo
cd web-demo

echo '<h1>Hello from the server!</h1>' > index.html

python3 -m http.server 8000

You can then open:

http://localhost:8000

Your browser is now communicating with a web server running on your own computer.

The HTTP response

The server responds with an HTTP response containing a status code, headers and usually a response body.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 42

<h1>Hello from the server!</h1>

The 200 status means the request was successful.

Other status codes you will encounter frequently include:

• 301 — permanent redirect.
• 302 — temporary redirect.
• 400 — bad request.
• 401 — authentication required.
• 403 — forbidden.
• 404 — resource not found.
• 500 — server error.
• 503 — service unavailable.

HTML becomes the document

Once the browser receives the HTML, it begins parsing it.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My Website</title>
</head>
<body>
  <h1>Hello World</h1>
  <p>Welcome to my website.</p>
</body>
</html>

HTML describes the structure and meaning of the document. It does not exist primarily to make the page beautiful.

That responsibility belongs largely to CSS.

CSS transforms the presentation

body {
  font-family: system-ui, sans-serif;
  max-width: 720px;
  margin: 0 auto;
  padding: 2rem;
}

h1 {
  font-size: 3rem;
  line-height: 1;
}

The browser combines the HTML structure with CSS rules to determine how elements should appear on screen.

JavaScript adds behaviour

HTML and CSS can create remarkably capable interfaces, but modern applications often need dynamic behaviour.

const button = document.querySelector("#hello");

button.addEventListener("click", () => {
  document.querySelector("#message").textContent =
    "Hello from JavaScript!";
});

JavaScript can react to user interactions, update the document, communicate with APIs and maintain application state.

The browser builds a page

At a simplified level, the browser turns the received resources into internal structures and eventually paints pixels to the screen.

HTML
 ↓
DOM
 ↓
CSS
 ↓
CSSOM
 ↓
Render tree
 ↓
Layout
 ↓
Paint
 ↓
Screen

This is one reason web performance can become complicated. A page is not simply downloaded and displayed. The browser needs to process the resources before the user can interact with the final interface.

Then the browser asks for more resources

The initial HTML document is rarely the end of the network activity.

The browser may discover stylesheets, JavaScript files, images, fonts and other resources while parsing the document.

<link rel="stylesheet" href="/styles.css">

<script src="/app.js" defer></script>

<img src="/images/hero.webp" alt="Example">

Each external resource can result in another request.

HTML
 ├── styles.css
 ├── app.js
 ├── hero.webp
 ├── logo.svg
 └── font.woff2

This is where network performance, caching, compression and resource prioritisation become important.

Where caching fits in

Imagine requesting the same stylesheet every time you visit a website. That would be wasteful.

Browsers can cache resources and reuse them later according to HTTP caching rules.

Cache-Control: public, max-age=31536000, immutable

With an appropriate caching strategy, a resource that has already been downloaded may not need to be downloaded again.

Caching can exist at several layers:

• Browser cache
• CDN cache
• Reverse proxy cache
• Application cache
• Database or object cache

Where APIs fit in

Modern websites frequently separate the page interface from the data powering it. JavaScript can request data from an API after the initial page has loaded.

const response = await fetch("/api/products");
const products = await response.json();

console.log(products);

The same HTTP concepts apply. The browser sends a request, the server processes it, and the server returns a response.

{
  "products": [
    {
      "id": 101,
      "name": "Example Product",
      "price": 29.90
    },
    {
      "id": 102,
      "name": "Another Product",
      "price": 49.90
    }
  ]
}

Debugging the journey

Once you understand the request lifecycle, browser developer tools become much easier to understand.

Open your browser’s developer tools and select the Network panel. Reload the page and you can inspect the requests generated by the browser.

You can see:

• Request URLs
• HTTP methods
• Status codes
• Request headers
• Response headers
• Transferred size
• Timing information
• Cached resources

For example, a failing API request might look like this:

GET /api/products
→ 500 Internal Server Error

Instead of randomly changing frontend code, you now have a much better starting point: inspect the request, inspect the response and determine which layer failed.

The complete picture

Putting everything together gives us a simplified version of the web request lifecycle:

User enters URL
       ↓
Browser
       ↓
DNS lookup
       ↓
Server IP
       ↓
TLS connection
       ↓
HTTP request
       ↓
Web server
       ↓
Application
       ↓
Database / APIs
       ↓
HTTP response
       ↓
HTML
       ↓
CSS + JavaScript + images
       ↓
Browser rendering
       ↓
Interactive page

Why this matters

You do not need to become a networking expert to build websites. But knowing where each part of the system belongs makes debugging and performance work much more logical.

A slow page might have a slow DNS lookup. A long server response might indicate backend processing. A large JavaScript bundle might delay interactivity. A missing image might simply be a 404. A blocked API request might be caused by authentication or browser security rules.

Instead of seeing the browser as a magical box that somehow produces websites, you can start seeing the individual systems working together.

When something goes wrong, follow the request.

Start with the browser. Check the network request. Inspect the response. Follow it to the server, application, database or external service. Once you know which layer is responsible, the problem becomes much easier to solve.

Final thought

Every website you visit follows some version of this journey.

From a tiny personal page to a massive application serving millions of users, the fundamental conversation remains remarkably consistent:

Client: "I need this resource."

Server: "Here it is."

Browser: "I'll turn it into something useful."

Learn that conversation well and you will have a much stronger foundation for everything that comes next in web development.