The path of a web request from the address bar to the screen

Objectives

By the end of the lesson, you can follow the opening of a page as a single process (URL, name resolution, connection, protection, HTTP, processing), say what the task of each step is, and tell which observation point shows what of the process.

Why do we need to see it as a whole?

The URL, DNS, the connection, HTTP, and the browser's processing are each easy to understand separately. The user, however, perceives only one action: opening a page. If something breaks, debugging requires knowing what each step is for, and what has already happened and what has not. This lesson strings the pieces of the earlier lessons into one process.

The process

The student types the address https://kurzuspont.example/kurzusok.

flowchart LR
    U[URL] --> D[DNS and IP address]
    D --> C[TCP + TLS]
    C --> Q[HTTP request]
    Q --> S[Provider system]
    S --> V[HTTP response]
    V --> B[Browser processing]
    B --> O[Usable page]

Step by step:

1. Breaking down the URL (2.1). The scheme asks for HTTPS, the host name names the service, the path identifies the resource.
2. Name resolution (4.1). DNS gives an IP address (or several) for the host name. If there is a valid cached answer, this step is short.
3. Connection and protection (4.2). The browser builds a connection (TCP, or QUIC for HTTP/3), performs a TLS handshake, checks the certificate, and meanwhile negotiates the HTTP version.
4. HTTP request (2.2–2.5). The browser sends the method, the target, and the headers (GET /kurzusok, Accept, etc.).
5. Intermediaries and server (4.4). The request reaches the application through a CDN or a reverse proxy, or gets its answer from the cache of one of the intermediaries.
6. Application and data. The application may check authorization, request data, and produce HTML or other content.
7. HTTP response (2.4). A status code, headers, and a body come back.
8. Processing in the browser (3.3, 3.4). The DOM and CSSOM are built, further resources load, the page is laid out and painted.

A real request through the eyes of curl -v

We can recognize the steps in the output of curl -v as well. A shortened output from the example.com page (11 October 2026), with each line marked with the step it belongs to:

*   Trying [2606:4700:10::6814:179a]:443...               ← name resolution done, connection
* ALPN: curl offers h2,http/1.1                            ← protocol negotiation
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
*  subject: CN=example.com                                 ← certificate
*  issuer: C=US; O=SSL Corporation; CN=Cloudflare TLS Issuing ECC CA 3
* ALPN: server accepted h2
* using HTTP/2
> GET / HTTP/2                                             ← HTTP request
> Host: example.com
> Accept: */*
< HTTP/2 200                                               ← HTTP response
< content-type: text/html; charset=utf-8
< server: cloudflare
< cf-cache-status: HIT

(The > is the outgoing, the < the incoming message; the * lines are curl's own remarks. We shortened the output.)

Time and steps: what costs how much?

curl also prints the times of the steps. Two measurements from example.com (in seconds, counted from the start of the request):

measurement 1: dns=0.0378 tcp=0.0492 tls=0.0660 ttfb=0.0833 total=0.0834
measurement 3: dns=0.0021 tcp=0.0115 tls=0.0281 ttfb=0.0447 total=0.0448

The numbers are cumulative; the time of each step is obtained from their differences:

Step	Measurement 1	Measurement 3
Name resolution (dns)	37.8 ms	2.1 ms
TCP connection (tcp − dns)	11.4 ms	9.4 ms
TLS handshake (tls − tcp)	16.8 ms	16.6 ms
Waiting for the first byte (ttfb − tls)	17.3 ms	16.6 ms
Download (total − ttfb)	0.1 ms	0.1 ms

In the first measurement name resolution was the most expensive (it was not yet in the cache), in the third it was almost nothing. TCP, TLS, and the server's waiting time, however, stayed roughly constant. In the next lesson we see what these numbers mean for latency and errors.

From response to page

After the HTML arrives, the browser builds a document tree, discovers further resources, applies styles, computes the layout, and paints (3.3). The references in link, script, and img can start new requests, some of which lead to the same service and some to external endpoints. A page is therefore not the result of a single response. The 200 status of the first HTML response is necessary but not sufficient evidence of usability: a style sheet may be missing, a program may fail, a data request may be late.

Observation points of the process

Observation point	What does it show?
Address bar	The opened URL and the security state.
Network panel	The requests started by the browser, their status, headers, and timing.
Elements / Inspector	The current DOM and the styles (3.2).
curl	The raw messages and timing of a single request, without the browser's processing.
User test	Whether the goal can really be accomplished.

Together they give stronger evidence than a single status code or screenshot.

Worked example: the course list of Kurzuspont

When the student opens https://kurzuspont.example/kurzusok:

1. The browser gets the address of the entry point from DNS (fast, thanks to the cache).
2. It builds a TLS connection; the certificate is for the name kurzuspont.example.
3. It sends a GET /kurzusok request; the CDN passes it on, because the list is personalized.
4. The application checks the login, fetches the courses, and sends HTML with a 200 status.
5. The browser processes the HTML and sends further requests for the style sheet (from the CDN) and the script.
6. The page is painted; after the script loads, the filter works too.

If step 1 fails, there is no connection; if step 2, a certificate error; if step 4, a 4xx or 5xx status; if step 5, the page appears but unstyled or non-functional.

Common misconceptions

Statement	Clarification
"The URL is directly the IP address of the application server."	The URL gives a name and a resource; resolving the name is a separate step.
"After DNS comes the HTTP request."	Connection and protection steps are needed too.
"A 200 HTML response means a finished page."	The browser may also need further resources and processing.
"Every opening repeats the same full chain."	A cache and connection reuse skip steps.

In brief

• The path of a request: URL → DNS → connection and TLS → HTTP request → intermediaries and server → HTTP response → processing in the browser.
• Every step has its own role and its own failure mode.
• Because of caching and connection reuse, not every opening is identical.
• The network panel, the Elements view, curl, and the user test each show a different slice.

Review questions

1. List the steps of the path of a request from the address bar to the screen!
2. At which step does the certificate first appear?
3. Why can the second request to the same server cost less?
4. What does the network panel show, and what does it not show?

Learning resources

• How the web works (MDN) — an overview of the whole path.
• Critical rendering path (MDN) — the steps from response to page.