HTTP, HTTPS and TLS: Part 14 — What happens when you open a website: the full request path

You type example.ru and press Enter. Half a second later the page appears on the screen. In that time the browser manages to find the server’s IP address, establish a secure connection, send the request, wait for the server to assemble the response, download dozens of files and render the page. This article walks the whole path step by step: what happens at each step, how long it takes, and where to look for a problem if the page loads slowly or doesn’t load at all. Details of each step are in earlier parts of the series; links to them are given along the way.

For timing estimates we’ll assume the round-trip time to the server (RTT) is 50 ms — a typical value for a server in a nearby city.

1. Address parsing and scheme selection

The browser decides what was entered: an address or a search query. example.ru looks like a domain, so the browser completes it as a URL. Next — choosing between HTTP and HTTPS:

• the domain is in the HSTS preload list or the site has already sent a Strict-Transport-Security header — then https:// immediately;
• otherwise modern browsers still try HTTPS first (HTTPS-First in Firefox, HTTPS-Upgrades in Chrome) and fall back to HTTP only if HTTPS doesn’t work.

Details — see the article “Moving to HTTPS: redirects, HSTS, HTTPS-First and the Upgrade header”.

If the site was opened recently, the browser may take the page or parts of it from its cache and not go to the network at all — this is controlled by Cache-Control headers from previous responses (“HTTP headers”).

2. DNS: name becomes an address

The browser needs the IP address of example.ru. It looks it up through a chain until it finds it:

1. the browser’s own cache;
2. the operating system cache and the hosts file;
3. the DNS resolver: usually the router or the ISP’s server, or a public resolver (1.1.1.1, 77.88.8.8), or a DoH server if encrypted DNS is enabled in the browser;
4. if the resolver has no cached answer, it queries the chain of servers: root → .ru zone servers → authoritative servers for example.ru.

The browser requests three record types at once: A (IPv4), AAAA (IPv6) and HTTPS. The HTTPS record can indicate that the site supports HTTP/3 and provide keys for ECH (“What is ECH”).

Time: from the cache — 0 ms, from the ISP resolver — 5–30 ms, with full chain traversal — up to 100–200 ms.

What can go wrong: the domain is not delegated or records are wrong (NXDOMAIN, “Could not find server IP address”); an old record is cached after a move; the provider is modifying responses.

3. TCP: connection setup

Having obtained addresses, the browser opens a TCP connection to port 443. The three-way handshake: client sends SYN, server replies SYN-ACK, client sends ACK. That’s one full round (1 RTT).

If the site has both IPv4 and IPv6, the browser tries both almost simultaneously, with a small preference for IPv6, and uses whichever responds first (the Happy Eyeballs algorithm). So a broken IPv6 usually appears not as an error but as a small delay.

Time: 1 RTT — 50 ms.

What can go wrong: the port is blocked by a firewall (connection hangs until timeout) or nothing is listening on the port (immediate “Connection refused”).

For HTTP/3 steps 3 and 4 are combined: the browser sends QUIC packets over UDP and transport + encryption are established in one round (“HTTP/1.1, HTTP/2 and HTTP/3”).

4. TLS: secure channel

On top of TCP a TLS 1.3 handshake takes place (“What is HTTPS and how TLS handshake works”):

1. ClientHello — versions, ciphers, key for key exchange, server name (SNI), list of protocols (ALPN: h2, http/1.1);
2. ServerHello with the server key; after this everything is encrypted: the certificate, the signature, Finished;
3. the browser verifies the certificate: chain up to a trusted root, validity period, name match;
4. client’s Finished — and the HTTP request is sent immediately.

By ALPN the parties agreed on the HTTP version — usually HTTP/2.

Time: 1 RTT for TLS 1.3 (2 RTT for TLS 1.2); session resumption is faster.

What can go wrong: expired certificate, name mismatch, incomplete chain, no common TLS version (“TLS debugging”).

