You press Enter after typing an address, and in less than a second a complete page appears: text, images, videos, animations. What looks like magic is a precise choreography of protocols, servers, cryptographic certificates, and rendering engines cooperating at the speed of light. This article walks through that invisible journey — from the moment your browser reads a URL to the last pixel painted on screen.
A Brief History
To understand the web, you have to go back to 1989 at CERN in Geneva, Tim Berners‑Lee wrote a proposal titled Information Management: A Proposal. His boss called it "vague but exciting." From that idea came the three pillars that still hold the web together:
Uniquely identifies every resource on the network
Transports resources between client and server
Describes and structures page content
The first server and browser ran on a NeXT workstation in late 1990, and in April 1993 CERN released the code royalty-free, triggering a global adoption explosion. Supporting layers evolved alongside: TCP/IP (RFC 791/793, 1981) provided reliable transport; DNS (RFC 1034/1035, 1987) enabled human-readable names; and TLS 1.3 (RFC 8446, 2018) added modern encryption. Every time you load a page, all these layers activate in cascade.
Step 1 — DNS Resolution
Machines do not understand names like example.com — they speak in IP addresses. The Domain Name System (DNS) translates one into the other through a distributed hierarchy. The browser checks its own cache and the OS cache first. If no answer is found, a recursive resolver walks the hierarchy: root server → TLD server → authoritative server, which finally returns the IP. The whole process typically takes tens of milliseconds.
Imagine you want to call a friend but you only know their name, not their phone number. You look them up in a phonebook and find the number. DNS is the internet's phonebook. When you type google.com, your computer asks DNS: "What's the address for this?" DNS replies with a number (the IP address) that computers can actually use to connect.
Step 2 — TCP Connection
With the IP address in hand, the browser establishes a TCP connection via the three-way handshake — a three-step greeting that guarantees both sides are ready to communicate reliably and in order.
The client sends a segment with an initial sequence number, signalling it wants to open a connection.
The server acknowledges the SYN and proposes its own sequence number.
The client confirms the server's SYN. The channel is open and data can flow.
Before two people have a proper conversation, they usually greet each other first. TCP is that greeting between your computer and the server. Your computer says "Can we talk?", the server replies "Sure, ready!", and your computer confirms "Great, let's go!" — only then do they start exchanging actual information. This makes sure nothing gets lost or arrives in the wrong order.
Step 3 — TLS Encryption
If the URL starts with https://, a security layer is negotiated before any data is sent. TLS 1.3 — the current version — completes the handshake in a single round trip (1-RTT), and even allows 0-RTT when resuming previous sessions.
The browser validates the server's X.509 certificate against its trust store and checks that the hostname matches. TLS 1.3 eliminates obsolete algorithms (RC4, MD5, SHA‑1, static RSA) and enforces forward secrecy: even if someone recorded the traffic today, they could not decrypt it later.
Imagine sending a letter. Without TLS it is like putting your letter in an open envelope — anyone who intercepts it on the way can read it. TLS is like sealing that letter with a lock that only you and the server have the key to. Even if someone intercepts your message, all they see is scrambled nonsense. That is why you see a padlock icon in the browser when visiting https:// sites.
Step 4 — The HTTP Request and the Server
Over the secure connection, the HTTP request finally travels. A typical request looks like this:
GET /index.html HTTP/2 Host: example.com User-Agent: Mozilla/5.0 ... Accept: text/html,application/xhtml+xml,...
The server returns a status code, headers, and the response body. Before reaching the origin server, the request may be intercepted by a CDN (Cloudflare, Fastly, Akamai…) that serves content from a node close to the user, drastically reducing latency.
| Code | Meaning | Example |
|---|---|---|
| 200 | OK — success | Page delivered correctly |
| 301 | Moved Permanently | http:// → https:// redirect |
| 304 | Not Modified | Resource unchanged, use cache |
| 404 | Not Found | URL does not exist on the server |
| 500 | Internal Server Error | Bug in the server's logic |
| 503 | Service Unavailable | Server overloaded or in maintenance |
Think of HTTP like walking into a library. You go to the librarian (the server) and say "I'd like the book on page X, please." The librarian checks, and either hands you the book (200 OK), tells you it moved (301), says it doesn't exist (404), or apologises because something went wrong (500). HTTP is simply the language your browser and the server use to make these requests and replies.
Step 5 — From HTML to Pixels
Once the HTML arrives, the browser transforms bytes into pixels through a six-stage pipeline called the critical rendering path.
Bytes become tokens and then nodes, building the Document Object Model tree.
Stylesheets are fully processed before painting — later rules can override earlier ones.
A <script> without attributes pauses DOM construction. async and defer avoid the block.
Both trees are combined, discarding invisible nodes (display:none, <head>).
Geometry is calculated: position and size of every element according to the viewport.
Pixels are rasterised into layers and composited, with GPU acceleration where possible.
Optimising this path — minifying resources, using async on scripts, preloading fonts, avoiding forced layouts — is the essence of modern web performance. The key metrics are LCP (loading of the main element), CLS (visual stability), and INP (responsiveness to interactions).
Imagine the server sends your browser a set of blueprints — instructions written in HTML and CSS that describe what the page should look like. The browser is the builder that reads those blueprints and paints every detail onto your screen: the titles, the buttons, the images, the colours. The faster it can read and understand the blueprints, the sooner you see the finished page.
Putting It All Together
Every time you open a web page, five invisible steps happen in rapid succession — usually in well under a second. Here is the full picture at a glance:
| Step | What happens | Plain English |
|---|---|---|
| ① DNS | Domain name → IP address | Finding the server's "phone number" |
| ② TCP | Three-way handshake | Agreeing to start a reliable conversation |
| ③ TLS | Encryption negotiation | Sealing the conversation with a private lock |
| ④ HTTP | Request and response | Asking for the page and receiving it |
| ⑤ Render | HTML/CSS/JS → pixels | The browser paints everything on your screen |
Whether you are a developer tuning a CDN cache, or someone who just wants to understand why a page sometimes loads slowly, these five steps are the answer. Each one has been refined over decades by open standards bodies — the IETF, the W3C, the WHATWG — and implemented by thousands of engineers across browsers, operating systems, and server software. The result is a system so reliable and fast that we take it entirely for granted — until it breaks. Understanding how it works is the first step to building web experiences that are faster, safer, and more resilient.
Main References
- IETF, RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 (E. Rescorla, August 2018).
datatracker.ietf.org/doc/html/rfc8446 - IETF, RFC 1035 — Domain Names — Implementation and Specification (P. Mockapetris, November 1987).
datatracker.ietf.org/doc/html/rfc1035 - IETF, RFC 9110 — HTTP Semantics (R. Fielding, M. Nottingham, J. Reschke, June 2022).
datatracker.ietf.org/doc/html/rfc9110 - MDN Web Docs — Critical rendering path, Mozilla Developer Network.
developer.mozilla.org/en-US/docs/Web/Performance/Guides/Critical_rendering_path - CERN — The birth of the Web.
home.cern/science/computing/birth-web
