What Happens When You Open a Web Page: From Typing a URL to Rendering

You open dozens of web pages every day, and each one is a precise relay race behind the scenes. From pressing Enter to the page appearing usually takes only a few hundred milliseconds, yet it contains five stages: DNS resolution, connection setup, request, response, and rendering. Here is an analogy: browsing the web is like taking a taxi to a restaurant — you tell the driver the restaurant's name (the domain), the navigation (DNS) gives the street address (the IP), you ride over (connect), you order at the counter (send a request), the kitchen cooks (the server responds), and you sit down to eat (render). This guide walks through that "trip" stop by stop.

Step 1: Type the URL and resolve the domain (DNS)

You type www.example.com into the address bar and press Enter. The browser does not recognize this "name"; it first asks DNS (the Domain Name System): what is the server IP behind this domain? The lookup order is "browser cache → OS cache → local DNS → recursive DNS server," and once found it returns an IP such as 93.184.216.34. To dig into the record types and configuration, see domain DNS records basics and DNS smart routing.

Step 2: Establish the connection (TCP handshake and TLS)

With the IP in hand, the browser opens a TCP connection with the server (a three-way handshake); then, if the URL starts with https://, it performs a TLS handshake to exchange encryption keys. The point of this step is simple: make sure data cannot be read or tampered with in transit. For the details of HTTPS, see HTTPS basics.

Step 3: Send the request

The browser sends an HTTP request to the server, carrying the path you want (such as /about), the browser type, supported encodings and languages, and cookies. The server receives it and starts "preparing the dish."

Step 4: The server responds

The server (possibly Nginx or Apache, backed by application code and a database) processes the request and returns three things:

  • Status code: such as 200 (OK), 301 (redirect), 404 (not found), or 500 (server error);
  • Response headers: type, cache policy, security policy, and more;
  • Response body: usually HTML first, which in turn references CSS, JavaScript, images, and other resources.

If a CDN is enabled, users hit the nearest edge node first, dramatically reducing both origin load and user latency. See how CDN works for details.

Step 5: The browser renders

Once the HTML arrives, the browser starts "decorating": it parses HTML into the DOM, parses CSS into styles, executes JavaScript, composites layout and painting, and finally displays the page. Resources download in parallel, but JavaScript can block rendering, so "scripts at the bottom and lazy-loaded images" noticeably improve first-screen speed.

A page-load flowchart

flowchart TD
    A[Type URL and press Enter] --> B[DNS resolution: domain to IP]
    B --> C[TCP three-way handshake]
    C --> D[TLS handshake, encrypted HTTPS channel]
    D --> E[Send HTTP request GET /]
    E --> F{CDN hit?}
    F -- Yes --> G[Edge node returns cached content]
    F -- No --> H[Origin server handles the request]
    H --> I[Query database / app logic, build response]
    G --> J[Browser receives HTML]
    I --> J
    J --> K[Parse HTML to DOM, CSS to styles]
    K --> L[Run JavaScript, load images and resources]
    L --> M[Layout, paint, display the page]

The roles of CDN and caching here

  • DNS layer: Smart resolution can route users from different regions to different nodes; see DNS smart routing.
  • Content layer: Static assets (images, CSS, JS) are cached on CDN edge nodes, so repeat visits do not hit the origin; the browser's local cache makes "returning users" load almost instantly.
  • Effect: Overall load time can drop by more than 50%, especially for cross-region access. For selection advice, see the CDN beginner's guide.

What is inside an HTTP request

A request is not just "give me a page" — it carries quite a bit of information, like telling the restaurant your taste and allergies when ordering:

  • Method: GET (fetch data, such as opening a page), POST (submit data, such as login or checkout), PUT/DELETE (modify/delete); the wrong method gets a 405.
  • Headers: User-Agent (browser type), Accept (which formats are supported), Cookie (login state), Referer (where you came from). Servers use these for personalization and security checks.
  • Body: form or JSON data sent with POST, such as the username and password you submit.

The server combines all this to decide who you are, which version to serve, and whether to block you. This is also why you stay logged in after a refresh — it relies on the Cookie in the request header plus the session returned by the server.

FAQ

Q1: Why do some pages appear "progressively"? Because the HTML arrives first while CSS, JS, and images follow, and the browser paints as it goes; putting scripts at the bottom and compressing assets helps.
Q2: When a page fails to open, where is the problem? Walk the chain: domain resolution (ping / DNS lookup) → connection (telnet the port) → server (logs / status codes) → frontend assets (browser console).
Q3: Does HTTPS need a handshake every time? After the first connection it can be reused (HTTP/2 multiplexing), so you do not re-handshake on every visit.
Q4: Why does a site sometimes fail only after switching networks? Usually local DNS cache or your ISP's DNS issue — changing DNS servers or clearing the cache often fixes it.
Q5: Why do some requests need a "preflight"? Before a cross-origin request, the browser sends an OPTIONS preflight to confirm the server allows the cross-origin call, then sends the real request — a browser security mechanism.