5. HTTP request

Over the established channel the browser sends the request (“What is HTTP”):

:method: GET
:path: /
:authority: example.ru
:scheme: https
accept: text/html,...
accept-encoding: gzip, br, zstd
accept-language: ru-RU,ru;q=0.9
cookie: session=...
user-agent: Mozilla/5.0 ...

The request goes in one HTTP/2 frame with compressed headers.

6. On the server side

The request rarely reaches the application directly. A typical path:

1. CDN or DDoS protection (if present) — terminates TLS, inspects the request: is it a bot, is there a cached response. If there’s a cached response it’s returned immediately and the request doesn’t reach your server. Client fingerprinting is evaluated here (“What are JA3 and JA4”);
2. load balancer or reverse proxy (Nginx, HAProxy) — selects the application server by Host and path, adds X-Forwarded-For and X-Forwarded-Proto;
3. application — PHP-FPM, Node.js, Python, Go: checks session by cookie, queries the database, cache, external APIs, assembles the HTML;
4. the response goes back the same way; the proxy compresses it, adds security headers, CDN may store it in cache.

Time: from single-digit milliseconds for static content or a cache hit to hundreds of milliseconds or seconds for heavy pages. This is where most of the time is typically spent. In curl this is the difference time_starttransfer − time_appconnect, in the browser it appears as “Waiting for server response” on the Timing tab.

What can go wrong: the application crashed (502), didn’t respond in time (504), returned an error (500), the request was blocked by protection (403, captcha).

7. Response

:status: 200
content-type: text/html; charset=utf-8
content-encoding: br
cache-control: no-cache
strict-transport-security: max-age=31536000
set-cookie: ...

The browser decompresses the body, records HSTS and cookies, stores the response in the cache according to Cache-Control rules. If the response is a redirect (301, 302), the whole chain starts again for the new address; crossing to another domain — DNS happens again.

Result of the first request with RTT 50 ms: DNS 20 ms + TCP 50 ms + TLS 50 ms + request and response 50 ms + server work. Even on a fast server the first HTML byte arrives in about 170–200 ms. Each extra redirect adds at least one more round.

8. Resource loading

The browser begins parsing the HTML before the download finishes and finds links to styles, scripts, fonts, images. It requests them:

• from the same domain — over the already-open HTTP/2 connection, in parallel streams, without new handshakes;
• from other domains (static CDN, fonts, trackers, widgets) — for each domain again DNS, TCP and TLS. So each third-party domain on the page costs ~100–150 ms on the first visit. You can speed this up with a hint like <link rel="preconnect" href="https://cdn.example.ru">.

Not all resources are equal:

• CSS blocks rendering — the browser won’t show the page until it loads styles from the <head>;
• scripts without async or defer block HTML parsing — the browser stops, downloads and executes the script;
• images and fonts load in parallel and don’t block parsing, but a font can delay text rendering.

The server can speed this phase: a 103 Early Hints response or a Link: <...>; rel=preload header can indicate important resources before the HTML is ready.

9. Rendering

From HTML the browser builds the DOM tree, from CSS — the style tree, combines them, computes layout, and paints pixels. JavaScript can modify the DOM, causing parts of this work to repeat.

For users three metrics from Core Web Vitals matter:

• LCP (Largest Contentful Paint) — when the main page element is shown; good — under 2.5 s;
• INP (Interaction to Next Paint) — how quickly the page responds to interactions; good — under 200 ms;
• CLS (Cumulative Layout Shift) — how much elements jump during load; good — under 0.1.

10. What remains afterwards

The connection to the server isn’t closed immediately — subsequent navigations on the site will reuse it without handshakes. The browser remembers:

• DNS answers (for the TTL);
• TLS session ticket — resumed handshakes are shorter;
• HSTS — next visits go straight to HTTPS;
• Alt-Svc header — next visit can go over HTTP/3;
• cached resources — on a repeat visit they don’t need to be downloaded.

