# Tracing a URL to a Rendered Page, and the Two Stories I Almost Told at Once

The assignment was simple to state and harder to actually do: explain, step by step, everything that happens between typing a URL into a browser and seeing a rendered page appear on screen. Label the client and the server. Break the URL into its parts. Say what DNS does, in one sentence. Explain frontend versus backend, in one or two sentences. Then be able to say the whole thing out loud, from memory, without the page in front of me.

I used a fake URL throughout so nothing here depends on a real server actually responding: https://www.TeSidrah.com/projects?sort=latest.

Client and server

Two roles show up the moment the URL is typed in and Enter is hit. The browser on my machine is the client, it sends requests. TeSidrah's remote machine is the server, it listens for requests and sends back responses.

The frontend is everything that runs on the client's own machine, using the client's own resources. The backend is everything that runs on the server's machine, using the server's resources.

That second sentence took longer to get right than it looks. My first attempt at defining backend split it into three separate ideas: where it runs, what its logic does, and where its database lives. It read like three facts about backend instead of one definition of what backend actually is. The database isn't what makes something backend, it's just a common piece of what backend systems tend to have. Once I dropped it and matched the shape of the frontend sentence exactly, both definitions said the same kind of thing about two different machines.

Breaking down the URL

The browser takes the URL apart into four pieces: the protocol (https://, the rules for communication, here adding an encryption layer), the domain (www.TeSidrah.com, the name of the server), the path (/projects, which resource on that server), and the query parameters (?sort=latest, extra instructions attached to the request).

DNS: the lookup before the real request

The browser can't send anything to a name like www.TeSidrah.com, it needs a numeric address. So it sends the domain to a DNS server first.

This is where something shifted while I was writing it. DNS isn't a separate mechanism sitting off to the side of the real request. It's the same request/response pattern, just happening first and at a smaller scale: the browser sends something (a domain name) and gets something back (an IP address). Once that clicked, the rest of the flow stopped looking like a list of separate steps and started looking like one idea repeating at different sizes: ask, wait, get an answer back.

Getting that into one sentence, the way the assignment asked, took a few tries: DNS translates a human-friendly domain name into the numeric IP address a computer actually needs to route the request. Writing a paragraph about DNS was easy. Getting it down to one correct sentence took several passes.

The real request

Now holding the IP address, the browser sends the actual request: the method (GET, please retrieve this for me), the path (/projects), the query string (?sort=latest), and metadata about the browser itself.

The server responds

This is the step where my first draft quietly told two different stories at once, without me noticing at first. I'd written the server's response as a 404, page not found, and then in the very next section described what happens if there was a page: the DOM gets built, CSS and JS and images get fetched, layout gets calculated, pixels get painted. Two different outcomes, stitched together as if they were one continuous thing.

I considered a few ways to fix it. Keeping both outcomes as two branches would have split the walkthrough in half, and the whole point was to explain one continuous flow I could say out loud without qualifying it. Stopping at the 404 was tempting, it's a real and common outcome, but it would have cut the explanation short right before the most substantial part: everything the browser does once it actually has a page to work with. So I committed to the success path all the way through, and kept the 404 as a one-line aside instead of its own branch.

TeSidrah's server reads the method, path, and query, runs its backend logic (queries the database, sorts by "latest," builds the page), and responds with a status code, 200 OK, and a body: the raw HTML.

What the browser does with it

The browser parses the HTML into the DOM, an internal tree of the page. As it parses, every reference to a stylesheet, script, or media file fires off a new request, each one its own small request/response cycle. Once everything's arrived, the browser combines the HTML with the CSS to work out layout, then paints the final pixels.

One breath

User types URL, browser labels client and server. URL splits into protocol, domain, path, query. DNS resolves the domain to an IP, a request/response in miniature. The browser sends the real request. The server runs its logic and replies with 200 and HTML. The browser parses, fetches what it's missing, lays out, paints. The page appears.

Writing all of this down turned out to be the easier half. Being able to say the whole cycle out loud, from memory, without the page open in front of me, was a different and harder bar than being able to write it. Something about not being able to lean on the sentence I'd already typed made it obvious which parts I actually understood and which parts I'd just successfully described once.