Skip to main content

What Happens During a Web Page Visit

Many people's mental model when they first build a site is just one sentence: "The user visits the URL, and the website opens."

That model is too rough. As soon as you start working with domains, DNS, HTTPS, CDN, reverse proxies, and caching, you will find that many problems can only be understood by going back to the full chain.

The Shortest Version​

When a user enters a URL in the browser, roughly these things happen:

  1. The browser parses the URL to determine which domain, protocol, and path to access
  2. The browser queries DNS to resolve the domain into an IP or proxy address
  3. The browser connects to the target and completes the TLS handshake if needed
  4. The browser sends an HTTP request
  5. The request may pass through a CDN, WAF, or reverse proxy before reaching your origin
  6. The origin returns HTML, CSS, JavaScript, images, API data, and other content
  7. The browser continues requesting dependent resources and finally renders the page

Why This Matters for Building a Site​

Most problems you will encounter later map to one layer in this chain:

  • Domain not opening: usually at the DNS layer
  • Certificate errors: usually at the TLS / HTTPS layer
  • Slow page: could be the origin, CDN, caching, images, or scripts at any layer
  • 404 on a resource: could be build output, paths, reverse proxy, or object storage
  • Intermittent access failures: could be DNS refresh, caching, or origin stability

Breaking It Down by Layer​

1. URL and Protocol​

A URL like https://docs.example.com/guide/start?lang=zh contains at least:

  • Protocol: https
  • Domain: docs.example.com
  • Path: /guide/start
  • Query parameters: lang=zh

The protocol tells the browser how to connect. The path tells the server which resource to return.

2. DNS Resolution​

The browser cannot communicate using a domain name directly. It needs to know the target first.

So it queries DNS to resolve the domain to:

  • A server IP
  • An access address provided by a CDN or hosting platform

The A, AAAA, CNAME, and Nameserver records you configure at your domain registrar are all answering the same question: "Where should this domain ultimately go?"

3. Establishing the Connection​

For HTTPS, the request must complete a TLS handshake before any real data is transmitted.

This step determines:

  • Whether the certificate is trusted
  • Whether the domain matches
  • Whether the connection is encrypted

4. The HTTP Request Enters the Edge Layer or Origin​

Now the browser actually starts sending the request.

But the request may not go directly to your server. It might pass through:

  • CDN
  • WAF
  • Reverse proxy
  • Edge nodes of the hosting platform

This is why "my server is fine, why are users still seeing errors" is often not a single-server problem.

5. The Origin Returns Content​

The origin can be:

  • A static hosting platform
  • Object storage
  • An Nginx static directory
  • A Node / Python / Java application

The origin does not only return HTML. It may also return:

  • CSS, JavaScript, images
  • API data
  • Redirects
  • Error pages

6. The Browser Fetches Dependent Resources and Renders​

After the browser gets the HTML, it continues requesting:

  • Stylesheets
  • Scripts
  • Fonts
  • Images
  • API data

So what the user sees as "opening a web page" actually corresponds to dozens or even hundreds of requests.

A Common Real-World Chain​

Browser
  ↓
DNS
  ↓
Cloudflare / CDN
  ↓
Nginx / Hosting Platform
  ↓
Static Files or Application Service

This is also why building a site requires you to understand all of these at the same time:

  • Domain
  • DNS
  • HTTPS
  • CDN
  • Origin
  • Caching

Things Beginners Most Often Confuse​

1. A Domain Is Not a Server​

A domain is just a name. What actually serves content is the service it resolves to.

2. A Website Opening Does Not Mean Only One Request Was Made​

The homepage is usually just the first HTML file. There are still CSS, JS, images, and API calls after that.

3. Cloudflare Is Not Your Server​

It may sit in front of you doing proxying and caching, but your origin still needs to return content correctly.

4. A Slow Page Does Not Always Mean "Slow Network"​

It could be slow DNS, slow TLS, slow origin, large resources, cache misses, or heavy scripts.

What You Should Remember at Minimum​

If you only remember one thing, remember this:

A web page that a user sees is the result of a complete chain: domain resolution, connection establishment, request forwarding, origin response, and browser rendering.

Whenever you run into a site-building problem in the future, ask yourself first: which layer is it on?