So the second visit to a site is almost always several times faster than the first, and speed should be tested in both modes — with an empty cache (DevTools → Disable cache or an incognito window) and with a primed cache.

Real-site breakdown

The same steps on this site, bigmike.help: measurement on 24 September 2026, site behind CloudFront CDN. Repeat the commands for your site — the numbers will differ, but the order of magnitudes is similar.

DNS: full chain without cache. dig +trace goes through the chain itself, starting from root servers:

dig +trace +nodnssec bigmike.help A | grep '^;; Received'

;; Received 823 bytes from 192.0.2.53#53 in 5 ms                  ← list of root servers from the provider's resolver
;; Received 285 bytes from 192.58.128.30#53(j.root-servers.net) in 15 ms     ← root: "ask the .help servers"
;; Received 180 bytes from 194.169.218.158#53(a.nic.help) in 44 ms           ← .help zone: "ask awsdns"
;; Received 244 bytes from 205.251.196.103#53(ns-1127.awsdns-12.org) in 46 ms ← authoritative server: addresses

Without cache — about 110 ms for four queries. From the resolver cache the same answer arrived in 3 ms. The answer contains four IPv4 addresses and CloudFront IPv6 addresses.

All stages of a single request:

curl -s -o /dev/null -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://bigmike.help/ru/

Response headers:

curl -sI https://bigmike.help/ru/

HTTP/2 200
via: 1.1 Caddy, 1.1 ….cloudfront.net (CloudFront)
x-cache: Hit from cloudfront
age: 8359
alt-svc: h3=":443"; ma=86400
strict-transport-security: max-age=31536000
etag: "6ab48ab0-e02e"

You can read the whole path from these: via — the request passed through Caddy on the server and CloudFront; x-cache: Hit and age: 8359 — the response came from the CDN cache where it sat for 2 hours 19 minutes, the origin server wasn’t contacted; alt-svc — the site is available over HTTP/3 and the browser will try it on the next visit; strict-transport-security — the browser will remember to use HTTPS only.

Cache miss. The same page immediately after an update on the origin — first byte at 570 ms instead of 60–90 ms: the CDN had to fetch the response from the origin. A repeat request — Hit again and ~60 ms. The difference is almost tenfold — that’s the benefit of a CDN.

Connection reuse. Two URLs in one curl invocation go over the same connection:

curl -s -o /dev/null -o /dev/null -w '%{url_effective}: tcp %{time_connect} tls %{time_appconnect} new connections %{num_connects}\n' \
  https://bigmike.help/ru/ https://bigmike.help/ru/posts/

https://bigmike.help/ru/: tcp 0.020 tls 0.043 new connections 1
https://bigmike.help/ru/posts/: tcp 0.000 tls 0.000 new connections 0

For the second page no DNS, TCP or TLS were needed.

Compression. The same HTML with gzip compression — 15 KB instead of 57 KB:

curl -s --compressed -o /dev/null -w '%{size_download}\n' https://bigmike.help/ru/   # 15362

HTTP to HTTPS redirect:

curl -sI http://bigmike.help/ | grep -iE '^(HTTP|location)'
# HTTP/1.1 301 Moved Permanently
# Location: https://bigmike.help/

The first visit over http:// costs an extra round for the redirect; after receiving HSTS the browser will go directly to https://.

How to see this yourself

curl shows stages of a single request (“HTTP debugging with curl”):

curl -s -o /dev/null https://example.ru/ -w \
 'dns %{time_namelookup}  tcp %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n'

Browser DevTools — Network tab, Waterfall column and the Timing tab for a request: the same stages for each resource on the page, including queueing time (“Intercepting HTTPS for debugging”).

Lighthouse (in DevTools) and PageSpeed Insights — Core Web Vitals metrics and specific recommendations for render-blocking resources.

Where to look for the problem by symptom