How Content Is Delivered to Users

When you type an address into your browser and a page appears a moment later, it feels instant. Behind that single moment is a small journey: a request leaves your device, travels across the internet, finds a computer that holds the page, and the answer travels all the way back. Most of the time you never think about it, and that is exactly the point. But if you build websites, understanding this path helps you reason about why some sites feel snappy and others feel sluggish.

In this article we will walk that path end to end. We will start at the place where your content lives, follow the request out into the network, see how it gets routed to a nearby server, and finally watch your browser turn the response into pixels. By the end you should be able to picture the whole trip in your head.

The two main characters: origin and edge

Before we trace anything, let’s name the two computers that matter most.

The origin server is the home of your website. It is the machine (or group of machines) where your files actually live and where your application runs. When someone asks, “where is this site hosted?”, they are asking about the origin. If your blog is built once and stored as ready-made files, the origin simply hands those files over. If your site builds pages on the fly, the origin does that work before answering.

The edge is a copy machine placed close to your users. “Edge” refers to a network of servers spread across many cities around the world, run by a CDN (Content Delivery Network). A CDN’s job is to keep copies of your content near the people requesting it, so the answer does not have to travel all the way back to your origin every single time.

Think of the origin as a single bakery that makes the bread, and the edge as small shops in every neighbourhood that keep loaves on the shelf. If your neighbourhood shop has the loaf you want, you grab it immediately. If not, the shop calls the bakery, gets it, and keeps a copy for the next person.

Step one: turning a name into a place

Your journey starts before any content moves at all. You type blog.acy-partner.com, but computers do not route traffic by name — they route by number, an IP address. So the first job is to translate the name into an address. This translation is handled by the DNS (Domain Name System), which works like a phone book for the internet.

Here is the subtle part that ties into delivery: when a CDN is involved, DNS does not just return one fixed address. It tries to return the address of an edge server that is close to you. So two people in different countries asking for the same site can be pointed to two different edge locations. The naming step is quietly the first moment of “getting you to the nearest server.”

You type:        blog.acy-partner.com
DNS answers:     203.0.113.10   (an edge near YOU)
Someone else:    198.51.100.20  (an edge near THEM)

Once your browser has an address, it can open a connection and send the actual request.

Step two: the request travels to the edge

Now your browser sends an HTTP request — a short, structured message that says what you want. A simplified version looks like this:

GET /en/programming/web-fundamentals/ HTTP/1.1
Host: blog.acy-partner.com
Accept: text/html

That message does not teleport. It is broken into small packets that hop from your device to your router, to your internet provider, and through several network “waypoints” until it reaches the edge server DNS pointed you to. Each hop is a brief handoff, like a letter passing through sorting centres on its way to a destination.

The good news for you, the developer, is that you rarely manage these hops yourself. Your responsibility is making sure the request can arrive (correct DNS, a working server) and that the answer comes back quickly. That second part is where caching enters.

Step three: cache hit or cache miss

The edge server now has your request in hand and asks itself one question: do I already have a fresh copy of this?

A cache is just stored content kept ready to reuse. The edge keeps recently requested files so it can answer the next person without bothering the origin. There are two possible outcomes.

A cache hit means yes, the edge already has a valid copy. It answers you straight away. This is the fast path, and it is why a second visit often feels quicker than the first.

A cache miss means no, the edge does not have it (or its copy has expired). Now the edge becomes a messenger: it forwards your request all the way back to the origin server, waits for the origin to produce the content, sends that content to you, and — importantly — keeps a copy so the next person gets a hit.

                           CACHE HIT
  You ──► Edge ──► (copy on shelf) ──► You          fast

                           CACHE MISS
  You ──► Edge ──► Origin ──► Edge (stores copy) ──► You    slower, once

Here is the comparison side by side:

Not everything should be cached the same way. A logo or a stylesheet rarely changes, so the edge can hold it for a long time. A personalised page — say, one showing a logged-in user’s name — should usually not be cached at the edge at all, because one person’s copy must never be shown to someone else. Your server controls this with response headers that say how long, and whether, a piece of content may be reused.

Step four: the response comes back

When the content reaches your browser, it arrives as an HTTP response: a status line, some headers, and the body. A healthy response starts like this:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600

The 200 OK is the server saying “here is what you asked for.” The headers describe the content and its caching rules, and the body is the actual HTML. But receiving the HTML is not the end — for most pages, that HTML refers to other things the browser still needs: stylesheets, scripts, images, fonts. Each of those is its own request, and each can be a hit or a miss at the edge.

So a single page view is rarely one trip. It is one request for the HTML, followed by a flurry of smaller requests, many of which the nearby edge can answer instantly.

Step five: the browser renders the page

Now the browser does its own work, turning text into something you can see.

First it reads the HTML and builds a tree of elements — the structure of the page, like headings, paragraphs, and images. Then it applies the CSS to decide how each element should look: colours, spacing, fonts, layout. It runs any JavaScript, which can change the page or load more data. Finally it paints the result onto the screen.

HTML ─► structure   (what is on the page)
CSS  ─► styling     (how it looks)
JS   ─► behaviour   (what it does / fetches)
        │
        ▼
     pixels on your screen

This render step happens entirely on your device, which is why a fast network is only half the story. A page can be delivered quickly yet still feel slow if the browser has a heavy amount of work to do afterward. Good delivery and a light, well-built page work together.

Putting the whole trip together

Let’s replay the journey in one continuous line, the way it really happens:

1. You enter blog.acy-partner.com
2. DNS turns the name into the address of a NEARBY edge
3. Your request hops across the network to that edge
4. Edge checks its cache:
      HIT  → it answers you immediately
      MISS → it asks the ORIGIN, relays the answer, stores a copy
5. The HTML arrives; the browser requests CSS, JS, images
6. The browser builds, styles, and paints the page
7. You see the content

Every site you have ever loaded followed some version of these steps. The differences between a fast site and a slow one usually come down to the same few levers: how close the edge is, how often requests are hits instead of misses, how much the origin has to do on a miss, and how heavy the page is to render at the end.

Recap

The path from server to screen is shorter to describe than it feels. Your content lives on an origin server. A CDN edge keeps copies of that content close to users. When you request a page, DNS points you to a nearby edge, your request travels there across the network, and the edge either answers from its cache (a hit, fast) or fetches from the origin and stores a copy (a miss, slower the first time). The response returns, your browser requests the extra files it needs, and finally it renders everything into the page you see.

Hold on to this mental model. Hosting decides where the origin lives, a CDN decides how close the copies sit, caching decides how often you skip the long trip, and the browser decides how quickly the delivered content becomes visible. Once you can see those four parts as one flow, performance stops being mysterious and starts being something you can reason about.